Everyone talks about how evil browser fingerprinting is, and it is, but I don't get why people are only blaming the companies doing it and not putting equal blame on browsers for letting it happen.
Go to Am I Unique and look at the kind of data browsers let JavaScript access unconditionally with no user prompting. Here's a selection of ridiculous ones that pretty much no website needs:
- Your operating system (Isn't the whole damn point of the internet that it's platform independent?)
- Your CPU architecture (JS runs on the most virtual of virtual environments why the hell does it need to know what processor you have?)
- Your JS interpreter's version and build ID
- List of plugins you have installed
- List of extensions you have installed
- Your accelerometer and gyroscope (so any website can figure out what you're doing by analyzing how you move your phone, i.e. running vs walking vs driving vs standing still)
- Your magnetic field sensor AKA the phone's compass (so websites can figure out which direction you're facing)
- Your proximity sensor
- Your keyboard layout
- How your mouse moves every moment it's in the webpage window, including how far you scroll, what bit of text you hovered on or selected, both left and right clicks, etc.
- Everything you type on your keyboard when the window is active. You don't need to be typing into a text box or anything, you can set a general event listener for keystrokes like you can for the mouse.
If you're wondering how sensors are used to fingerprint you, I think it has to do with manufacturing imperfections that skew their readings in unique ways for each device, but websites could just as easily straight up record those sensors without you knowing. It's not a lot of data all things considered so you likely wouldn't notice.
Also, canvas and webGL rendering differences are each more than enough to 100% identify your browser instance. Not a bit of effort put into making their results more consistent I guess.
All of these are accessible to any website by default. Actually, there's not even a way to turn most of these off. WHY?! All of these are niche features that only a tiny fraction of websites need. Browser companies know that fingerprinting is a problem and have done nothing about it. Not even Firefox.
Why is the web, where you're by far the most likely to execute malicious code, not built on zero trust policies? Let me allow the functionality I need on a per site basis.
Fuck everything about modern websites.
Agree. No reason they should have this.
I can see a reasonable argument for this being allowed. Feature detection should make this unnecessary, but it doesn't seem to be fully supported yet.
This is clearly a break of the browser sandbox and should require explicit permission at the very least (if not be blocked outright...I'm curious what the legitimate uses for these would be).
Should probably be tied to location permission, for the sake of a simple UX.
Definitely potential legitimate reasons for this, but it shouldn't be by default.
As someone who uses a non-QWERTY (and non-QWERTY-based) layout, this is one I have quite a stake in. The bottom line is that even without directly being able to obtain this, a site can very easily indirectly obtain it anyway, thanks to the difference between
event.codeandevent.key. And that difference is important, because there are some cases where it's better to use one or the other. A browser-based game, for example, probably wants to useevent.codeso the user can move around based on whereWASDwould be on a QWERTY keyboard, even though as a Dvorak user, for me that would be<AOE. But keyboard shortcuts likeJandKfor "next"/"previous" item should usually useevent.key.There could/should be a browser setting somewhere, or an extension, that can hide this from sites. But it is far too useful, relative to its fingerprinting value, to restrict for ordinary users.
It's also simple presence detection. "You have a proximity sensor" is a result not every browser will have, so it helps narrow down a specific browser.
Operating system and CPU architecture are useful for sites to serve the correct binaries when a user is downloading an application. I know you could just give them all the options, but the average idiot has no idea what the difference between ARM and x86 is, or whether they have a 64 bit system. Hell, I wouldn’t even trust some users to accurately tell me what operating system they’re using.
This was the only one I could think of a good reason to track. I immediately thought of all the grandparents and tech illiterate people who'd probably implode if they had to pick .exe vs .deb vs .dmg/.app (I actually had to look up what MacOS uses...) vs etc. And don't even try to have them guess intel vs amd.
Automatically guessing the operating system saves us tech people from having to figure out they downloaded a file for a completely different OS.
Barely. You could trim down the data to incredibly low granularity ("OS: Windows", "CPU: Intel Desktop") and you'd still get the exact same binary as 99% of the people 99% of the time, anyway.
Oh yes, that's a very good point, actually. That actually seems such a fundamental use case that you could almost justify it being available without a permission.
No. It should be made available with a permission, because not every site out there is going to offer you to download binaries. 1% of the web """requiring""" this does not justify 99% of the web being able to violate that privacy.
Reread the comment you replied to. Not one word of it was in there accidentally.
Good catch. Still, doesn't make it true either: it's not such a "fundamental use case" that it would even require the capability. The browser already reports the usable information in the user agent (you rarely even in that 1% need more specificity than "Windows" on "Desktop Intel").
Plugins and extensions could make sense if the site and plugin are designed to talk to each other. But that could be made safer by each extension being able to decide whether to announce itself (and the user being able to override that).
Maybe, but I'd like to see a concrete example of how they are "designed to talk to each other" that couldn't be achieved by the extension just reading the DOM.