Hacker News new | past | comments | ask | show | jobs | submit login

I would replace Ghostery in your list with Disconnect. I would also add the 'Self-destructing Cookies' browser plugin. In its settings, whitelist a very limited set of sites you want to allow persistent (or session) cookies.




I work on Disconnect and don't quite understand what your page is getting at (you probably ought to be disclosing that this is your page and project, btw). If you consider the Guardian page, for instance, all the domains you've listed as third parties except Google and Twitter actually look to be first parties serving content for the page. In other words: If you go to the Guardian, you're going to be tracked by the Guardian. If you'd like, you can also prevent their pages from working properly by blocking some secondary domains they use.


> "look to be first parties serving content for the page"

"look to be"? How would javascript code know that?

I measured something, and that is the result of my measurement. People can make an informed decision with proper information. I found that the page served well without all the extra requests that Ghostery and Disconnect allowed.

Given the results, I am quite surprise you would say "look to be first parties serving content for the page".

> "If you go to the Guardian, you're going to be tracked by the Guardian"

* facebook-web-clients.appspot.com * guardian-notifications.appspot.com * related-info-hrd.appspot.com * static-serve.appspot.com * cdnjs.cloudflare.com * ajax.googleapis.com * discussion.guardianapis.com * s.ophan.co.uk

Aside `discussion.guardianapis.com`, others are clearly 3rd-parties.

It's seems my definition of "3rd party" aligns more with that of the EFF: https://www.eff.org/deeplinks/2013/06/third-party-resources-...

Now you focused on the Guardian, how about the two other cases I measured?

I'm sure you don't like the result, but this is what came out when I decided to audit. Your response: You don't think it is a problem. That is settled.


To answer your reply to my reply:

> Given the results, I am quite surprise you would say "look to be first parties serving content for the page".

I believe every single domain name you listed (except the Google and Twitter domains, like I said) is a domain owned by or a CDN used by the Guardian or hosts an app run by the Guardian - prove me wrong:

> facebook-web-clients.appspot.com

> guardian-notifications.appspot.com

> related-info-hrd.appspot.com

> static-serve.appspot.com

> cdnjs.cloudflare.com

> discussion.guardianapis.com

> s.ophan.co.uk


> "prove me wrong"

This is a terrible answer: you are suggesting that Disconnect knows exactly which 3rd-party is legit when visiting a web page, and somehow you can vouch that none of these hostnames is a threat to privacy (this is what your defense of this implies).

`static-serve.appspot.com` is no different than `ajax.googleapis.com` (you didn't list this one, why?): they are 3rd-party hostnames, some are CDN which is exactly why they are not to be trusted, you can end up hitting these hostnames from other places than just the Guardian, which is the problem.

In any case, the legitimacy of their their purpose is not the point. They are 3rd-party hostnames: Unless being told, the user wouldn't know that he is also hitting these hostnames.

I will note that you completely disregarded the other results which are even more embarrassing to explain (like `simplereach.cc`: "SimpleReach tracks every social action on each piece of published content to deliver detailed insights and clear metrics around social behavior.")


> You are suggesting that Disconnect knows exactly which 3rd-party is legit when visiting a web page.

Yes! You now know how Disconnect works - Disconnect's filter list is based on weekly crawl data that identifies what the most prevalent third parties on the web are.

> `static-serve.appspot.com` is no different than `ajax.googleapis.com` (you didn't list this one, why?)

You think that URL might belong to Google, which I already called an exception 2x?

> I will note that you completely disregarded the other results which are even more embarrassing to explain (like `simplereach.cc`: "SimpleReach tracks every social action on each piece of published content to deliver detailed insights and clear metrics around social behavior.")

I examined and debunked the entirety of the first example on your page, so I'm not inclined to waste any more time on your so-called "science".


I just tested the front page of wired.com with this new page I just assembled to quickly check what blockers are not blocking: http://raymondhill.net/httpsb/har-parser.html.

Despite "Adobe tag" marked as blocked by Disconnect, these requests were not blocked:

http://p.typekit.net/p.gif?a=219379&f=175.10294.10295.10296....

http://www.adobetag.com/d1/condenast/live/Wired.js

This is the part that bothers me: fooling people into thinking they are shielded against this kind of thing. That is not ok. I accept bugs can happen, but so far your position has been to rationalize why these 3rd-party domains are not blocked.

Oh and in this particular case, Ghostery blocked everything it said it blocked.


Hi gorhill, interesting study. Ghostery runs its own to see how effective privacy extensions are, here it is: http://www.areweprivateyet.com/

Ghostery database is not static either and we update it very often, if you feel we are missing something, please let us know.


Could you include RequestPolicy in your comparison please?

https://addons.mozilla.org/en-US/firefox/addon/requestpolicy...


I tested what is available on Chromium. Request Policy is not available for this platform.


> I would also add the 'Self-destructing Cookies' browser plugin. In its settings, whitelist a very limited set of sites you want to allow persistent (or session) cookies.

Curious, how would this differ from whitelisting cookies in the browser's own settings?




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: