Re: [w3ctag/design-reviews] Schemeful Same-Site (#497)

I have thoughts! In no particular order:

1.  Chromium, at least, seems interested in shipping both of the behaviors in question. Talking about them as distinct behavioral changes makes it possible to ship pieces when they're ready, rather than waiting for the stars to align for a big-bang shift, but they're both part of the same story around [incrementally improving cookies' security and privacy properties](https://mikewest.github.io/cookie-incrementalism/draft-west-cookie-incrementalism.html).

2. Hand-waving a bit: RFC6265bis currently [defines](https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-06#section-5.2) "same-site" as a registrable domain match between two origins. HTML [defines](https://html.spec.whatwg.org/#sites) "schemelessly same-site" as more or less the same thing, and also defines "same-site" as a registrable domain match _and_ a scheme match. That's more or less what @sbingler is proposing here: "schemefull same-site" will align the `SameSite` cookie attribute with HTML's existing "same-site" concept, rather than its "schemeless same-site" concept.

3.  We originally defined cookies `SameSite` attribute to equate HTTP and HTTPS variants of a site as a mechanism to ease upgrades for sites that had non-secure pages relying upon secure SSO endpoints (e.g. `http://example.com/` embedding `https://login.example.com/`). It does allow vulnerabilities in those relationships, as anything `https://login.example.com/` passes to `http://example.com/` is exposed to the network. At the time, it was a reasonable carveout to allow migration from non-secure to secure pages. Given the shift to HTTPS over the last few years, we're hopeful that it's a carveout that's no longer necessary.

-- 
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/497#issuecomment-619044992