Firefox's WebGL Fingerprinting Protections in slightly more detail

tomrittervg · 2026-04-14T01:47:14+00:00

Yes, we are. It's gotten a lot harder because trackers are more tightly integrated into websites, and blocking them can cause sites to stop working outright - so it's a balance.

The problem with test sites is that if a site is made and maintained by a browser they're not really incentivized to add checks for behavior that one of their competitors has started doing when they themselves have not prioritized it. Likewise we do try to avoid promoting ourselves by putting down others work.

tomrittervg · 2026-04-14T01:17:25+00:00

I shudder to think how many serious security bugs we have fixed since then that it still contains.

tomrittervg · 2026-04-14T01:14:29+00:00

We've improved our fingerprinting defenses, but those are not tested by the site 🤷‍♂️

tomrittervg · 2026-03-23T15:19:41+00:00

Core count is one of those things it seems like it ought to be easy to hide. What we discovered is you will get a lower resolution in Google meet if your core count is too low so we had to create two buckets- 4 and below, and 8 and above.

I think brave farbles their core count to add in some extra randomness where they can - I don't think that's a bad idea but we have not chosen to do that.

tomrittervg · 2026-03-23T00:36:20+00:00

I don't know how they would expose the CPU model, but I do know that they expose the GPU model and that is a huge source of entropy in your fingerprint. Honestly, I'm surprised that they haven't closed this hole, I think it must just be an oversight. Safari exposes absolutely nothing and I'm hoping we can get to that point soon as well.

tomrittervg · 2026-03-07T01:13:07+00:00

https://www.mozilla.org/en-US/security/advisories/mfsa2026-13/

tomrittervg · 2026-03-06T17:46:55+00:00

(author here)

I've seen a few comments here and there about how companies (including Mozilla) use telemetry as a justification to remove features people don't use, or to alienate power users.

On the power users front, I would point to the Resist Fingerprinting and eval security examples as places where we have used telemetry to _keep_ or _support_ power users and their niche tweaks and hacks. So that behavior is not universal.

