5 ms·

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 (

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"?

red_trumpet 4y ago
> every website gets to read only its own cookies 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.
- aidenn0 4y ago
  It's not already the case, but it is expected to be the case in all major browsers sometime next-year[1] 1: https://en.wikipedia.org/wiki/HTTP_cookie#Third-party_cookie https://en.wikipedia.org/wiki/HTTP_cookie#Third-party_cookie
  - cortesoft 4y ago
    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”
    - TylerE 4y ago
      Then they should say server/domain/subdomain and not “website”.
taeric 4y ago
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.
arthuredelstein 4y ago
Total Cookie Protection partitions all cookie-like data ("state") between the websites you visit, not just cookies. For a technical discussion, see https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning https://developer.mozilla.org/en-US/docs/Web/Privacy/State_P... You can see which browsers partition state (and which don't) in the State Partitioning section of https://privacytests.org https://privacytests.org. Firefox passes nearly all of those tests because Total Cookie Protection is enabled by default.
- olliej 4y ago
  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.
  - talkin 4y ago
    > 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.
renewiltord 4y ago
It appears 3rd party cookies will still be placed but they will be partitioned by 1st party domain. That's interesting.
deleted 4y ago
[deleted]
xg15 4y ago
> every website gets to read only its own cookies 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.

red_trumpet 4y ago

> every website gets to read only its own cookies 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.

aidenn0 4y ago
It's not already the case, but it is expected to be the case in all major browsers sometime next-year[1] 1: https://en.wikipedia.org/wiki/HTTP_cookie#Third-party_cookie https://en.wikipedia.org/wiki/HTTP_cookie#Third-party_cookie
- cortesoft 4y ago
  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”
  - TylerE 4y ago
    Then they should say server/domain/subdomain and not “website”.

taeric 4y ago

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.

arthuredelstein 4y ago

Total Cookie Protection partitions all cookie-like data ("state") between the websites you visit, not just cookies. For a technical discussion, see https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning https://developer.mozilla.org/en-US/docs/Web/Privacy/State_P... You can see which browsers partition state (and which don't) in the State Partitioning section of https://privacytests.org https://privacytests.org. Firefox passes nearly all of those tests because Total Cookie Protection is enabled by default.

olliej 4y ago
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.
- talkin 4y ago
  > 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.

renewiltord 4y ago

It appears 3rd party cookies will still be placed but they will be partitioned by 1st party domain. That's interesting.

deleted 4y ago

[deleted]

xg15 4y ago

> every website gets to read only its own cookies 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.