Hey Steven, I think this is a great idea, though I have to admit that (being aware of the domain attribute and how it works) I was also under the impression that this proposal was intended to fix the domain mechanics by *strictly* binding cookies to origin. This is suggested by the proposal name, so I wonder if it makes sense to change the name (at this early stage) to avoid future misunderstandings?
Sorry for starting a bikeshed & thanks, Johann On Thu, May 26, 2022 at 9:32 PM Domenic Denicola <[email protected]> wrote: > > > On Thu, May 26, 2022 at 3:00 PM Steven Bingler <[email protected]> > wrote: > >> Hi Domenic, >> >> If I understand correctly you're concerned about how cookies will behave >> along same-site host boundaries. This proposal does not alter that behavior. >> >> A simple cookie `a=b` will currently not be sent to any host other than >> the one that originally set it. If a developer would like the cookie to be >> sent to other same-site hosts they need to use the `Domain` attribute e.x.: >> `a=b; Domain=example.com`. This will continue to be the case once/if >> this proposal is implemented. >> > > Thanks, and my apologies for not knowing this basic fact about cookies! I > had heard the mantra "cookies do not respect the origin boundary and > instead span the whole site" so many times, I thought it was the default > behavior, not just a (presumably popular) opt-in behavior. > > For anyone else interested, Ctrl+Fing "host-only flag" in > https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html > gives all the details. > > >> >> > if the plan (per the explainer) is to no longer share cookies between >> different origins under the same site. >> Origin-Bound Cookie is focused on adding the scheme & port components of >> the origin to cookies rather than tightening the existing host related >> rules. So while a simple cookie `a=b` can be considered origin bound, that >> restriction can continue to be loosened with the `Domain` attribute. >> >> Maybe one day `Domain` could be deprecated/removed and cookies would be >> completely origin bound, but that's well out of the scope of this proposal. >> >> On Thursday, May 26, 2022 at 2:10:49 PM UTC-4 Domenic Denicola wrote: >> >>> On Thu, May 26, 2022 at 12:53 PM Steven Bingler <[email protected]> >>> wrote: >>> >>>> Contact emails >>>> >>>> [email protected], [email protected] >>>> >>>> Explainer >>>> >>>> https://github.com/sbingler/Origin-Bound-Cookies >>>> >>>> Specification >>>> >>>> Link >>>> <https://mikewest.github.io/cookie-incrementalism/draft-west-cookie-incrementalism.html#name-origin-bound-cookies> >>>> >>>> Summary >>>> >>>> Binds cookies to their setting origin (by default) such that they're >>>> only accessible by that origin. I.e., sent on a request or visible through >>>> `document.cookie` >>>> >>>> Cookies may ease the host and port binding restrictions through use of >>>> the `Domain` attribute but all cookies will be bound to their setting >>>> scheme. >>>> >>>> >>>> Blink component >>>> >>>> Blink>Network >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork> >>>> >>>> Motivation >>>> >>>> Cookies are not secure by default. A simple cookie `Set-Cookie: >>>> foo=bar` can be accessed by any scheme or port regardless whichever set it >>>> originally. This can lead to users' data leaking to attackers or allowing >>>> attackers to alter users' state. >>>> >>>> By only sending cookies back to the origins that set them (binding them >>>> to the origins) we can protect cookies (by default) from untrusted origins. >>>> >>>> >>>> Initial public proposal >>>> >>>> https://github.com/mikewest/scheming-cookies >>>> >>>> Search tags >>>> >>>> scheme bound cookies >>>> <https://chromestatus.com/features#tags:scheme%20bound%20cookies>, >>>> scheme-bound >>>> cookies <https://chromestatus.com/features#tags:scheme-bound%20cookies>, >>>> origin bound cookies >>>> <https://chromestatus.com/features#tags:origin%20bound%20cookies>, >>>> origin-bound >>>> cookies <https://chromestatus.com/features#tags:origin-bound%20cookies>, >>>> scheme bound cookie >>>> <https://chromestatus.com/features#tags:scheme%20bound%20cookie>, >>>> scheme-bound >>>> cookie <https://chromestatus.com/features#tags:scheme-bound%20cookie>, >>>> origin >>>> bound cookie >>>> <https://chromestatus.com/features#tags:origin%20bound%20cookie>, >>>> origin-bound >>>> cookie <https://chromestatus.com/features#tags:origin-bound%20cookie>, >>>> cookie <https://chromestatus.com/features#tags:cookie>, cookies >>>> <https://chromestatus.com/features#tags:cookies> >>>> >>>> TAG review >>>> >>>> None yet. Related: the review for a similar proposal >>>> <https://github.com/w3ctag/design-reviews/issues/483> was positive >>>> <https://github.com/w3ctag/design-reviews/issues/483#issuecomment-634767557> >>>> >>>> TAG review status >>>> >>>> Pending >>>> >>>> Risks >>>> >>>> Interoperability and Compatibility >>>> >>>> As this change explicitly prevents cookies from being accessible >>>> between schemes and ports (without use of the `Domain` attribute), any >>>> sites relying on that behavior will experience breakage. >>>> >>>> Initial metrics show that of cookies sent by Chrome in the 7 days >>>> leading to May 23th 2022: >>>> >>>> - >>>> >>>> 0.39% are between schemes >>>> - >>>> >>>> 0.09% are between port values >>>> >>>> >>>> It’s difficult to convert these metrics into expected breakages as not >>>> every cookie that is sent between schemes or ports is needed in that >>>> context. However this does give an idea of the upper bound of breakage. >>>> Because of the high potential impact, we will be proceeding carefully >>>> during an eventual launch, if given LGTMs to ship. >>>> >>> >>> What about cookies that are shared between subdomains (i.e. different >>> origins under the same site)? That seems likely to be much higher than >>> this, e.g. cookies shared between https://www.example.com and >>> https://example.com. So it is hard to believe the above numbers >>> represent a sort of upper bound, if the plan (per the explainer) is to no >>> longer share cookies between different origins under the same site. >>> >>> >>>> >>>> >>>> Gecko: No signal >>>> >>>> >>>> WebKit: No signal >>>> >>>> Web developers: No signals >>>> >>>> Other signals: >>>> >>>> WebView application risks >>>> >>>> Yes, any WebView applications that access cookies across origins may >>>> potentially be affected. >>>> >>>> >>>> Debuggability >>>> >>>> Devtools will be updated to support viewing and editing the new scheme >>>> and port components. >>>> >>>> Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ? >>>> >>>> Not currently, but web platform tests will be added before launch. >>>> >>>> Flag name >>>> >>>> No flags yet. >>>> >>>> Requires code in //chrome? >>>> >>>> False >>>> >>>> Tracking bug >>>> >>>> https://crbug.com/1170548 >>>> >>>> Launch bug >>>> >>>> https://crbug.com/1170557 >>>> >>>> Estimated milestones >>>> >>>> No milestones specified >>>> >>>> >>>> Link to entry on the Chrome Platform Status >>>> >>>> https://chromestatus.com/feature/4945698250293248 >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8ddc0664-bbf4-4af5-806f-cec7e5f84ae0n%40chromium.org >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8ddc0664-bbf4-4af5-806f-cec7e5f84ae0n%40chromium.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8xjbL9kh3pV9u7YfXm0t4NzrUANr-tu1g23sdmQrU1zA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8xjbL9kh3pV9u7YfXm0t4NzrUANr-tu1g23sdmQrU1zA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4idoMu5DHUYnNbJy0tBHFEHENSUyuJD9BdXVFcoOkc8SQ%40mail.gmail.com.
