Firefox's protection against fingerprinting
support.mozilla.org
support.mozilla.org
I did some research whether it is possible to stop fingerprinting using a browser extension that patches JS environment before loading the page, and it turns out that it is difficult or impossible. Because first of all, there is no API for patching a JS environment from an extension.
I think that many of new HTML standards are poorly designed in regards to privacy. For example, WebGL reports the video card that you use. Who needs that? Well, maybe there is a tiny percentage of sites that use this information to detect bugs but main use of this feature is a reliable unforgeable signal for fingerprinting a device. Most of sites do not need WebGL at all.
It seems that browser vendors hurry to push forward as many features as possible without much thinking about user's privacy.
So basically today we have lots of standards that provide signals for fingerprinting (Web Audio, WebGL, Canvas API, WebRTC, port scanning via fetch or websocket, probing extensions list) and zero APIs or settings that allow to control it or block (unless you are ready to patch a browser).
WEBGL_debug_renderer_info is an optional extension to webgl specifically so it can be denied to the page at the browser's discretion. And Firefox's privacy.resistFingerprinting (the subject of this article) disables it: https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_debug...
Vendors in plural makes it sound like the market isn't a monopoly of Google at this point. Google naturally loves to be able to fingerprint people based on as many metrics as possible, for their ads.
[1] https://www.khronos.org/registry/webgl/extensions/WEBGL_debu...
Video cards behaves wildly different between vendors. Some shader runs smoothly in one vendor while lag like hell in another. And some don't even run correctly under certain vendor. Without knowing the vendor, it is not possible to patch them up to get a usable program.
They share the same API doesn't mean they behave identical.
2) WebGL is being used for a lot more than just 3D objects now -- it's used for everything from 2D games, graphing libraries and even webgl-accelerated machine learning in the browser (like tensorflow.js).
They should be asking nicely, not getting it for free.
They are more about buggy layout (not the shiny grid layout or style worker, it doesn't even works correctly with css2 a lot of time), incorrectly implemented API (not the 'not implemented due to privacy' one, they are those implemented but reporting wrong result).
Firefox also rejects a lot of proposal due to security reasons. But for every one it supported, it works correctly. Instead of work in funny way and require devs to guess the browser and insert ransom workaround just to make it not using the improper result safari gives and breaking the page.
Fun fact: Safari doesn't even handle the full ISO8601 correctly until very recent version. A timestamp without timezone will be parsed into incorrect timezone. A timestamp without colon in the middle of timezone don't even be parsed(which is unfortunately go's default output format).
I guess that's why they have a explicit policy of prohibiting browser fingerprinting in all their ad business.
https://digiday.com/media/googles-opaque-practices-to-restri...
It adheres to web standards that it primarily writes and pushes through.
> We need to be holding the w3c accountable for considering privacy as they refine new rfcs for apis.
You know, when w3c does that HN is ablaze with "Safari is the new IE" and "Firefox is irrelevant". See all of hardware APIs (Bluetooth, Serial, HID etc.) that are rejected by both Safari and Firefox primarily on privacy issues.
It Is Difficult to Get a Man to Understand Something When His Salary Depends Upon His Not Understanding It
Follow the money, people in tech get their paychecks from companies that do not respect privacy. And I don't mean that as an accusation: in capitalism it is your duty to do whatever you can get away with.
For example, the AudioContext API allows websites with zero audio to query sensitive personalized information about your audio equipment, with no permission. It was written by a Google employee, and implemented first in Chrome, then abused throughout DoubleClick's (owned by Google) display advertising network.
Don't rubber stamp specs that aren't privacy-conscious; Apple, Mozilla, and Microsoft are WHATWG standards members too.
How do we do that?
Actually I think that when zoom is less than 100% (i.e. the page is made smaller) it is possible to report to the page original window size rather than scaled up size. Many sites today use gigantic font sizes and they are difficult to read without zoom or high-DPI display.
I don't think it does disable page zoom; I have privacy.resistFingerprinting set to true and can still zoom just fine. (It does disable per-site zoom settings, but you can still zoom any site to whatever size you want each time you visit—which is certainly inconvenient, but, well, the state of the web is such that you can choose convenience or privacy; Firefox giving you that choice does not mean that the necessity of choosing is their fault.)
Are you fricking kidding me with that? Sure 30 year old me could have read that as is, but why would I want to?
Basically anybody trying to do a high performance game in webgl. Even today, the quirks of individual cards are enough that a game relying on sufficient feature capabilities is going to need a quirks list of cards to substitute implementations on. There's nothing to be done about it if a card just lies about its capabilities in the gestalt API or has an honest to God bug that you have to work around in the shader.
But, if an API like that isn't behind a permission allow dialogue and is instead on by default, that's a major privacy mistake.
Instead game developers should provide an option to select graphic settings: more textures, less textures, more shaders, less shaders and so on, and display a FPS counter so that the user is able to decide what is better for them. Or automatically switch to lower settings if fps falls below cetrain threshold.
And my app isn't even all that complex. There are so many bugs to handle, but luckily Three.js handles the vast majority of them for me. You can't count on even very basic apps to be completely compatible across all devices.
Testing for bugs is fingerprinting - you are back at square zero.
But that's the problem. The developer has no power to make that happen. Between vendors failing to support their chips once they released to the public and users failing to upgrade their machines... Some of the Intel bugs are over a decade old.
This is one of those network effect problems not unlike the question of whether a website is broken if it doesn't work under Firefox. If a game doesn't work on a user's computer, the game is broken, not the computer.
This whole conversation has raised an interesting point, because bugs like that will never be fixed in the driver. And similarly, different versions of web browsers have different quirks and bugs in their implementations. I suspect you could build quite a fingerprinting profile by tickling those bugs and quirks... Not just in the webgl implementation, but in the DOM implementation, etc.
But you're right, in practice a lot of engines do both... They render a known image at boot-up and check it for consistency. But once you know you have a problem, you don't know how to solve it, so you might as well query the card anyway.
If you really want to get your blood boiling, Vulkan since day 1 has had an application info struct which gets passed down to drivers, so drivers can work around application bugs and optimize for their specific loads! https://www.khronos.org/registry/vulkan/specs/1.3-extensions...
I mean, I'm already logged into the site; I have already given them my name, password, etc. So what am I trying to hide from them??
edit: wording
https://old.reddit.com/r/firefox/comments/q9kql8/help_settin...
I've been trying to get slack to show the current time on messages.
does it just hardcode GMT?
I suppose there's no field to enter these domains beforehand but I don't really run into any trouble because of this feature.
I'm all for anti-fingerprinting, but i'm also for interactive graphics on the web, and getImageData() is essentially your way of accessing a pixel buffer... I would be better if it was more conditional.
e.g instead gate the call that ultimately attempts to send any derivatives of that data over the network - although I understand that may entail significant complexity in the JS engine. Alternatively, gate getImageData() only if fingerprintable context methods have previously been called, i.e those with antialiasing, compositing, blending differences etc or any other rendering method with potential differences emerging from the underlying algorithm. That way someone just trying to use the pixel buffer as an output doesn't get punished by needlessly causing modals to be thrown in front of the user.
I'm sure it's a great feature when you need it, but most websites have no legitimate need for it. Having this sort of feature off/blocked by default and whitelisted on a case-by-case basis makes a lot of sense to me. Are you trying to use a webapp image editor? Makes sense to whitelist it. Are you trying to read a local newspaper article online? Keep that shit off by default.
In fact, that's how I treat even first-party javascript, because most websites are made worse by turning javascript on. It seems to follow a 90-9-1 rule; 90% of websites need no javascript, 9% need first-party javascript whitelisted, and 1% require some 3rd-party javascript.
You - as a developer - probably know that an image editing site might need this permission and other sites don't. The average user has zero (ZERO) clue.
They don't know, they don't really care. Instead they arbitrarily accept or deny based on how scary the popup text is, or how annoying it becomes, or how much they depend on the site.
Which is pretty terrible from all perspectives
- Users get prompts that require decisions that they don't have the knowledge or context for.
- Valid sites & businesses lose traffic because some users are scared away by scary sounding prompts that they don't understand.
- Malicious sites still get a broad swath of data on users who don't give a rats ass about the prompts and have been conditions to just always hit yes.
I think this style of implementation is basically always indicative of a failure.
https://brave.com/privacy-updates/4-fingerprinting-defenses-...
Isn't it pretty obvious? Generate the same image 1000 times and take the median pixel value for each pixel to get the "real" image.
The problem I forsee with getImageData() and gl.readPixels() is that despite all this security, it's possible that it leaks some data through the openGL implementation, like with a spectre/meltdown type attack. Like imagine there is some cached data on the GPU that lingers between draw calls, I don't know.
Things will break in unexpected ways, while web developers are the ones expected to spend their time offering support for a browser that has been rendered broken.
They need to be very careful about how these features are presented, and evaluate how they affect the entire web ecosystem.
It's hidden behind an about:config option (rather than being in the settings page), and the linked article literally says "It is likely that it may degrade your Web experience so we recommend it only for those willing to test experimental features". What more do you want?
Inform users when they silently pass garbage through web APIs such as HTMLCanvasElement.toDataURL(), when it happens. And the UX of that should also be very carefully considered.
Otherwise you might end up with some critical document scans on a government website being uploaded as striped nonsense images without your knowledge, and the "may degrade your Web experience" that you glanced over a year before when you enabled the option may not cut it when your Visa application is delayed or rejected.
I use a different (from my regular privacy optimized) unmodified browser for such websites and use cases.
While this is clearly not a perfect solution, I also subscribe to the adage[0], that “perfect is the enemy of the good”[1]
[0] https://www.thefreedictionary.com/adage
[1] https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good
>[...] when your Visa application is delayed or rejected.
Isn't that what the prompt (pictured in the article[1]) is for? It doesn't always show up, but AFAIK it only does that when the page tries to grab canvas data before the user has interacted with the page. For a page where you're uploading documents, that seems unlikely.
[1] https://user-media-prod-cdn.itsre-sumo.mozilla.net/uploads/g...
Right, it can auto-decline it in certain circumstances. As the name suggests, it auto-declines it when there there isn't any user input. That seems fairly reasonable to me, and is unlikely to cause issues with you uploading documents for a visa application (you need to interact with the site to upload the document in the first place). That said, I was playing around with it using various codepen demos and discovered that even if you interacted with the page, if the page was in an iframe it would always not show the popup. That might cause issues in certain circumstances and I do hope it will get fixed.
>and even then they shouldn't serve fake data when the user declines the request, but throw an error for the API call.
Whether that's the best approach is debatable. For the use case of uploading a document, I agree that would be the best behavior, but for other cases (ie. it's trying to display something), an exception would likely crash the app. In many cases (eg. google maps), the garbage data doesn't interfere with my use of the app, and crashing the app would be far more disruptive.
This would prevent problems but I don't think it can cope with the number of requests in the normal flow of web browsing.
I'm presuming you want the browser to somehow detect whether the garbage image data ends up in a POST request? I don't see how you can implement that in a reliable way, considering there are dozens of ways to go from canvas data to a POST request.
2. The linked blog posts already lists the things it does (although it's non-exhaustive)
I just noticed there is a "Show only modified preferences" which is wonderful. It shows me uhh.. a few hundred things I haven't changed myself.
I really can't remember what I've changed.
(5 minutes later)
I remembered, last time I've looked the about:config right click context menu was replaced with the rather useless default webpage menu. Kinda funny as I was looking to disable dom.event.contextmenu.enabled
Putting "enabled" and "disabled" behind the preferences feels kinda silly. It would make more sense if the gui replaced true/false with disabled/enabled.
Like the webgl max texture size dropping to 2048. I wish they'd give that one a bump.
Maybe this will become available when they roll out more broadly with a configuration UI.
I think the main downside to this is that it hurts the people who do want the most protection. If 5% of people enable max settings then they have a reasonable set size. However if only 1% do and the other 4% opt out of a few options that is a dramatic privacy reduction for those users without anything they can personally do to improve it.
Not really, considering you can just check if the IP is a Tor exit node.
Before: One in 69970.67 browsers have the same fingerprint as yours. Currently, we estimate that your browser has a fingerprint that conveys 16.09 bits of identifying information.
After: One in 104957.5 browsers have the same fingerprint as yours. Currently, we estimate that your browser has a fingerprint that conveys 16.68 bits of identifying information.
So according to that, my browser is more fingerprintable after enabling the setting!
I didn't expect this experimental feature to be a silver bullet, but I certainly didn't expect it to make me more unique. I'm not sure what to think of that.
[1] https://addons.mozilla.org/en-US/firefox/addon/toggle-resist...
getImageData() is blocked - datapoint
Any detectable difference from what a “regular” browser would return is another point of entropy.
However, the accuracy of device fingerprinting with `getImageData()` is as far as I can tell a lot higher than the accuracy from trying to fingerprint people based on whether they're returning blank data from that call.
If turning off a feature reveals a new 3 bits of information, but leaving it on would have revealed 5 bits, then it's still probably a good idea to turn it off.
Again, not to say that people shouldn't care about those 3 bits, they should. But it's not necessarily a waste of time even if a site tries to use anti-fingerprinting as its own metric. It only becomes a waste of time if the anti-fingerprinting is more unique than leaving the holes open.
"Look at me: I'm the Chrome now."
Even things like the GPU make and model can end up necessary because the webgl mechanisms for determining those things are allowed to lie (i.e. I've seen cards that report in the gestalt data that they allow various features, when those features are in reality implemented in software and therefore basically unusable).
I'm really worried that we're going to head down the road of chrome becoming the only browser anyone tests their site against and we're going to go back to the bad old days of IE 6 compatible sites that are completely broken in other browsers.
It's like they're deliberately ruining the experience in everything but their app to feed their ever growing hunger for more user data. It's the worst website I regularly visit by a mile.
Incidentally the problem (bug? feature?) goes away if you have javascript disabled.
That in particular makes me nervous sometimes. If the implementation can't even run properly on other browsers, I don't want to know what other corners they're cutting behind the scenes.
If those numbers are right, Safari has about 5x the number of users. Realistically, Safari is our only hope.
Even for me for some stuff I keep on Chrome since its too connected to all the business/saas/hosting logins and etc.
I don't believe you can care about privacy with half your org being hyper-political lefty activists, and Mozilla seems to be infested with them. Having monitored the Firefox reddit for 2 years, FF devs & leadership are often at odds with FF users who are people who want privacy above all.
The way we're doing capability permissions on the web (to the extent browsers do it at all) is just broken. A barrage of piecemeal modal dialog boxes is not the way forward. It needs to be drastically simplified. A website should be treated exactly like any other kind of app: if it needs to use extended features, it should put that into a manifest so the browser can provide a specific list of items for the user to approve or reject.
If none of these permissions are given, sites should be extremely restricted in what they can do, including cookies and localStorage.
Let's get rid of UserAgent and codec compatibility headers. Especially UserAgent is already useless and both should be replaced entirely by an improved feature detection system.
There are only 3 major browser vendors left. They could fix this within months. This is not a technology problem, it's a question of will and ad revenue.
My personal concern with fingerprinting isn't so much any individual low-traffic site recognizing my browser. It's the higher-traffic sites working together to aggregate profiles. I don't need "zero tolerance" anti-fingerprinting. I just want to make it harder for big data aggregators to compile highly accurate, large population databases. Hopefully, a sweet spot can be found in testing which is minimally disruptive for typical users but frustrates data aggregator's ability to compile highly-lucrative data products across sites. I'd imagine just applying anti-fingerprinting to the 1,000 highest traffic websites might be enough to cut the profitability of cross-site aggregation significantly.
That sounds like brave/firefox's "tracking protection", which blacklists well-known fingerprinting scripts
>My personal concern with fingerprinting isn't so much any individual low-traffic site recognizing my browser. It's the higher-traffic sites working together to aggregate profiles. I don't need "zero tolerance" anti-fingerprinting. I just want to make it harder for big data aggregators to compile highly accurate, large population databases. Hopefully, a sweet spot can be found in testing which is minimally disruptive for typical users but frustrates data aggregator's ability to compile highly-lucrative data products across sites. I'd imagine just applying anti-fingerprinting to the 1,000 highest traffic websites might be enough to cut the profitability of cross-site aggregation significantly.
What counts as a "low-traffic site"? how would this work with tricks like CNAME cloaking?
Although, ultimately my opinion is this is a legal problem. The entities that are a threat to my privacy that also use fingerprinting operate within the boundaries of criminal law.
I’d also love to see interoperability with history, keychain, and bookmarks with other browsers. Would make it far easier to switch between.
Any idea how this works? Can you still set your browser window to any size you want in your window manager, does it misreport it? Could that not cause rendering issues too?
1. by default, any non-maximized windows will default to a 1000x1000 viewport. This is consistent with how the tor browser works. Of course, this doesn't do anything when your window is maximized. On tor browser they warn you not to maximize your window for this reason. The idea here is that if everybody's window is 1000x1000, you won't be able to fingerprint based on people's monitor sizes, OS decoration sizes, and the user's window size preferences.
2. you can optionally enable a feature called "letterboxing", which rounds the viewport size to multiples of 100px. This works even if you maximize/resize your browser window.
> Your timezone is reported to be UTC
> Not all fonts installed on your computer are available to webpages
> Your browser reports a specific, common version number and operating system
> The Media Statistics Web API reports misleading information
It _does_ break some websites, but I just use another browser for those one-offs.
1. you're forgetting about other fingerprintable features. the obvious one would be WEBGL_debug_renderer_info which leaks your gpu model. that might be fine if you're running intel uhd graphics, but for someone with high end discrete graphics it's quite revealing. There's also more[1]
2. what if you don't have a 1920x1080 monitor? if you have a 1440p or 4k monitor, then what? JS APIs allow you to get both the viewport size as well as the monitor size. That's going to make you stick out as well. You can try to mitigate this by running in a VM, but then your GPU model would show up as "VMware SVGA 3D" or "Virtualbox Graphics Adapter", which also makes you stick out like a sore thumb.
I guess that's true in the abstract, but the more fingerprinting vectors there are, the easier it is to identify a specific person. The best case scenario is something like the iPhone, where each model behaves identically and there are limited amount of user-configurable settings, such that there are tens of thousands of people in your city alone that have the same model/settings (eg. timezone/dark mode on/off). You can do all the fingerprinting you want, but for a medium traffic site you're probably still going to get hundreds/thousands of users with the same fingerprint.
>The time of day you visit specific sites is enough to eventually fingerprint you.
How does this even work? If I'm on a VPN (ie. shared IP with hundreds of other users) and have total cookie protection (separate cookie jars for each site), it's effectively impossible to tell whether I'm one user visiting a dozen sites, or a dozen users viewing one site each.
I'd like to believe that all the other changes still contribute plenty towards obscuring the fingerprint, but there's no way I can adjust to manually having to resize the browser window every time I open a new one.
Of course, 1280 pixels should not be hardcoded, there could be a choice between several popular sizes.
I quickly close websites like that (and blacklist them in my pihole if they're particularly offensive in their messaging) but for people like me these protections do actually help.
I really wish Mozilla would address battery/CPU issues of FF first. I'm not an ordinary user, but I can see why many people would just pick Chrome/Brave/Safari if they realize FF drains their battery too fast.
Youtube and Chrome have the same CPU usage on my machine when playing 4K60 video (downscaled to 2K even for even more load). Tested on Firefox and Chrome using this video: http://ftp.vim.org/ftp/ftp/pub/graphics/blender/demo/movies/... (had to hack in a <video> element on the parent page to get it to play instead of download). Firefox uses about 150% of a CPU core, Chrome about 160%. CPU is a i7-7700k, GPU is a GTX1080 but I'm on Ubuntu so the latest Nvidia update probably broke something to get these load numbers.
Many bloated Javascript websites are slower on Firefox for sure, but video playback is one of those things it seems to handle fine (or, just as badly as their competitors do).
[1] https://palant.info/2020/12/10/how-anti-fingerprinting-exten...
I recognize that I'm probably in the minority for wanting to avoid web fonts in my web pages, to make my web pages more lightweight / faster / environmentally friendly. I prefer to use locally installed fonts, a.k.a. native fonts or system fonts. Unfortunately, this privacy measure may somewhat interfere with that, to an extent that depends on the details of how it's implemented.
I'll accept the privacy win, since surveillance capitalism and trackers also significantly increase bandwidth / energy usage and GHG emissions, but it's always sad when some efficiencies have to be discarded because we've turned the internet into a panopticon (or for other reasons related to humans behaving badly).
So WebGL/Web Audio/et. al. leak information about your system. What are you going to do about it? Argue that these sorts of features should be reserved for native apps and remove them completely, or hobble them to the point that they are basically useless? (At which point you might as well just remove them completely.)
Okay, let's do that. Let's force every WebGL developer to start making native apps instead. We do not have a write-once-run-anywhere platform for developing applications that is anywhere near as reliable as the Web. So now, developers need to massively explode their project configuration to build all the native versions of their app for all the platforms that were previously supported by their web app. Every new release of their project has to go through a walled garden approval process. Hope you aren't a doing anything Apple or Google don't approve of!
It was painful, but here we are: users aren't fingerprintable.
Wrong. It's even easier now. The native application platforms give the nefarious data collector so much more access to be able to fingerprint users. Hell, you are often readily given a unique user identifier by the app platform. Even if the user resets that ID, it's not going to bug you too much because you'll just re-fingerprint them and then be able to correlate the new data to the old. Oh, you're not allowed to do that by the platform ToS? How long does it take to catch you doing that? And do you actually get banned, or told to cease and desist in favor of purchasing the same data directly from the platform? It's so nice of Google to make suggestions on what not to do here, wink wink nudge nudge https://developer.android.com/training/articles/user-data-id.... How would they even know if you were bridging advertiser IDs in your own database completely out of their control?
And your browser sessions are still fingerprintable, too, because even the most basic of common information that has been transmitted to HTTP servers since day 1 is enough to fingerprint users.
You've succeeded in none of your goals to reduce fingerprinting but have harmed legitimate developers massively. All for what? Because of essentialist arguments about how the Web used to be?
The problem is not that application platforms leak data. We are walking, talking data leaks by our very nature of not being 100% literal clones of everyone else. Maybe in the 1960s you could walk into a shop and pay cash for something and reasonably assume that nobody was videotaping you and collecting your credit card number and storing all this information in a database, but that ship sailed a long time ago. The problem is that collecting this data, correlating it, colluding between other data collectors, and selling it off to the highest bidder is not regulated. Look at all the data breaches that credit reporting services like Experian have allowed to happen to them. All of this data is a potential weapon against users and it's just sitting around in woefully underregulated databases, everyone hoping the likes of Equifax know what they're doing (when they have demonstrated on several occasions they don't).
But browsers and web app developers. That's where we need to draw the line. Right.
For example, if we had a 3-tiered model, "basic", "web app", and "custom" that would solve most of the problems. For "basic", the browser acts like a featureless monolithic platform: no UserAgent header, no (3rd party) cookies, no localStorage, no advanced JS API, maybe even limited DOM access. Anything that needs access beyond "basic" would trigger a permissions dialog. "web app" would be full JavaScript, but no WebGL and only limited media support. And "custom" could be anything the website asks for, preferably in a manuscript file.
This would solve a whole host of issues, including security, for the most common cases. The number of websites that need to ask for more than "basic" is limited, at least as far as the typical user is concerned. Over the lifetime of a browser's settings profile that would probably be about 10 sites that need "web app" access.
It’s a fork of Firefox with security / privacy configurations set as default.
How very helpful, you extension! I'll wager this "feature" gets baked into all sorts of extensions :)
Fingerprinting is necessary for an open web to work.