I use Cookie as my cookie "manager," and the v 3.0.6 update I just d/l'ed introduced a "bug" that may in fact be a bonanza for us and a major plus and selling point for it: Little Snitch has begun popping up multiple connection requests from WebProcess for every Web site I visit.

At first glance, this seems like a major nuisance, because sites are requesting that many, 5, 10, even more, connection requests be dealt with before leaving me in peace, but I've realized that most of the requests are to connect with the sites that plant the unwanted tracking caches we find in Safari > Prefs > Privacy > Cookies and other website data > Details, so maaaybe not.

What seems to have happened is that C has somehow contrived to enable LS to block tracking caches from reporting back to the sites that planted them.

True, this comes at the cost of having to enable the connections I want, but I can set "Forever" rules on both the wanted and unwanted connections and apparently breathe easier in the knowledge that a major tracking avenue has been shut down.

(Little Snitch, itself, introduced what was apparently the same "bug" a coupl'a years ago, but it was resolved long ago. I guess its flip-side went unnoticed)

Cookie's developer is approaching this as a bug at the moment, but I'm wondering whether he has in fact stumbled on gold?

All comment will be very much appreciated.

Edit: I just reinstalled Cookie, and the aberrant behavior has not recurred, but I'm still interested in everybody's thoughts on it.

Thanks.

Update: It's (miraculously?) back!

Little Snitch started popping up requests for WebProcess connections from pages that had already been loaded and reloaded right smack dab in the middle of a browsing session, and since I was aware of what was going on I paid attention and saw requests for connections to tracking site after tracking site pop up and presumably be denied forever.

I may never restart my deuced Mac(hina) again.

Update: And just like that, it's gone again (5:40 PM), but not before I took good advantage of it.  (I may have screwed up by quitting Safari, in which case I can maybe count on it to recur.)

Update 2: Took a walk, and it's back again... Beyond bizarre!!!

Update 3: And gone again about 5 minutes later. (Last post 'til I've got some sort of handle on this bizarre issue.)

Edit: Screenshot of my denied "Forever" connections.

those deny's don't say what process is trying to make the connection, but it's via port 80 or 443 so it's probably web based. If you've told it to allow all traffic on those two ports it may shut up.

I've also ran into issues with LS where it keeps bugging me after I deny or allow, and it's caused by the process differing from the previous instance. That was due to a crazy bit of software that would copy off and then spawn a daemon when it needed to be used. When done it would delete it. so LS kept seeing them as new apps. There wasn't any easy way to deal with that unfortunately.

I mentioned in my original post that the guilty process was WebProcess, and the tooltip in my screenshot further identifies it.

But you've got it backwards, I don't want Little Snitch to shut up!

If you look carefully you'll see that all the denied connections are to tracking Web sites, and I'm perfectly happy with having to deal with each of them once to keep them from spying on me forever.

If you like the idea of tracking Web sites being forever inaccessible, there's an even better way than firewalling them. Drop them into your Hosts file on your computer.

The Hosts file, which is built into every Unix-based system, is a special text file. When the computer attempts to connect to a Web site, it consults the Hosts file before it does a name server lookup. If it sees the name of the server in the Hosts file, it uses what it sees there and doesn't look up the site on the name servers. (It's usually used as a means to assign computers on a LAN names and be able to look them up by name.)

If you edit your Hosts file to assign a name to the IP address 127.0.0.1, it will forever be unreachable by that computer. So for example if you add the line

127.0.0.1 doubleclick.com

to your computer's Hosts file, doubleclick.com will disappear into a black hole.

There's a Web site with a huge list of ad and tracking servers already pre-built into an OS X hosts file at

http://pgl.yoyo.org/adservers/

Thanks...great!

