- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 15 Aug 2018 17:18:05 +1000
- To: Daniel Stenberg <daniel@haxx.se>
- Cc: Mike West <mkwst@google.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Aug 15, 2018 at 4:05 PM Daniel Stenberg <daniel@haxx.se> wrote: > So, looking into the crystal ball, won't this lead to clients using both > cookies *and* Sec-HTTP-State ? To Daniel's point here (and Mark said something similar), this does several things at once. It removes the option for state offload at the HTTP layer in favor of a (long) fixed string. It also resets the scope of identifiers that can be persisted. I really like the idea of narrowing the scope problem of cookies; cookies are awful, mostly because they cross origin boundaries in awful ways. And document.cookie is similarly terrible. Bundling those two changes with the removal of state offload might be too much though. Other HTTP clients don't have indexedDB or service workers to fall back on for this use case. Cookies are - from the perspective of a user - superior in almost every way. The CSRF benefits here seem fairly hard to get excited about enough to use this new, more limited thing. I can maybe see sites doing this for high value state, if it comes to that, but that's being optimistic. I don't understand how the cross-origin use of these is intended to work (what requests do the options apply to?). p.s., Not sure that son-of-token-binding is worth doing here. Proving that you know a cookie-analogue as opposed to just providing the value might be neat, but it's still leap of faith. Besides, token binding was a ton of work to get right.
Received on Wednesday, 15 August 2018 07:18:40 UTC