RE: [E] Re: HTTP State Tokens

State tokens would be a big improvement on what we have now, with the proviso that the default expiry remained short (i.e. no more than 1 hour as in Mike’s original draft) and that Sec-HTTP-State-Options response headers changing the defaults always triggered a user prompt.
The UA could extend the lease for some reasonable amount of time if it detects real user interaction.
The token is generated by the user agent per-origin and cannot be cross-origin, and the <1hr expiry means it would work for session persistence but not tracking. Using this while eventually disabling cookies also mitigates against sneaky things like bounce tracking etc.
 
 

 

 

From: George Fletcher <george.fletcher@verizonmedia.com> 
Sent: 08 April 2021 15:15
To: Mike West <mkwst@google.com>
Cc: Kaustubha Govind <kaustubhag@google.com>; public-privacycg@w3.org
Subject: Re: [E] Re: HTTP State Tokens

 

Hi Mike,

 

Thanks so much for the response! I found the ability for the user agent to generate a signature for the state tokens very intriguing. Is there any chance we could add that feature to existing cookies via some mechanism? Maybe an attribute for a "set-cookie" response header?

 

Thoughts?

 

Thanks,

George

 

On Thu, Apr 8, 2021 at 1:18 AM Mike West <mkwst@google.com <mailto:mkwst@google.com> > wrote:

Hey George,

 

There was discussion on the IETF's HTTP working group list, and in WebAppSec. My impression from those conversations was that there wasn't enough appetite for building a cookie replacement vs. incrementally changing cookies as they exist. That's the strategy laid out in https://mikewest.github.io/cookie-incrementalism/draft-west-cookie-incrementalism.html <https://urldefense.proofpoint.com/v2/url?u=https-3A__mikewest.github.io_cookie-2Dincrementalism_draft-2Dwest-2Dcookie-2Dincrementalism.html&d=DwMFaQ&c=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY&r=cl87BDJWy_Dken1-bgbUZHoY1dEfYnAZIzXekbjJhbc&m=PF75H_jMRGPCLyMfWDj-A4dzaaPqTcbqyYtjw89EGLo&s=F7i2jxquOErF2Ge7jHxCrCcLy3KYBsaY2LFPcDC8dps&e=> .

 

From my perspective, state tokens are on hold while vendors determine just how malleable existing cookies actually are. I'd love to see folks collectively decide to pick them up again as I think there's some value in shipping a modernized version of that draft, but I'm happy to see the energy flow into incremental change for the time being. :)




-mike

 

 

On Wed, Apr 7, 2021 at 9:42 PM George Fletcher <george.fletcher@verizonmedia.com <mailto:george.fletcher@verizonmedia.com> > wrote:

Thanks! I remember it being discussed but then it seems like discussion has gone silent. The IETF draft expired in September 2019 :)

 

On Wed, Apr 7, 2021 at 3:38 PM Kaustubha Govind <kaustubhag@google.com <mailto:kaustubhag@google.com> > wrote:

Adding +Mike West <mailto:mkwst@google.com>  (author of the proposal).

 

It was discussed on the WebAppSec WG mailing list months ago.

 

On Wed, Apr 7, 2021 at 3:15 PM George Fletcher <george.fletcher@verizonmedia.com <mailto:george.fletcher@verizonmedia.com> > wrote:

This may not be the correct venue but figured I'd ask to see if anyone knows the status of HTTP State tokens. 

 

Thanks,

George