Re: [w3ctag/design-reviews] HTTP State Tokens (#297)

Thanks, @dbaron and @torgo!

> So it seems like this turns something that currently requires sites to actively track (i.e., set a cookie) into something that can now be done passively

Two points:

1.  https://github.com/mikewest/http-state-tokens#opt-in discusses the question of whether an initial navigational request should be pre-populated with a value, or whether the capability should be advertised and opted-into. My intuition is that binding the initial request to the next request is actually important, and that folks would just initiate another navigation if they didn't get the value to begin with (which means that this isn't actually a barrier, and it just creates annoyance for users). This, though, is not at all set in stone, and I may well be wrong in my analysis. If there's real value to making the token completely opt-in, I'm not at all philosophically opposed to doing so.

2.  Note that the default `delivery` behavior of a token is `same-site`. This means that even if we do decide to auto-mint tokens for origins, they're not particularly useful for third-party tracking until and unless a user visits the site in a first-party context so that it has an opportunity to change the `delivery` option via a `Sec-HTTP-Site-Options` header (because `same-site` tokens aren't delivered in third-party contexts). That is, if a user who's never been to any websites before visits `https://example.com/`, then:

    *   The navigational request would include a newly-minted token for `https://example.com`.
    *   Subresource requests to `https://example.com/` would include `https://example.com`'s token.
    *   Subresource requests to `https://sub.example.com/` would include a newly-minted token for `https://sub.example.com` (because its `delivery` would default to `same-site`).
    *   Subresource requests to `https://not-example.com/` would not include a token for `https://not-example.com` (because its `delivery` had not been changed from `same-site`).

    In other words, I think this proposal actually makes third-party tracking _more_ opt-in than it is today, insofar as the third-party which wishes to track must have been visited in a first-party context at some point in the past to have changed it's `delivery` option.

> Is there any additional implementer interest? 

None that I know of.

> Also to David's point, will implementation of this proposal diminish the ability for the user to measure how they are being tracked?

I don't see how it would. Users would remain in control of these tokens in the same way they're in control of cookies.

> Also, will an origin get different tokens depending on the top level origin (i.e. double-keying).

That seems like a choice specific user agents could make. I'd note that Safari is the only browser to double-key storage, and they've just [removed cookie partitioning](https://bugs.webkit.org/show_bug.cgi?id=188109) from tip-of-tree WebKit. It seems more likely to me that folks will follow Firefox's approach of gating access completely for particular origins rather than attempting to shard identity across top-level pages, but I think this proposal would give user agents flexibility to do so as they see fit.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/297#issuecomment-434719695