I was aware of "Hosts," having used it to facilitate access to MFIF, but the thought of adding zillions of tracking sites to it, one at a time, made it a no-go. Your linked site, on the other hand, provides a huge list to be added in one quick shot, and is a most appealing avenue (which I'll probably travel once my Little Snitch issue has been resolved).

I took a quick look at the list and found that some items LS has highlighted are missing, but most is better than the none that now rules, and I can always add to it. (I don't see your "huge list of ad and tracking servers already pre-built into an OS X hosts file."

This seems to be an important missing link in the quest to attempt to nullify the "if you don't want to be tracked, stay off the Internet" mantra.

Edit: If I'm understanding you, LS, working in much the same, if not the same, manner, augments "Hosts?"

there are places you can go to download a prestocked HOSTS file so you don't have to manage them yourself. I played with that a bit, but a few client apps like adblock are much more self-maintaining and effective.

Got any links to share?

Thanks.

AdBlock for Safari

Click To Plugin (/Flash) for Safari

Those and other popular Safari plugins are available here at Apple

Thanks for the links, but I think we're on different wavelengths.

I'm already running both AdBlock and both ClickTos, but unless I'm mistaken, neither of them blocks the tracking caches shown in Safari > Prefs > Privacy > Cookies... > Details.

I think Ghostery tries to do what I'm looking for, but as far as I can tell its blocking of tracking cookies is subverted by the deployment of tracking caches.

tacit's linked hosts list seems to be the best (only?) option.

Thanks for the suggestion, but I'm not understanding something.

By way of example, even after I add 127.0.0.1 trankynam.com to my hosts file I can access the (XtraFinder) Website to check for updates, and it still plants a cookie when I do.

I assume I'm confusing functionalities, but how? Is it that hosts file's only functionality is that it prevents the cookie from corresponding with the Website?

Thanks.

If you put a Web site in the Hosts file and assign it the IP address 127.0.0.1, it for all intents and purposes vanishes as far as your computer is concerned. Your computer should not be able to find or communicate with that site at all.

I just edited /private/etc/hosts to add FTM


and I was not blocked from FTM, which leaves me wondering whether any of what I did to that file is working as it's supposed to work.

Did I do something wrong...edit the wrong file, not restart, something else?

Thanks.

Edit: I tried restarting, but with no joy.

Maybe try flushing the DNS cache? See OS X: How to reset the DNS cache.

Thanks for a good idea, but no joy.

(On a lark I uninstalled DNSCrypt, also no joy.)

A Goole search found this, which led me to this, but neither the PERL command nor saving the file in BBEdit brought joy.

Edit: I couldn't figure out how to open the file in VIM.

Got it... Found it here (down towards the bottom)!


I added finetunedmac.com to my hosts file, not www.finetunedmac.com.

Unfortunately, though, the answer creates a nightmare situation...

Not a single one of the 2,693 entries in either tacit's linked list or my own list of additions is preceded by www, so "n" Websites that I've assumed are blocked are not blocked at all. (I've tried a few of 2,693, but I'm not about to try them all; my own list has only got about 30 entries, so I will check them.)

And further, I've found that some items are "redirects" and adding the "sign-posts" to the hosts file is wasted effort.

Fooey!!!

(I'm going to advise the creator of the list of what I've found and see if he's got any ideas.)

Actually, a handful are, towards the bottom of the list, but regardless of that, it should be a simple matter to create a second list, with a text editor, by using find and replace.

For example, I used TextWrangler's Search menu -> Find… command, entered \r in the Find: text field and \rwww. in the Replace: text field, then clicked Replace All. This tells TextWrangler to replace every hard return with a hard return followed by www. (which means the very first entry needs the www. added manually, since no hard return precedes it).

The handful of entries which already include www. can be edited manually as well.

and


The statement "# Ad server list for use with hosts files to block ads" at the top of the list is unfortunately worded, so I'll have to do some research and figure out how to make it work.

Excellent!

A quick test suggests that a domain that doesn't need "www" will resolve to a URL without it and be blocked, but I'll test a bit more before following through.

Many thanks for the instructions.

By the way, I forgot to mention that I think the linked list has Mac, rather than UNIX, line breaks, which, presumably, also affects its ability to function as hoped for.

I think that because the file size changed considerably when I saved it with UNIX line breaks in BBEdit.

I made the change, but with an important difference: Your instructions placed www. at the beginning of each line when they should really precede the URLs, so I replaced \r and \rwww. with .1(space) and .1(space)www. in TW's "Find/Replace" window.

Despite the fact that I've saved my hosts file with UNIX line breaks I'm not sure whether I've got I've got UNIX or Mac breaks, because a BBEdit search for \n returns results for \r, but my file appears to be working, so...

What's confusing me now is that items that cannot be accessed from Safari's address bar by their URLs do appear in Safari > Prefs > Privacy > Cookies... > Details, so I'm not certain whether Safari is actually blocking their information collection.

And finally, it looks like this experiment has turned into a nightmare, because there are items on the list whose URLs should not include www., and they cease to be blocked after www. is added to them.

I guess I'll investigate Peter Lowe's Website and figure out how to use his list without appending it to my hosts file.

Aaargh!

Brainstorm: I think I've come up with a solution to the www./no www. issue. I simply added the list to my hosts file twice, one with and once without, and that seems to be working.

Not sure I understand the distinction. In my original TextWrangler document—a copy and paste from this page—each line began with a URL, so placing www. at the beginning of each line did precede each URL with www.

As for your brainstorm: sorry I wasn't more explicit; my unstated assumption was that you'd combine the two into a single list.

We were working with different lists.

Yours doesn't incorporate the 127.0.0.1 that must precede each entry in the hosts file (as does tacit's linked list).

I originally misled myself into thinking that adding www. to an item would block its URL both with and without www., so appending both the www. and non-www. lists to my hosts file didn't appear to be necessary.

Peter Lowe's Web site suggests better ways to make use of the list than appending it to a hosts file, but they're beyond me, so I'll muddle along as best as I can.

In the meantime I'm still wondering whether those tracking caches are actually blocked from reporting back to the entity that placed them, otherwise this entire exercise will have been meaningless other than for its educational aspects.

Edit: The list without the 127.0.0.1 entries may work with a Nameserver, but that's one of the things I couldn't follow.

Got it.


If I'm reconstructing the sequence of events correctly, your flushing of the DNS cache preceded your discovery of the distinction between www.-prepended and non-www.-prepended URLs in the hosts file, so unless you've flushed the DNS cache again, it might be premature to assess the success or failure of the venture.

I discovered the difference between www.-prepended and non-www.-prepended URLs in the hosts file as reported in post #24711, and I've now flushed it the DNS cache multiple times.

As far as judging the success or failure of the venture goes though, I don't see any way to make a judgement... I know Safari can't reach any of the Web sites listed in the hosts file via its address bar, but since I've got less that zero idea how the cached tracking items work I've got no way of knowing whether their communication with their masters has been halted. (I know that tacit places the obsidian fields.com cache, so I'm going to resurrect an old post thread and see whether he'll explain its workings for us.)

Edit: Maybe I've got the answer on my own... I added (tacit's) obsidianfields.com to my hosts file, and a cache (Edit: and cookie) still appeared in Safari > Prefs > Privacy > Cookies... > Details, but tacit's avatar was blocked and a website-unavailable.com cookie turned up.

I'm going to extrapolate from that one instance and guess that all the caches that turn up from blocked Web sites are similarly "tongue-tied."

Edit: Cookies, too, I hope.

Yep.

When you put something into your Hosts file, it's not just blocking that site from Safari. The Hosts file tells your computer "Do not query the name servers for the IP address to this site. Use this value instead."

Functionally, that means that site ceases to exist for your computer. *Any* attempt to reach that site by any software or process on your computer will fail. In addition to not being able to reach it in Safari, you can't ping it, you can't tracert to it...you can't get to it by any means at all.

Even if a reference to it turns up in the HTML of a code that you can reach (for example, if a reference to doubleclick.net shows up in a cookie domain of a site you're browsing), as soon as your computer attempts to resolve the reference, it will fail.

Many thanks for that post, which fully and finally clarifies the matter (for me, anyhow).

I was confused by the caches and cookies from presumably unreachable Web sites that I always find in Safari > Prefs > Privacy > Cookies... > Details, but between your explanation and the very helpful object lesson of your avatar's not loading I'm now satisfied that I've got a viable "don't track me" system, even if it's not a panacea, in place.