HN user
Hi, one of the authors here. We discuss this in the last section of the post. uBlock Origin uses lists to determine which requests to block. We tested the two largest, EasyList and EasyPrivacy, and both fail to block scripts from FullStory, Smartlook, and UserReplay.
Gmail's image proxying actually won't help much with this style of tracking. In the paper we found email addresses (or hashes of them) leaking to third parties via a query string parameter in the request URL. So the proxied URL still contains your email address and the third parties can still learn you opened and read the email. As another commenter mentions, we found these requests to occur the moment you first open the email in the Gmail web interface. Since the request URL is unique to you, it can still be used to serve you targeted content. See: https://web.archive.org/web/20170922213846/https://support.l...
Actually I suspect image proxying will also interfere with request blockers like ABP or uBlock Origin, which may have otherwise blocked all requests to that third-party domain.
We found that Apple Mail clients typically load remote resources by default, unless the message is spam. That content can't set or retrieve cookies, which is an improvement over other standalone clients.
I'd still recommend disabling remote content by default since the tracking identifiers (the hash of your email address, etc) are present in the image URL. That's enough to continue to track the read and serve targeted content. See: https://web.archive.org/web/20170922213846/https://support.l...
Hello, I'm one of the authors of this work.
The code and data for the study is available here: https://github.com/citp/email_tracking (measurement platform here: https://github.com/citp/OpenWPM).
We also just released a blog post that highlights the main results (and is a quicker read): https://freedom-to-tinker.com/2017/09/28/i-never-signed-up-f...
I prototyped this feature last year as an intern at Mozilla. I think the engineering done for containers can be exposed in a lot of cool ways to the user. I'd love for you to send in your ideas on the comment form [1]. One of the features we considered last summer was "site specific containers" [2], which would support your facebook example.
[1] https://docs.google.com/forms/d/1oQN14TUnqj-MDErp8MKxH_v7Ytt... [2] https://wiki.mozilla.org/Security/Contextual_Identity_Projec...
Feel free to email us at the addresses listed on the bottom of the linked site.
Thanks, I've added a clarification.
There have been a couple plugins which try to address this question: Chameleon (https://github.com/ghostwords/chameleon), which is still in early stages, and FireGloves (https://fingerprint.pet-portal.eu/?menu=6), which was built by a research group (not sure it's still supported).
Also a great paper on this topic: http://research.microsoft.com/pubs/209989/tr1.pdf
Yes, we'll definitely do an analysis on this and write it up.
The Tor Browser folks have done some excellent work to reduce the fingerprintability of the browser. See "Specific Fingerprinting Defenses in the Tor Browser" here: https://www.torproject.org/projects/torbrowser/design/#finge....
For Firefox and Chrome there are canvas fingerprint blockers [1] and [2]. These are heuristic based, so you'll likely see a bit of false positives. uBlock Origin includes an option to prevent the leakage of local IP addresses [3].
[1] https://addons.mozilla.org/en-US/firefox/addon/canvasblocker...
[2]https://chrome.google.com/webstore/detail/canvasfingerprintb...
[3]https://github.com/gorhill/uBlock/wiki/Prevent-WebRTC-from-l...
Yes, no sound is recorded. Access to the user's mic isn't possible without a permission. If there are sections of the website or paper that seem to imply that, let me know and we'll clarify.
Other co-author here. Unfortunately there are good performance reasons for allowing WebRTC to access the local IP, see the lengthy discussion here: https://bugzilla.mozilla.org/show_bug.cgi?id=959893. One use case is allowing two peers behind the same NAT to communicate directly without leaving the local network.
The working group recommendation that we linked in the paper (https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handli...) addresses some of the concerns that arise from that (namely the concern that a user behind a VPN or proxy will have their real, public address exposed), but still recommends that a single private IP address be returned by default and without user permission.
However that's still quite identifying for some network configurations, e.g. a network which assigns non-RFC1918 IPs to users behind a NAT. Seems to me that putting access to the local IP address behind a permission would both remove the tracking risk and still allow the performance gains after the user grants permission.