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.
