GPU models also should not be given, browsers need to abstract features and performance into something else. Like if I'm writing a WebGL app, I should just be able to test a few baselines configs.
User agent is a tricky one, Chrome on Android gives too much info because it's built by an advertising company.
So no more ad blockers?
For instance, several versions of Firefox had a serious bug in shared workers, which appeared intermittently when users opened your site in multiple tabs https://stackoverflow.com/questions/51092596/feature-detecti... - I had to use the user agent to work around this.
Bundling into adblockers or browsers directly would help.
Chrome could change its header to the header of a competitor or a neural one, but has no reason to (Google's main business is delivering ads). For other big browsers like Firefox and Safari it would be a huge loss to change the header: they would vanish from browser market share statistics, and with that the business case to make websites work well with their browser dwindles. That in turn would reduce their actual market share. That only leaves the browser with a market share so tiny they are ignored by developers, and those browsers do often spoof the user agent header (or at least make it very convenient to do so).
You don't need the model to fingerprint it. It's performance is probably more than enough.
edit: also your comment seems to imply that plugins are used for websites trying to do something the browser doesnt support (ex flash) -- while this is sometimes done, most plugins add additional functionality for the user, ex adblockers, usability improvements, etc
The `navigator.plugins` used for fingerprinting is just for NPAPI/PPAPI stuff like Flash, Java, Silverlight. Just about all browsers are also in the process of deprecating support for them.
(it can also be possible to fingerprint browser extensions, but that is a bit trickier as it's not served up directly by the browser as a handy array)
The rest of these "attributes" are not HTTP headers, and occurs after the resource is fetched. We do not need to give away this information in order to retrieve the resource. The fingerprinting problem arises because the software we use to do the retrieval does far more than retrieve web pages. These other attributes cannot be detected unless the software used to retrieve the web page also includes other features that process what is retrieved, including a Javascript engine that runs code straight from the internet ("browser").
Looking to the authors of a popular browser to solve the problem they themselves have created. Is it rational to expect that this is where the solution will come from?
If one is willing to make some "useability tradeoffs" then one might use a simple http client to retrieve web pages instead of a popular browser. After the pages are retrieved, then one can use a popular browser to view them if desired; the browser need not have access to the internet. This is what I do. Not to avoid "fingerprinting" but just because it is faster and more robust.
With the help of a trivial program that transforms urls into http (I wrote one), one can retrieve the text/html of web pages, without requesting all the third party advertising cruft, with any tcp client such as netcat. HTTP pipelining becomes easy, making consumption of large quantities of information more efficient -- many pages, one connection. The two programs together form an "http client" with, relative to a popular browser, or even a program like curl, very low code complexity.
Whenever I see the "fingerprinting" debate come up, I always go through the same thought experiment: For situations where "fingerprinting" is a problem, web users all use the same simple http client. All send the same minimal headers. The web must accomodate users not the other way around.
Maybe if you have script disabled, but if you have javascript it's trivial to detect which browser you're on based on javascript implementation quirks alone.
>We do not need to give away this information in order to retrieve the resource.
You clearly haven't seen mandatory javascript sites.
You are making the assumption that I am using a browser to retrieve the page. I can use a simple http client with no features such as JS to retrieve the page. I have full control over what headers I send and the contents of those headers.
"You clearly haven't seen mandatory javascript sites."
I have seen many sites that prod the user to enable JS yet still return the same text/html even when JS is disabled. Sometimes I am only after the content of the page: text, URLs pointing to images or other resources, URLs pointing to other sites, etc.
I have seen some sites where there is "no content" in the initial page fetched, with or without JS enabled. These are dummy sites, hollow shells, skeleton pages. The technique is simply misdirection. All the useful content is pulled from another site via a second request (JS triggering the request). Maybe this is a CDN. I simply read the JS or use a debugger to find this "endpoint". Then use the simple http client to request the content as usual. These dummy sites are not the majority of sites on the web, nor even the majority of sites posted to HN.
The endpoints supporting these "no content", dummy sites often deliver the text with fewer or no tags, without HTML. Maybe it is JSON. This makes it easier for me to format it the way I like it. What many HN readers may perceive as a growing nuisance I believe could be a blessing in disguise. I prefer delivery of content in a more "raw" format allowing the user to process it as she pleases client-side, with the software of her choice. This leaves no room for advertising. It is more efficient and the user becomes the creative one, deciding how she wants to present the content to her own eyes.
If so, I want to shake your hand, sir.
For non-commercial use of the web, I use what I want to use. A simple http client and/or text-only browser.
My day-to-day use of the internet is almost always 100% non-commercial.
I never want to use a Javascript-enabled browser for simply retrieving information from the web. For example, reading. This is non-commercial activity.
For simple information retrieval, I find a large, complex, popular, recommended "browser", a single, "do-everything" program, is overkill and, counterintuitively perhaps, such browsers loaded with "features" actually limit what I can do. Using smaller, simpler "one-purpose" programs to retrieve web pages allows me more flexibiilty. I can be more productive.
Using single-purpose programs, I also find the retrieval process to be more reliable and robust, not to mention more transparent. I know exactly what I am sending. Unlike the popular browsers, these programs are not fetching and running code from the internet automatically. I feel a greater sense of control.
Canvases should never be readable by the other end without explicit permission. Basically transmitting anything rendered to a canvas should be equivalent to using my web camera from an integrity standpoint.
Time zone, operating system (from a short list) and language is fine, because it’s not a lot of entropy and my ip is known anyway unless on a vpn.
Gl renderer/graphics card, desktop resolution - nah. The viewport dimension is all that should be known.
Basically the browser should by default have an entropy budget for my entire fingerprint that ensures I’m not personally identifiable.
This could be fixed with a bit of courage. Firefox could use "Firefox", Safari "Safari," etc. UA sniffing and UA strings are completely absurd at this point, and need to go away.
> - List of Plugins
JavaScript should not see this, especially not their versions.
The last three are harder to avoid for "responsive" web design. One attribute you didn't mention was the font list. There is no good reason for JavaScript to be able to see this. The model should be that the page requests a font, and the browser uses either that or its best try at a substitute.
If Firefox tried that, it would instantly become that weird browser that makes Google look bad. The internet would be flooded with tips on how to set a custom UA that made it pretty again.
I just tried, and it's great! I had forgotten that search could be so snappy and simple. The more likely outcome, unfortunately, is that Google would adjust its UA-sniffing to serve the same 2019 bloat to "Firefox."
You can just measure performance of those things then.
Chrome on Android reports your phone model and build number. If you're using a lessor known phone with a carrier specific ROM, then you're in a really tiny population.
WebRTC is another one which you can disable. JavaScript, in general, as well, requiring uMatrix.
Chrome leaks the extensions you use, Firefox does not (AFAIK). As for blocking canvas, see [1]
To test your fingerprinting I can recommend IPleak [2]
The problem of this all is, its a usability nightmare.
[1] https://addons.mozilla.org/en-US/android/addon/canvasblocker...
Sure... "leak", wink wink.
If you use a common device and browser kept up to date to the latest versions, then you are not going to be unique. Using Safari on an iPhone will make you similar to 30% of web traffic.
Browsers also update all the time changing the user agent so it isn't that reliable tracking over extended periods of time.
The am I unique websites seem to compare your user agent to a database with outdated browser versions from the past data, making your score look much scarier than it really is. If you keep things up to date, chances are that you are not that unique.
Basically Canvas is a JavaScript API for programmatically drawing graphics and text. Subtle differences in color, font rendering, antialiasing etc will produce different rendering on different hardware depending on OS, browser, GPU, drivers, etc. This lets a site running JavaScript to generate a hash unique to everyone with your specific combination of software and hardware and uniquely identify you without cookies.
- User agent
- List of Plugins
- Screen resolution and color depth
- Canvas
- WebGL Renderer (~GPU Model)
Maybe Canvas can be fixed to a degree, but the others feel like things that will inherently be different. Firefox with the privacy.resistfingerprinting setting solves all of these at least partially (and more), but not without some usability tradeoffs.