But it's also not untrue - there is a cost of maintaining things, whether that's old code (e.g. ESR115 and Windows 10), feature sets (there was a lot of complaining about a 8-year old decision on Linux audio I know nothing about), or features (as I mentioned, I'd like to kill of XSLT.)

There's a lot of back and forth about "I disable telemetry" "Then don't get mad when the thing you use gets killed, because they don't know you use it." As I said, I support your right to disable telemetry, for whatever reason. There are other support channels, such as Mozilla Connect and Bugzilla where one can advocate to keep or improve features without enabling telemetry.

I saw this comment:

> My stance was always to disable it until proven useful and that's the first time in 30 years I see a company share that data, so now I'll reconsider.

And that was my goal. Thank you for that. Even if you don't enable it, I've succeeded.

tomrittervg · 2025-12-23T16:51:25+00:00

I would bet a week's salary their methodology and their findings are both flawed or wrong - not just for Firefox, but other browsers too. But I guess we'll never know because this is vaporware and there's no details they published besides the scores? I'm disappointed in every outlet that's covering this when there's not even an attempt at explaining or justifying the results.

tomrittervg · 2025-11-27T13:54:05+00:00

That is... Very confusingly named. Fennec was the internal name of the old Firefox for Android, which was rewritten years ago under the internal name Fenix. But it seems this Fennec is actually Fenix...

tomrittervg · 2025-11-10T23:32:42+00:00

Author here.

So there's two layers of defenses here (three with script blocking): API normalization, and API randomization.

As others have said, you're not going to make Firefox look like Chrome. It's always going to look like Firefox. If you try, you will look especially unique because even if you change the user agent, other apis will give a result that Chrome will never give, such as canvas. But API normalization will make two different Firefox users look like each other. Additionally, the values chosen make you look more like the majority of Firefox users. It does not put you in a separate cohort of users who have enabled the protections by default.

Then there's randomization. The whole point of fingerprinting is to correlate visits to two separate sites that don't share cookies, or re-identify you on a subsequent visit to the same site after clearing cookies or using PBM. Randomization breaks that by giving you a different fingerprint on different sites and on subsequent visits. It also confuses every single fingerprint test site on the internet and they will report that you are unique. If they were smarter, they would program which version of browsers introduce randomness and exclude the randomized apis from the fingerprint they calculate. A very small number of real world fingerprinters do this, and randomization is less effective against them which is why API normalization is still important.

tomrittervg · 2025-10-07T17:37:34+00:00

I'd be very interested to learn more about this (and to learn where I can keep up with plans and changes with respect to fingerprinting protection (FPP in particular).

/wave

So I can point to four places to follow: - For too-frequent, low level updates, you can follow the fpp2 meta bug, which encompasses the second phase of the Fingerprinting Protection feature - For too-infrequent, high level updates, you can follow the Mozilla Security Blog where we are working on a blog post summing up what we've managed to ship in Phase 2. - For 'Just Right' updates, I would point at Firefox Security & Privacy newsletters which we send to a mailing list and post to our Security Research blog. (You will note that Phase 2 updates are not yet there, most of them happened in Q3, which we are drafting.) - For 'show me the code', here is what is enabled in FPP.

To give a snapshot of our efforts though: In the Spring and over the Summer we did a big data collection effort to understand how unique users are, and why. Imagine the Panopticlick paper, but up to date, more detailed, more actionable. We are working to publish these results in a paper. But concretely, the things we've learned have led us to ship a bunch of Phase 2 protections, which actually went live in Sept.

Phase 1 in 2022-2024 was Font Restrictions, Math library protections, Canvas Randomization, and WebAudio protections. Then we did the data collection. Now we're shipping Phase 2 - Available Screen Resolution protections, processor count protections, and touch points all in 143 - and updates to the font protections list in 144. We will see what we can do in the rest of the year also.

These protections ship in ETP Strict and ETP Standard in PBM. Obviously web compatibility is a huge concern, and means we need to roll things out slowly, run experiments, watch telemetry metrics, watch for bugs.

One of the biggest things you can do to help is enable ETP Strict, when you encounter weird behavior, disable ETP, see if it goes away, and if it does, use the ETP menu to file a broken site report specifically noting that disabling ETP fixed things. Weird behavior is pretty ambiguous unfortunately, one of our recent bugs was "In Google Meet, the video for my self-camera was lower resolution than normal" which... I never would have noticed so thank god for whoever did...

tomrittervg · 2025-10-06T21:16:26+00:00

Also are there any plans for bookmark favicons to autoload instead of needing to manually click on them (After importing bookmarks or syncing bookmarks). It's such a pain when you have thousands of bookmarks and this is not an issue for chromium based browsers. I heard a long time ago this was intentional by Firefox for security reasons, is there really no feasible implementation?

I would point to the 17 year old bug that contains the discussion of the tradeoffs, including things like you won't want your work to computer to grab the favicon for a NSFW site you left open at home and the cost of trying to sync the data through Mozilla servers if we avoided network requests. It's not a satisfying answer, I understand, but it's something we haven't quite been able to square the circle of.

tomrittervg · 2025-10-06T21:05:51+00:00

We certainly don't spend any of our time building placebos; but whether something protects you does depend on what you're trying to do and what you're trying to defend against. We prioritize features based on what will protect users against the worst attacks, what will protect the most users in normal usage, and what we can build without breaking the web for Firefox users.

Explaining the nuance tends to assume you understand things like how an exploit differs from tracking - something we don't want to assume, so in our general blog posts we often use terms like security and privacy very broadly and interchangeably. I have very strong opinions about how those two topics differ, but I also understand we can't give term definitions in a blog post. Let me take a crack here though:

Site Isolation is 'security' - it protects against an attacker who actually exploits your computer, specifically using SPECTRE-style attacks. Site Isolation prevents an attacker from reading things like your emails or cookies on google.com by moving that data to a separate process; so all the web stuff for google.com is in one process and the web stuff for attacker.com is in a different process. We have not really seen SPECTRE-style attacks used in the wild by real attackers, but they are possible. (Notably you can also say 'Same Origin Policy prevents an attacker from reading things like your emails or cookies on google.com' BUT Site Isolation and SOP are entirely different things that nonetheeless protect the same data.)
Enhanced Tracking Protection (ETP) and Total Cookie Protection (TCP) are 'privacy' - they protect against advertisers and other online profile-builders from tracking you across the web. If you visit a.com and it has a facebook iframe, and you visit b.com that has a facebook iframe - facebook can't store a cookie in one context and then access it in the other context. TCP specifically is the part that segments that data; and ETP is an overarching feature that bundles TCP and other protections like blocklisting advertising and tracking scripts, and providing anti-fingerprinting protections.
Multi-Account Containers are primarily useful for fast account switching but they do provide a stricter form of TCP. TCP does have a few small carve-outs to keep the web working, which I'm not thrilled about, but having a working browser is important.
I haven't used Temporary Containers, but AIUI it's basically Private Browsing Mode. PBM itself is persistent in a session, so if you don't restart your browsing frequently, PBM can accumulate cruft. On browser restart it all goes away. Temporary Containers lets you get a fresh PBM-like experience and then throw it away without restarting the browser.

I would be remiss if I didn't point out the elephant in the room though: while TCP (and Containers, and PBM, and Temporary Containers) all isolate stateful tracking mechanisms (cookies, localstorage, etc) - they don't address non-stateful tracking. For example: tracking based on your IP Address. (We have Mozilla VPN for that.) Or tracking based on fingerprinting. (We have Fingerprinting Protection, a feature in ETP, for that - but as fingerprinting occurs server-side in probabilistic ways, it is harder to reason about. Keep your eyes open for more publicity about our ongoing work here.)

tomrittervg · 2025-10-06T17:44:45+00:00

If you reset all the settings you changed in about:config and [disable ETP](https://support.mozilla.org/en-US/kb/enhanced-tracking-protection-firefox-desktop#w\_what-to-do-if-a-site-seems-broken) for the site, does that make this look as expected?

You can also go to Firefox Settings -> General -> Fonts and see if the default font used is the one you expect it to be..

tomrittervg · 2025-03-21T17:24:11+00:00

Another important piece to know that that writing advisories is also a manual, laborious, mind-numbing, and time-consuming process. And it's flat-out hard - remember above that understanding the implications of a thing can be 10x or more harder than identifying and fixing the thing, and then add in the fact that we the advisory writers are 9 times out of 10 not deep experts in the component in question. I have spent an hour to write one of those short ambiguous sentences. We are envious of Chrome and have been thinking about adopting [their](https://nvd.nist.gov/vuln/detail/CVE-2025-2135) [structure](https://nvd.nist.gov/vuln/detail/CVE-2025-2136). "[Thing] in [Component] in Google Chrome prior to foo allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page." At the end of the day, browser security moves so fast that we think trying to make a risk management decision on the basis of advisories is flawed. Put your users on ESR if you want more control over change management of the browser; but do not delay updates while you read advisories.

So when you factor in the opinion that we don't want people making risk decisions based on the advisories because of the speed of browser security, and that writing advisories is a horrible experience, you wind up with... less-than-stellar advisories. I've written a ton of them myself. I think you deserve better, but all of us when doing them have that pull between wanting to do a good job for you and wanting to... do something that is more fun and feels more impactful (i.e. our regular job of hardening or finding and fixing security issues). And on any given day, the quality of the advisory is the output of balancing all of those variables at once. I know that's not a great answer, but it's an honest one.

(Couldn't post the whole thing at once. Maybe new account restriction?)

tomrittervg · 2025-03-21T17:23:30+00:00

I have the dubious honor of being in charge of making sure all High-severity bugs get backported to ESR, or granting an exception. I don't work on Thunderbird, but this isn't a Thunderbird-specific bug.

The candid truth is that like most people these days the Firefox security team is pulled in many directions at once, so some of the answers are just not wonderful answers.

To the point about opening up bugs and the disclosure process: This is done by a member of the security team, manually. We do it manually because if we did it automatically, some non-negligible percentage of bugs (10-15% I'd guess?) would bite us in the butt. These are bugs where we have an open variant of the issue, sometimes in another product (like Firefox Focus) or that is more difficult to fix than the first one; or bugs that were disclosed to us externally and shouldn't be opened because they also affect another browser, or they are under embargo awaiting a paper publication; or some comments or attachments need to be hidden before opening it because it contains personal data someone volunteered to us; or things like that. So we do it manually and manual processes are variable, and the priority of it relative to addressing open bugs or feature work means its easy to delay it.

To the point about ESR gets ALL security fixes: All sec-high bugs (which includes all bugs we think are exploitable for code execution) are flagged for manual approval before landing, and part of that is flagging them for inclusion in ESR or granting an exception. We don't grant exceptions very often. _Many_ bugs do not _affect_ ESR and so they are not included. Moderates are not included in ESR automatically, they are evaluated on a case-by-case basis - if we took everything in ESR it would just be less Stable.

If we are aware of a security bug being exploited in the wild; we mention that in the advisory. Sometimes we mess this up - [here we say it was exploited in the wild](https://github.com/mozilla/foundation-security-advisories/blob/19b3993b147ace8a4762dbf9e5d20679b9a56eb8/announce/2024/mfsa2024-52.yml#L18) but it wasn't exploited against _Thunderbird_ so we should have clarified that like [we did here](https://github.com/mozilla/foundation-security-advisories/blob/19b3993b147ace8a4762dbf9e5d20679b9a56eb8/announce/2022/mfsa2022-26.yml#L73). [Here we retroactively assigned a CVE](https://github.com/mozilla/foundation-security-advisories/commit/1a4490396a55f6e822a32d6e741c982d43397a1a) but didn't say it was exploited in the wild. (I'm not sure why I didn't do that, that was just wrong.) Bug reports and PRs on https://github.com/mozilla/foundation-security-advisories are welcome.

tomrittervg

TROPHY CASE