search

sbingler / schemeful-same-site

Explainer for Schemeful Same-Site
15 stars 3 forks source link

Is schemeful the right term considering https vs wss? #5

Open johnwilander opened 3 years ago

johnwilander commented 3 years ago

Does this proposal aim to separate SameSite cookies between plaintext and TLS connections or between schemes? The https and wss schemes are both secure and I assume you are not suggesting separate SameSite cookies for WebSockets. The WebSockets handshake with cookies is done over HTTP, sure, but in the web platform layer the URLs differ in schemes. Schemeful might not the best term. Sorry if I'm missing something. @mikewest to weigh in.

davidben commented 3 years ago

WebSockets map the ws/wss URLs to http/https before running through most of fetch, so it's still the same scheme. See step 1 of https://fetch.spec.whatwg.org/#websocket-opening-handshake

I think using schemes is the right way to go. There are other schemes than http: and https:. For instance, about: and data:, and browsers may manage some additional schemes like chrome-extension:. These schemes may not even use DNS-based authorities, so it would be especially bad to fold them in with the HTTP-based schemes. While cookies are primarily for HTTP-based schemes, using schemes over a "secure" boolean makes things less likely to end up with some mishap. It also aligns with the WHATWG definition of site (which is pretty useful for something called SameSite).

mikewest commented 3 years ago

I agree with @davidben. From Fetch's perspective, the only schemes that matter are http and https. ws and wss are folded into those, and other schemes either don't have cookies at all (data, file), or are expected to have distinct cookie jars (chrome-extension, moz-extension, etc).

Partitioning the "site" concept on scheme seems like a reasonable approach.