That's already the case, isn't it? It's just that embedded parts by a 3rd party can set their own cookies, which can be read by the 3rd party whenever it is embedded in any other page.
1: https://en.wikipedia.org/wiki/HTTP_cookie#Third-party_cookie
You are calling all of the assets loaded, no matter from where, as one “website”. The person you are replying to considers each domain for each asset on the single page as being different “websites”
You can see which browsers partition state (and which don't) in the State Partitioning section of https://privacytests.org. Firefox passes nearly all of those tests because Total Cookie Protection is enabled by default.
I'm not sure what document.referrer blocking is meant to accomplish - if the intent is for the referrer to pass information to the loaded site then they can just include that in the url. If the intent is "don't let people know where you saw the link", then sadly there are plenty of sites that gate access on the referrer and they get broken. The fact that no one is filtering that kind of indicates the cost/reward balance.
Calling "media queries" a privacy issue is absurd: literally the purpose of these is to allow sites to tailor to the view format. More over you can directly measure these from JS, it's just less efficient and more annoying.
The "known tracker" blocking is more curious as I'm unsure how that's expected to scale, nor what happens if a browser ever misclassifies one (be it a resource or a query parameter). Certainly query strings can be trivially changed to make anything a major browser does just break instantly, and similarly trivially changed to not be statically identifiable.
I also wonder how those are tested because browsers that do automatic "learned" identification of trackers do take time to identify what they consider trackers and start blocking them. e.g. that site says google analytics is not blocked by safari, yet I can look at Safari's tracker stats and see that it has identified and is blocking google analytics.
The header at media queries says “Fingerprinting resistance”. Some data point like screenwidth doesn’t immediately disclose you identity. But having a few data points helps with fingerprinting.
That said, my point stands that the bigger "reputable" trackers (e.g. the ones that exist on basically every website) are all blocked by the learned trackers techniques, and so should be listed as blocked on that site.
>By default, Privacy Badger receives periodic learning updates from Badger Sett, our Badger training project. This “remote learning” automatically discovers trackers present on thousands of the most popular sites on the Web. Privacy Badger no longer learns from your browsing by default, as “local learning” may make you more identifiable to websites. You may want to opt back in to local learning if you regularly browse less popular websites.
-- https://privacybadger.org/#How-does-Privacy-Badger-work
The full writeup:
https://www.eff.org/deeplinks/2020/10/privacy-badger-changin...
GPC does differ from Do Not Track in that the former is intended to carry the weight of law. See for example: https://cheq.ai/blog/what-is-a-global-privacy-control/
Regarding document.referrer, you are absolutely right that there is a cost/reward balance and most browsers have chosen to allow cross-site passing of the referrer. However, there are browsers on Android that do block cross-site referrer altogether (see https://privacytests.org/android.html).
"Media queries" refers to the fingerprinting threat where, for example, screen width and height is divulged. You are right that JavaScript can also be easily used to get screen width and height: any fingerprinting resistance feature should protect against screen fingerprinting via both JS and media queries, in my view. Some browsers already do that, as the results show.
Your question about scale is a good one. Some browsers (such as Firefox and Brave) embed fairly large blocklists. You are right that query parameters can be changed, but in practice I haven't seen any cases of that happening (yet).
As far as I am aware, Safari is (by default) blocking cookies/storage from Google Analytics and similar trackers, but not blocking the scripts themselves. You can see that cookie blocking reflected in the "Tracking cookie protection tests".
Anyway, "the Web" can work in a more user-friendly, less advertiser-friendly way, meaning the user has more control over what DNS lookups are made, what HTTP requests are sent and what remotely hosted code, e.g., Javascript, is run. I know this because I am using it in such a manner every day. There is nothing in the "technology" underlying the web that prevents it. The practices that necessitate something like "TCP", the Mozilla acronym not the IETF one, stem from (a) the widespread use of particular programs, e.g., popular web browsers that have user-hostile, advertising-friendly "features", and (b) web developer behaviour, e.g., stuffing web pages full of third party advertising-related links. They do not stem from the protocols ("technology") that comprises "the Web", e.g., RFC 1034 or RFC 2616.
Mozilla and other so-called "tech" companies portray "the Web" as something that is (a) only accessible through a narrow range of programs, namely a handful of popular browsers distributed by so-called "tech" companies, and (b) intricably tied to online advertising. Web developers, the majority of them now working for so-called "tech" companies, design websites that utilise "features" of these programs and similarly, based on their own self-interest, argue that this is "the Web". However this is only their preferred version of "the Web". This is the web as experienced using a particular handful of programs that put online advertising first and web users second.
However these so-called "tech" companies are not producing the majority of the web's content. Users are producing that content. The majority of it is not being directed (published) to the world. It is being directed to one other user or a small group of other users. The so-called "tech" companies are intermediaries that seek to promote a minority of users who desire to publish content for large audiences, as this is optimal for advertising purposes, Given the proliferation of these so-called "tech" companies as intermediaries that surveil people using the web in order to profit from selling advertising services, this presents an interesting technical challenge for the majority of web users. How can web users share content with each other using the Web without using so-called "tech" company website intermediaries that perform surveillance for advertising purposes.
The so-called "tech" companies, often including Mozilla, argue that online advertising is necessary for "the Web" to exist, and therefore so-called "tech" companies must exist to faciltate the advertising. But that argument feels disingenuous. For one, "the Web" existed before advertising was permitted on the network. Thus there is no technical limitation that requires advertising. Second, users are paying ISPs for their network connections to each other; they are not paying so-called "tech" companies. Thus, there is no financial limitation that requires advertising in order for the majority of users to share content with each other (cf. large audiences). Most web use is not publishing content to large audiences, it is sharing content with individuals or small groups. Thus most web users do not need a so-called "tech" company to help them publish content to the world.
So-called "tech" companies are only intermediaries, not content producers. They surveil web users for advertising puproses, a practice which they spin as "for the purpose of improving the Services". From the user's perspective "improving the Services" would mean reducing data collection, surveillance and the annoyance of advertising.
Silicon Valley and the so-called "tech" industry more generally have a blind spot for conflicts of interest.
My understanding is, it's a simplified explanation for a somewhat more complex policy.
The obvious thing - every site gets its own cookies - has always been the case: Those are first-party cookies.
The question is what happens when one site embeds content from a different site. Traditionally, there was no special behaviour for that case: If site A embeds an iframe from site B, the top-level document gets to see the cookies for A while the embedded document gets to see the cookies for site B. B's cookies here are 3rd-party cookies.
The problem is that the two documents can communicate, so if site B is embedded into many other sites, B and the other sites can cooperate to track the user across them using B's cookies as a sort of shared identifier. (Or more commonly, B will do the tracking and pay/otherwise incentivise the other sites to embed itself and pass the necessary information to the embedded document)
To avoid this, TCP introduces another level of partitioning: Cookies are not just partitioned by which site has access to it but also by the top-level site.
So site B now doesn't get a single cookie jar as before, it will get several jars "B, embedded by A", "B embedded by C", "B top-level" etc with separate sets of cookies. Hence it becomes impossible to pass a common identifier from one top-level site to another one and (this particular way of) cross-site tracking won't work anymore.
On a side note: Isn't it odd, how the composition of different technologies (here HTTP and DNS) make it unintuitively complex to implement a so intuitively natural policy as "every website gets to read only its own cookies"?