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.
This is particularly annoying, because if they just cached the image immediately upon receiving the e-mail, there would be no privacy impact AND you would get to see the image. (Yes, it might still send your e-mail address to third parties, but someone who has your e-mail address is free to send it to anyone they want without your help; there is no way to stop that.)
I guess we didn't need further evidence that Google cares more about third party marketers than users' privacy.
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...
Thank you very much for doing this work! I have recommended that my employer, who makes a popular email client, read this and consider adding these sorts of features.
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.
Is it possible to implement this feature via the extension API ? Exposing the low-levels, like choosing the cookie jar or intercepting calls to the local storage, would sprawl some really good privacy-enhancing extensions.
EDIT: Looks like there are already extensions doing that ! nice !
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].
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.
It does, and also as someone who has never heard of AudioContext before, I can't fathom why it would be necessary for a web application to generate an audio data stream that isn't output to speakers _AND_ _THEN_ analyze the result.
What is the typical use case for AudioContext?
The capabilities of AudioContext used in audio fingerprinting seem like they're beyond what is really necessary?
AudioContext is actually pretty cool. As far as I know, only Firefox supports it at the moment. But it allows you to work with audio streams in raw byteform, which means you can do advanced audio processing in client side javascript.
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.
Thanks for the response! If you're interested and it would be useful for your research, I have some really, really interesting privacy findings regarding Service Workers I'd be happy to share. I'm strongly in favor of an enhanced Open Web, but I'm not comfortable with the opaque nature in which tracking/privacy can be likewise enhanced with little user interaction or notification. Keep up the good work.
