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

Tl;dr: “Schemeful same-site” affects the browsing contexts cookies will be sent in.
“Scheme-bound cookies” affects the connections the cookies will be sent on.

Thanks for your feedback Kenneth and Daniel!

I’d like to start off by prefacing that understanding the differences between schemeful same-site and scheme-bound cookies can be difficult; It’s subtle and can be confusing.

The two proposals complement each other (@torgo) by each trying to move cookies closer to an origin based security model. At present, cookies are shared between secure and insecure browsing contexts, and secure and insecure network connections. The first vulnerability is the target of "Schemeful same-site" while the second is addressed by "Scheme-bound cookies". 
“Schemeful same-site” protects secure origins from potentially-compromised insecure origins by allowing the SameSite attribute to protect a cookie from being sent in a mixed-scheme browsing context.
“Scheme-bound cookies” protects secure origins from potentially-compromised insecure origins by binding a cookie to the secureness of its source origin’s scheme and preventing it from being accessed on any insecure connection.

This similarity in their goal inevitably leads to overlap in their proposed behavior. However one is not a strict subset of the other, as shown in [Lily’s previous post](https://github.com/w3ctag/design-reviews/issues/497#issuecomment-613496794). Notice which cookies are included changes depending on which proposals are active: just schemeful same-site, just scheme-bound cookies, and finally both.

Communicating this successfully to developers is clearly not going to be easy and “how” isn’t a question I can fully answer at the moment. Same-site (current) was/is also a complicated concept but a lot of work has gone into communicating to developers about what it means for them and how they can successfully adopt it e.g. [this article](https://web.dev/samesite-cookies-explained/).
I’m hoping 1) my proposal is easy enough to understand for devs as simply a modification of what they know about same-site. I.e. the current world + “different scheme means cross-site” and 2) a similar communication effort can be made for scheme-bound cookies.

As to why the name “schemefully same-site” (@kenchris) vs something else I chose the name to illustrate that this is a modification/extension of (the current) same-site which only considers the registrable domain as defining a “site.” This new proposal now considers the scheme as well, hence schemefully. Could it be called scheme-bound same-site? Maybe, but it feels strange to me.

Scheme-bound cookies on the other hand makes sense to me in that you are binding the cookies to the scheme of the source that set it. So if a secure source sets a cookie then an insecure source can’t possibly get to it (ignoring any temporary carve outs) and vice-versa. @mikewest Please weigh in if you have any thoughts.

As to the explainer (@torgo) could you expand a bit on what you think would be helpful? I made mention of the user benefits in the goals (extending the CSRF protections to the schemed site) and tried putting the context in the introduction. Given your experience with explainers how could I make this more clear? 

Cookies are one of the last components of the web platform that blur the lines between secure and insecure origins, and both of these proposals are designed to harden different boundaries in order to increase the trustworthiness of the Web platform. 


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