A history of Fingerprinting protection in Firefox
Fingerprinting is a common technique used predominantly by advertising agencies and marketing companies to track people on the Internet.
Mozilla introduced the preference privacy.resistFingerprinting in Firefox 41 as part of the Tor Uplift project.
The official Tor browser is based on Firefox ESR; Tor Uplift aims to introduce patches that the Tor development team makes to the Tor browser to Firefox. See our article on Tor Browser privacy changes coming to Firefox for additional information on Tor Uplift.
These preferences are set to disabled by default usually as they may break things on the Internet.
Fingerprinting protection
Fingerprinting protection is disabled by default in Firefox as it may cause quite a few issues currently when enabled. Mozilla did enable some forms of fingerprinting protections in Firefox 67 using the browser's anti-tracking functionality.
Firefox users may notice, for instance, that they cannot install extensions on AMO using the default method thanks to the integrated User Agent spoofing in fingerprinting protection (Mozilla AMO reads the version of the browser as Firefox 52.x regardless of the actual version of the browser).
Firefox may also open in a different window size than the one when it was closed.
Firefox users can enable fingerprinting protection in the following way:
- Load about:config in the Firefox address bar.
- Search for privacy.resistFingerprinting.
- Double-click on the preference.
- A value of True means that the protection is enabled.
- A value of False that it is disabled.
Fingerprinting protection started with basic protective features, but changes in recent versions of Firefox added a significant number of additional protections to the privacy feature.
The Ghacks User JS team keeps track of these changes on the project's GitHub page. You find the most important changes and the Firefox version they are implemented in below:
- Firefox 41:Â privacy.resistFingerprinting added to the browser. (418989)
- Firefox 50: spoof screen orientation (1281949)
- Firefox 50: hide navigator.plugins and navigator.mimeTypes (1281963)
- Firefox 55: spoof timezone as UTC 0 (1330890)
- Firefox 55: round window sizes to hundreds (1360039)
- Firefox 55: precision of time exposed by JavaScript reduced (1217238)
- Firefox 56: spoof/disable performance API (1369303)
- Firefox 56: spoof navigator API (1333651)
- Firefox 56: disable device sensors (1369319)
- Firefox 56: disable site-specific zoom (1369357)
- Firefox 56: hide gamepads from content (1337161)
- Firefox 56: spoof network info API as "unknown" (1372072)
- Firefox 56: disable Geolocation API (1372069)
- Firefox 56: disable WebSpeech API (1333641)
- Firefox 57: spoof media statistics (1369309)
- Firefox 57: enable fingerprinting resistance for WebGL (1217290)
- Firefox 57: reduce fingerprinting in Animation API (1382545)
- Firefox 57: enable fingerprinting resistance for Presentation API (1382533)
- Firefox 57: disable mozAddonManager Web API (1384330)
- Firefox 58: prompt before allowing canvas data extraction (967895)
- Firefox 59: spoof/block MediaDevices API fingerprinting (1372073)
- Firefox 59: spoof keyboard events and suppress keyboard modifier events (1222285)
- Firefox 64: spoof/suppress Pointer Events (1363508)
- Firefox 67: enforce ui.use_standins_for_native_colors=true (1485266)
- Firefox 67: RFP letterboxing, privacy.resistFingerprinting.letterboxing and privacy.resistFingerprinting.letterboxing.dimensions (1407366)
Mozilla maintains an incomplete list of information that is blocked or spoofed on the company's support website.
You have granted the website permission.
Your timezone is reported to be UTC
Not all fonts installed on your computer are available to webpages
The browser window prefers to be set to a specific size
Your browser reports a specific, common version number
Your keyboard layout and language is disguised
Your webcam and microphone capabilities are disguised.
The Media Statistics Web API reports misleading information
Any Site-Specific Zoom settings are not applied
The WebSpeech, Gamepad, Sensors, and Performance Web APIs are disabled
The GitHub page lists reported issues and follow-ups as well as pending changes as well.
Closing Words
Fingerprinting protection is a unique feature of the Firefox browser (and compatible web browsers).
While it is undoubtedly possible to reach a similar level of protection with browser extensions, scripts, and modifications, it is good to see that Mozilla is pushing this privacy-enhancing feature.
It is not clear whether this will ever be enabled by default or listed as an option in the Firefox preferences though.
Now You: Do you use privacy add-ons in your browser?
Related articles
By the way, u wanna see some really great Offtopic Experience, which MUST u get a Smile on ur Face?
https://www.youtube.com/watch?v=A22oy8dFjqc
Go there and tell mee u NO like it,… enjoy just a Sequence in Life, which doesn’t make u wanna cry, this is awesome.
Greets, InGSoC.
Soohooo,
just retested FF Quantum vs. Opera Reborn, both Beta and Stable Version due to Websiteloading.
Faceboo:) FF up to 8 Seconds, Opera up to 3 Seconds, other Websites as well tested.
Result: I do NOT know what is wrong in FF???
.
Other Browsers tested, Google Chrome and Open Project Chromium, good results but lack of
personal Designfeatures, as Speed Dial and so on.
Staying on Opera as Mainbrowser, tested Stable, Beta and Developer Edition.
System is Win 10 Prof, Geforce 9400 GT, and Dualcore Processors, 2 GB Ram, Panda Online
Security as Antivirus,…..so it’s NOT an Up to Date
Hardware PC, but testing out Browser Performance, it should be eloquent enough.
Strange thing is that under same Circumstandings Browser behavoiur is so different?
How can that be? Different programming of Engines?
Hmmm.
Greets, InGSoC.
I love the idea of fingerprint resistance, but at this point it seems a bit futile. The screen size issue is a tough one to crack. The solution to that being explored in Firefox is entirely unacceptable to me from a usability standpoint.
I don’t know the technical details of this stuff, but if I understand what various FF devs have said, then there is no solution to this problem. I really, really wish that browsers simply did not report this sort of information to web servers at all. No screen resolution, no OS information, no nothing.
Unfortunately, that’s not going to happen. This whole issue feels hopeless.
Martin, I just posted (last 20 minutes) three or four replies before I realized I wasn’t logged in. Can you please make sure they get thru, as often they never do – thanks
Yes, should all be there. If one is missing let me know.
Thanks, they’re all there, 3 of em.
Instead of having to jump through hoops to get this setting working, or not, why not use the extension CanvasBlocker?
Also, to elaborate a little on this (using prefs & extensions in combo or instead of each other), with RFP, on the flipside, there are prefs that if you don’t have them at default, mess with various FP items. In the ghacks user.js they are in a section called RFP Alternatives (4600’s) although we stuck everything in there that was no longer needed (not necessarily those that impacted your FP). Every RFP patch needs to be looked at in isolation, as sometimes the RFP patch overrides the pref, and sometimes vice versa – and when the outcome differs (in some its very subtle), that’s when you can have a problem.
See the no longer maintained issue https://github.com/ghacksuserjs/ghacks-user.js/issues/222 for a little more insight
quick example; if you set “media.video_stats.enabled” to false this disables the API, and the RFP patch can no longer dynamically spoof actual values
Thanks for jumping in. Unfortunately, what you write is “Chinese” to me. Nevertheless, I looked at https://github.com/ghacksuserjs/ghacks-user.js/issues/350 and noticed your recommended strategy:
* set CanvasBlocker to fake. Do NOT set to block as this will disable the API and you will not get the same result as RFP.
* block sites when prompted: RFP takes over and CB is never used
* allow sites IF you must: RFP allows CB to take over which will fake
* use a CB whitelist for sites that MUST have the real thing
RFP = resist finger printing?
I have my CB set to fake, and get a notification each time a site tries to finger print.
“block sites when prompted”: where does the prompt come from?
“use a CB whitelist for sites that MUST have the real thing”: how does none know which sites MUST have the real thing?
My apologies for what are probably boringly stupid questions. If you decline to answer I fully understand.
There’s nothing wrong with using CanvasBlocker. I use it. But if you want to look like all the other RFP users in the future (when numbers get up and it gets more mainstream and is ready), then it would pay to behave like them (see Stuts posts above)
At the moment, I use CB to block, and since this disables the API calls (I think I got that right), then the canvas prompt never kicks in. But in 59 when it comes out in a couple of weeks, the canvas prompts will be reduced to only those that are “user-initiated” – see https://bugzilla.mozilla.org/show_bug.cgi?id=1376865 . This means that then I can change CB to fake and not worry about canvas prompt fatigue.
So, by default most canvas is auto-handled under RFP which will auto return a 10x10px white square. Those sites you get a prompt you can allow. Any site, you can override the permission in the site permissions panel. Then any canvas extraction you let thru RFP, CB can take over with a setting of fake, and in CB you can, if needed, allow a whitelist for sites that REALLY need it.
So extensions and settings can co-exist, enhancing each other. For more on that topic see https://github.com/ghacksuserjs/ghacks-user.js/issues/350
I’d like to use resist.fingerprinting, but don’t like how it makes the timezone UTC. The times are all off when reading webmail and also using other web apps. Is there a way to manually set the timezone?
Best solution would be for Firefox to translate utc to local time locally instead of letting the server know what time zone you are in.
Mozilla improvements are:
– Slow
– Create more Bugs than Improvements
– Are pushed only to appeal Tor Project.
There are indipendent 3rd party extensions that do this (and more) in a clean, honest a free way.
Free as in not-tracked.
Feel free to follow a dying project, the Mozilla Browser… it’s Time wasted.
Dying project? I think there market share has been going up, so not sure where you get your info…
@jupe Just ignore the trolls or the forum will degenerate into a debacle and get derailed – I mean look at some of the last few Firefox articles. I’d rather have informative and meaningful discussion about RFP than defend against Herr CCC’s ridiculous claims.
As for market share, I think they have stabilized, its a bit early to tell what will happen. I hope that the further quantum parts when they arrive for really noticeable speed gains (not benchmarks but real world) over chrome, and this, the push about privacy (when it’s finally ready for prime time) really make an impact. There was a study done by DuckDuckGo or StartPage about “privacy mode” / “icognito” and something like 83% of people thought that mode made them anonymous and kept them private. I can’t remember if there was a figure for people who said they would swap browsers for one that did, I should try and find that survey. So hopefully Mozilla will do some advertising etc when its ready, to really drive this point home, and get some real growth, because a strong FF is healthy for the browser/internet ecosystem.
Assumption: Please, commentators, do not start up about FF’s default settings (that can be tweaked for more privacy) vs some other niche browser/fork with those pre-done. They are different beasts with different needs, aimed at different users.
You’re wrong.
Add-ons cannot provide fingerprinting resistance because the amount of people using them is negligible, and because they do not offer an all-or-nothing protection, which is a necessity for a protection that actually works. Add-ons also can’t do certain things, yes even legacy add-ons, which is why Tor Browser is a fork and not just an add-on.
Add-ons are only able to provide privacy through reducing exposure, by which I mean blocking network requests. Since this is not practical for most people, and since a certain level of exposure is mandatory for all people anyway, fingerprinting resistance comes into play which allows you to expose yourself more without increased risk, assuming you can deal with your IP (e.g. IPv4 shared with many devices, dynamic IP, ProtonVPN or possibly in the future, Firefox Private Browsing mode since it might include the Tor client so that all Firefox users in PB mode can use the Tor network)
(In case that part wasn’t clear: Some spoofing add-ons exist but they aren’t able to reduce fingerprint entropy enough for fingerprinting protection to work, see first line of previous post. Some add-ons and about:config prefs disable certain web standards and stuff but again people are split into minuscule configuration groups. Protection requires significant market share and all-in-one protection, anything less makes it not work. When you can’t get it, reduce exposure though it’s partially voodoo unless you block like a nazi.)
@Stut – Yes. Thank you :) It requires a significant enough numbers of users (in the Firefox set of users) to all buy into the exact same “enforced” settings, albeit a few of them have variables (OS in UA, windows sizes), in order to **reduce** entropy in a real world scenario
I would also like to reiterate your point (which I think you made) that a lot of what has been done could only have been done within the application code itself. Extensions can and could not do half of this stuff: and some extensions that readers may think do the job (some UA spoofing items for example) are probably not aware that they leak like a sieve
One other point: Anti-FP’ing is a generally a last gap measure (in tests you are meant to assume the worst) – in other words, reducing your exposure, or the “attack surface” is always a good start (eg, blocking third party JS by default). That’s not to say there aren’t quite a few server-side FP’ing methods. So in the real world, a tightened browser with extensions and the end user’s habits can mitigate a lot of this – eg TBB with preset NoScript settings.
(By partially voodoo I mean that reducing exposure “but not too much” still has some efficiency, but it’s hard to evaluate so it can be overestimated or induce a false sense of security)
Hello,
resist Fingerprint is a nice Idea due to privacy settings, but the performance of thee actual Beta 59
is sluggish and Fullscreen Video in Html5 is also a Mess for mee.
I was fedup with FF last year and only came back to see Improvements in Speed.
Yes,there are Improvements but, for mee FF still sxxxs. I am on OPERA again, seems, for my
personal kinda View, thee better choice, cos of thee Addon Policy Control, which gives u instant
Access on Javascript and other important Features to allow or block, very fine to use
Greets, InGSoC.
I tried activating the resist fingerprinting setting in the latest firefox and waterfox. It caused the same problem in both. It shrank the active window size of the browser.
Okay, so having a 1440 by 900 screen size, I set the browser to use most of it (typically 1400 by 800) but activating fingerprint resistance shrank them to 1000 by 600. Returning the setting to false fixed the problem.
1) Nothing prevents you from maximizing your browser’s window or even going full-screen even when that pref is flipped out, 2) if you don’t want to be easily fingerprinted keep your browser size at the one that privacy.resistFingerprinting sets, otherwise you’re leaking a lot of info about your machine (window size).
Point 2 is very true. While inner screen measurements can be obtained without JS, the key here is to limit JS exposure thru eg uMatrix and setting JS off by default for all sites (1st party included). You’d be surprised how many sites (for reading, not logging in or being interactive with) work with just css and images. All we can do is mitigate as much damage as possible.
That said, I am hoping (and I will push for it) that since most FF users are desktop users, and most desktops are widescreen, and since that FF privacy study showed a massive abandonment of RFP due to “screen issues” (most would be the window size and perhaps not opening maximized), that tor uplift change the re-sizing algorithm to use better widths. I looked at the FF metrics for screen res, and they are not catering to something like 75% of potential users
PS: by the way, if you have the bookmarks toolbar visible, your resizing is out by 1 to 3 pixels (different results for diff people) anyway due to icon padding
The window resizing is probably the biggest turn-off. It sets an inner window of only 1000px max width, and on desktops that sucks.
Use the hidden overrides. Note that the size will be rounded down to 200’s in width and 100’s in height, so find the size you want. For example, I have a screen res of 1080×1650 (double height task bar). I have no FF side bar, so a I find the following works for me
user_pref(“privacy.window.maxInnerWidth”, 1400); // (hidden pref)
user_pref(“privacy.window.maxInnerHeight”, 800); // (hidden pref)
You’re on a smaller res monitor, but with these two prefs set to your liking, I am sure you can come up with something that suits
Thank you, I’ll try them out.
Martin, I have some eagle eyes (poor eagle)
Missing:
======
– 55 spoof navigator.hardwareConcurrency as 2 1360039
– 57 spoof media statistics 1369309
– 57 reduce screen co-ordinate fingerprinting in Touch API 1382499
– 57 enable fingerprinting resistance for WebGL 1217290
– 57 reduce fingerprinting in Animation API 1382545
– 57 limit MediaError.message to a whitelist 1354633
– 57 enable fingerprinting resistance for Presentation API 1382533
– 57 disable mozAddonManager Web API 1384330 (behind it’s own pref)
Incorrect:
=======
Canvas is FF58, not 57
Totally blanked out the Fx 57 changes ;)
FYI: in the https://github.com/ghacksuserjs/ghacks-user.js/issues/7 first post, under each major item, eg UA spoofing, there are subsequent changes listed with bugzilla links
eg: FF58: canvas prompts also lists the change in 59 where canvas prompts will be reduced to those that are “caused by user interaction”. By default, canvas will be spoofed, but you can still override canvas on a per site setting in the site settings panel. This will reduce the canvas prompt fatigue.
eg: FF56: UA spoofing lists a number of subsequent changes such as not lying about the OS, and the problems with ESR being 60 rather than 59, and the issue of Aurora/Nightly at times spoofing ahead of schedule (thus unmasking themselves as Aurora/Nightly)
So for those who want to know more and dig deeper, enjoy the list and links
> that they cannot install extensions on AMO using the default method
FYI: users can still install extensions, just right click on the “+ Add to Firefox” button and open in a new tab
Hmm , no edit button for me .. I see now that you already listed that in the article (I only did it earlier today as I am sick of reddit answers for this problem telling people to disable RFP)