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/ce56664b-ef96-4a26-a975-af73dd396312n%40chromium.org.
