The question is how to do it tho, because some things might actually be useful: if your browser tells the site you prefer dark themes the site can react and display your prefered color scheme. If the browser tells the site how big your viewport is it can give you a site that fills that viewport neatly — and if the site can do these useful things it can also track you using that info.
I think it’s less true if you’re trying to play a game, look over a complex dataset, do high-end image previewing, maybe host a multi-party video conference, or other highly interactive application in a web browser (for user convenience and, to some extent, because users semi-reasonably trust browsers more than random app downloads).
There is actually no technical reason that an HTTP request needs to be any more than
GET / HTTP/1.0
There is no reason that the Firefox or Safari developers couldn't decide in the next version to send only bare minimal request headers.
> nc news.ycombinator.com 80
GET / HTTP/1.0
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Sat, 21 Nov 2020 13:59:31 GMT
Content-Type: text/html
Content-Length: 178
Connection: close
Location: https://news.ycombinator.com/ > openssl s_client -connect news.ycombinator.com:443
GET / HTTP/1.0
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 21 Nov 2020 17:25:28 GMT
Content-Type: text/html; charset=utf-8
Connection: close
Vary: Accept-Encoding
Cache-Control: private; max-age=0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Referrer-Policy: origin
Strict-Transport-Security: max-age=31556900
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/ https://cdnjs.cloudflare.com/; frame-src 'self' https://www.google.com/recaptcha/; style-src 'self' 'unsafe-inline'
<html lang="en" op="news"><head><meta name="referrer" content="origin"><meta name="viewport" content="width=device-width, initial-scale=1.0"><link rel="stylesheet" type="text/css" href="news.css?jacyibSTLtogl89kgrgw">
<link rel="shortcut icon" href="favicon.ico">
<link rel="alternate" type="application/rss+xml" title="RSS" href="rss">
<title>Hacker News</title>All that additional crud has probably contributed to the "relative ease" of conducting tracking as well as the "richness" of the data one can gather from tracking. Why should we ignore this simple fact.
The people behind these browers, especially Mozilla, keep assuring the public they are working to protect user privacy. This may be true to some extent but what they are not telling the public is how they are working to ensure the online advertsing industry continues to thrive, i.e., how they are working to ensure they do not upset the status quo. The words do not match the actions.
I would not rely on the browser developers to address this problem. To experiment with how well minimalism works on today's web, one can use alternative HTTP clients that allow control over headers and/or one can use a forward proxy one can remove/modify headers generated by the browser.
User A makes a single request to download bulk DNS data or Wikipedia content, then makes it available on her loopback or local network.
User B makes a series of DNS queries for specific RR's or HTTP requests for specific Wikipedia pages.
How do the behavioural fingerprints of User A and User B compare?
Trackers generally cannot see the individual DNS queries or HTTP requests for Wikipedia pages that User A makes over her loopback or to addresses on her local network. However all of User B's individual DNS queries and HTTP requests, including timings and context, are easily visible to a variety of trackers operating on the internet.
The basic principle of information theory is that these two things are exactly the same. There is no "correspondence" between them, they are one and the same thing. The amount of information that you send is, by definition, the measure of how unique it is.
I don't see how your reasoning about sending more or fewer headers fits into this; but anyhow the conclusion won't depend at all on the amount or the length of the headers, but on how many people are sending the same headers as you. It is impossible to know how much information are you sending by only looking at the bytes you send. You need to know the worldwide distribution of headers to measure that.
Your interpretation, which I think is correct in this context, seems to be with regard to the entropy of a probability distribution over internet users, and the mutual information between that and the distribution over messages. The actual length of the message is irrelevant to the math once you fix the joint probability distribution.
The argument others seem to be making is that the joint probability distribution is in fact not fixed, and that you can smear out the conditional probability over users given a message by shrinking the space of possible messages. In theory that seems possible, but I don't know enough to have any idea how well that would work in practice. If you shrank the message space to be small enough to be useful for this purpose, wouldn't that get in the way of usability?
This is not "my" interpretation, it's the standard definition of information content in computer science, as given [1] by Shannon in 1948 and used by everybody since.
[1] https://en.wikipedia.org/wiki/A_Mathematical_Theory_of_Commu...
Define the random variables M for message content and U for the identity of the user. The interpretation of "bits of information" that most people will have is H(M). The correct interpretation in this context is H(U). You seem to be confused about why people are talking about H(M) instead of H(U). But I think people correctly intuit that those aren't independent, so the mutual information I(U;M) = H(U) - H(U|M) is positive. And obviously if you change P(M), you will also change the amount of mutual information. That's why talking about sending fewer headers makes sense.
We should agree on common set of absolutely minimal necessary data (User agent, supported fonts, screen resolution and DPI if Javascript can probe those, etc) and then ALL run with the same, except on the very few sites one truly needs and which don't work with this bare minimum for some (hopefully valid!) technical reason.
We could actually package all of this into an addon or a simple recipe of settings. I'm not knowledgeable enough to pull such an effort with absolute certainty that nothing gets forgotten, but if someone does, I'd suggest "V for Vendetta" as a name, as it reminds me of the 5th of November scene.
Instead of asking "How do we become "non-unique""?
We could ask "How do we send less data to the parties who want to do tracking?"
For example,
User A sends 2-3 HTTP headers, the bare minimum, e.g., Host, Connection, maybe User-Agent or Cookie in some instances if required. User A has disabled Javascript unless she needs it.
User B sends a potentially unlimited number of HTTP headers (User B does not care to control the headers she sends, she just leaves that to the applications). User B leaves Javascript enabled regardless of whether it is needed.
Each user may be "unique", with sufficient effort from the party doing tracking, but there's an argument that User A is less interesting to the tracking parties than User B. Both users have footprints, both can be tracked, but one is sending much more data to the trackers than the other. She's leaving more detailed tracks, so to speak. User A is leaving a more generic footprint.
There is also an argument that finding "uniqueness" among a large group of "User B's" would be easier than amongst a large group of "User A's". If we were trying to achieve the impossible goal of "non-uniqueness" it would arguably be easier to try to have all users appear to be identical to User A than trying to get all users to match User B what with all the additional potential variables User B presents thanks to uncontrolled HTTP headers and Javascript's access to her computer's resources (and all the potential issues and "options" that raises).