The breadth of responses here about people who can't reproduce this (or can) is one of the most frustrating things about working on fingerprinting protection. I also cannot reproduce this behavior, and have to assume that there is some complicated, behind-the-scenes risk assessment that is being done and some people trigger it and some don't. If any Cloudflare devs want to chat, I would love to. While not a normal way to contact us (support requests will be ignored), I can be reached at security@mozilla.com
> Also by default addons.mozilla.org is a privileged site so of course they include google tracking in it and they get the proper fingerprint no matter what you have configured
AMOs privileges are limited to (A) installing extensions with only one prompt (instead of two) (b) launching some sort of "UI Tour" feature that highlights some features of the UI and (c) extensions cannot, by default, operate on the site. That last one is an unfortunate trade-off we've made because of the massive waves of malicious extensions. You can re-enable extensions access to AMO on a case by case basis: https://support.mozilla.org/en-US/kb/quarantined-domains but I recognize this is an opt-in, non-default configuration.
I am saddened to hear we use Google Analytics on the site, but I can tell you with certainty that it is not bypassing any of Firefox's built-in fingerprinting protections or getting any privileged access that way.
- ETP Standard (see [0] for the latest improvements we rolled out)
- ETP Strict (we're working on things in Bugs 2036879 specifically this issue, 2037260, and more generally 2036786)
- Resist Fingerprinting (RFP)
These levels are something akin to "Wash your hands after using the subway", "Wear a mask on the subway", and "Wear a level B hazmat suit on the subway".
"people already expect sites to break, so why holding back?" - because the breakage is so severe, and people _don't_ associate that breakage with the setting they made. There are bug reports all over the internet proving it, here are some examples [01-4]. The protections we deploy in ETP Standard and Strict are calibrated to provide as much protections as possible while keeping the internet usable, and we're working fulltime on improving them.
To me custom is something I define between Standard and Strict and not the next level after Strict.
Strict already mentions that sites can break, so I'm pretty sure people associate the setting with breakage.
> Stronger protection, but may cause some sites or content to break.
Additionally Strict says :
Firefox blocks the following:
Social media trackers
Cross-site cookies in all windows
Tracking content in all windows
Cryptominers
Known and suspected fingerprinters
It's confusing if Known and suspected fingerprinters doesn't include resist fingerprinting. resist fingerprinting isn't even an option in Custom so how do ordinary users know where to set that option. You know, those users you say won't associate the Strict setting with breaking pages depite the fact that it clearly says so. Some kind of Schrödinger's user? Too dumb to understand the warning, but smart enough to know special settings?
You may avoid unnecessary bug reports that way but maybe only because users don't recognice that they are tracked per fingerprinting. It's not like websites would tell them.
Feels like Mozilla traded their time for my privacy.
second, would it be possible to make RFP appear as an extension like uBO, where it suggests sites to allow-list, or hints that the page might be broken and asks if you want to disable RFP?
I'm more tech savvy than the average user, admittedly, but I've learned this pattern for uBO.
For a time RFP - by itself - could be enabled by web extensions. (It might still be possible, I don't recall if we removed it.) But it's a footgun because it became even easier for people to enable it by accident.
I can point you at a few things you could do if you wanted to pursue this:
2) granularOverrides allows you to enable/disable individual protections for a given website.
If you wanted this, you could go read https://docs.google.com/document/d/1FywogzvkWupoUoz4PcCp9nNd... ; then made an extension that made it easy to edit granular overrides (you couldn't directly set the preference, but you could produce the json you could copy/paste into the pref). You could do stuff with lists if you want. (Somewhere there was a FF fork that had a pretty impressive granularoverride list itself...) You'll be in this awkward spot where you don't have all the permissions to do what you want to do directly, but you can get yourself about.... 40 - 60% of the way there?
I would like to find a way to support power users while not making the problem worse (In https://ritter.vg/blog-telemetry.html I describe that the 'confused users think FF is broken' problem got so bad management wanted to just disable RFP entirely, but I was able to show that these users are a very vocal minority and the problem is not as bad as it seems) while also not giving myself a maintenance burden but... maybe there a path forward where this dev extension - that can do things normal extensions can't - could potentially get more functionality...?
I'd lump Mozilla into the bucket since it's a nonprofit and open source, it's hard to come up with an objective list of what makes an org "good" so sometimes it's been useful to fall back on the fact that at least in the states, academics are bound by the IRB.
> Ultimately most fingerprinting technologies use features that are intended behavior
Strong disagree.
> IP address/cookies/useragent obviously are useful
Cookies are an intended tracking behavior. IP Address, as a routing address, is debatable.
> Canvas/font rendering is useful for some web features
These two are actually wonderful examples of taking web features and using them as a _side channel_ in an unintended way to derive information that can be used to track people. A better argument would be things like Language and Timezone which you could argue "The browser clearly makes these available and intends to provide this information without restriction." Using side channels to determine what fonts a user has installed... well there's an API for doing just that[0] and we (Firefox) haven't implemented it for a reason.
n.b. I am Firefox's tech lead on anti-fingerprinting so I'm kind of biased =)
The thing is, technology is either enabling something or not. The exploration space might be huge, but once an exploit is found, the exploitation code / strategy / plan can trivially proceed and be shared worldwide. So you have to deal with this when you design and patch systems.
Example: preserving paths in URLs. Safari ITP aggressively removes “utm_” and other well-known querystring parameters even in links clicked from email. Well, it is trivial to embed it in a path instead, so that first-party websites can track attribution, eg for campaign perfomance or email verification links etc. In theory, Apple and Mozilla could actually play a cat-and-mouse game with links across all their users and actually remove high-entropy path segments or confuse websites so much that they give up on all attribution. Browser makers or email client makers or messenger makers could argue that users don’t want to have attribution of their link clicks tracked silently without their permission. They could then say if users really wanted, they could manually enter a code (assisted by the OS or browser) into a website, or simply provide interactive permission of being tracked after clicking a link, otherwise the website will receive some dummy results and break. Where is the line after all?
In this context "a unique fingerprint" means that your fingerprint does not match any other user's. When you visit Site A and B you give a fingerprint X that is the same on A and B but no one else on the internet has ever sent.
In contrast a randomized fingerprint mean when you visit A you have a fingerprint X' and on B you have a fingerprint Y' and no one else on the internet has X' or Y' but A and B can't correlate you.
The protections we've put in place first try to do API normalization to make it so more people have a fingerprint X, and it isn't unique. And then they do API randomization so you use X' and Y'.
If a fingerprint goes to extra effort of detecting a randomized fingerprint, and ignore (or remove) the randomization, they will get the X fingerprint which - hopefully - matches many more users.
It's 'Suspected Fingerprinters' that controls the Fingerpritning Protection feature described in the blog post. But yes, naming and descriptions is hard and never seems to work.
But to disable it on a per-site basis, I would just disable ETP for the entire site. If it's a service or site you use frequently you probably trust them or otherwise have a login to them that makes trying to avoid fingerprinting illogical.
This is true, but adding a sandboxing to browsers has been a huge part in driving up the difficulty/cost of browser exploits, and driving down the frequency of their use.
And also we'll pay for a bypass of the wasm sandbox. (Actually, looking at our table, I'm going to try and get the bountyamount upped...)
He works (or recently worked) for Mozilla on security-related projects. The code commit fixing the issue was isolated to the /dom/ directory in the source tree, and Firefox does not support CSS Animation Timelines. The Animation Timelines code is not directly accessed by web devs, and it appears the only way to execute that code is via the JS API for Animation Timelines. I'm not a web security expert, but the signs seem to point to him being correct.
The breadth of responses here about people who can't reproduce this (or can) is one of the most frustrating things about working on fingerprinting protection. I also cannot reproduce this behavior, and have to assume that there is some complicated, behind-the-scenes risk assessment that is being done and some people trigger it and some don't. If any Cloudflare devs want to chat, I would love to. While not a normal way to contact us (support requests will be ignored), I can be reached at security@mozilla.com
reply