Hello All,
The proposal's new name is now
*Origin-Bound Cookies (by default)*
and the explainer now has a new tl;dr which together will hopefully prevent
future confusion.
I poked around chromestatus.com and wasn't able to find a way to change the
feature's name there. I'm hoping it's possible, but I'm fine with creating
a new feature if need be. Does anyone know?
Thanks,
Steven
On Wednesday, June 1, 2022 at 3:55:58 PM UTC-7 Steven Bingler wrote:
> Hi Johann,
>
> Thanks for your input.
>
> Naming always seems to be the hard part; we went with it primarily because:
>
> - It covers the broad intent of the proposal
> - A significant portion of the proposal's purpose is to defend
> "default" cookies, which would indeed be origin bound.
> - It's short and easy to remember
> - Being more correct would make it more unwieldy ("Mostly Origin-Bound
> Cookies"? "Origin-Bound by Default Cookies" maybe?)
>
> With all that said, if changing the name helps reduce confusion and we can
> find a good one I'm not opposed to doing so. I'm happy to discuss it more
> in the explainer's repo https://github.com/sbingler/Origin-Bound-Cookies
>
> On Wednesday, June 1, 2022 at 3:12:40 PM UTC-7 Johann Hofmann wrote:
>
>> 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/2c1d0e88-26ec-4531-aba4-07452507dee3n%40chromium.org.
