In what sense is TCP tomorrow different from disallowing 3rd party cookies today?
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"?
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 have a problem with them including the "GPC" flag as a privacy feature. We know directly from "Do Not Track" that it was widely ignored, and frequently actually used to perform tracking because it was meant to be opt in, and so was rare. When it got turned on by default a bunch of companies said "DNT is not a user choice now so doesn't mean anything".
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.
Hi! Author of PrivacyTests.org here. Thank you very much for the comment. (I only just saw your reply.) PrivacyTests is very much a work in progress, and all feedback is much appreciated.
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".
> Calling "media queries" a privacy issue is absurd
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.
on mobile so can't provide source but look up why privacy badger no longer uses a dynamic "learned" list of trackers to block, the way you mention safari works and instead uses a list that everyone else uses. it basically reduces privacy because your list of blocked sites is likely to be unique among other users (along with other data points) and unintuitively makes it easier to track you across the web.
>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.
Huh an interesting issue to have to deal with. I'm not sure it makes it easier to track you in practice, though I can see in theory it could absolutely work, so if you did have the choice of have a static block list it would be better.
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.
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.
You aren’t disagreeing with the person you are responding to, you just have slightly different ideas what it means when someone says “website”
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”
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.
Of course... knowing that this is all by well behaving browsers is a bit of a troubling point. Such that I find it equally odd that we have placed so much power and general trust into software that we keep expanding the capabilities of. It is a small step to "managed devices" that we don't even trust users to keep up to date being required for access.
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"?