Intent to Prototype: Origin-Bound Cookies

249 views
Skip to first unread message

Steven Bingler

unread,
May 26, 2022, 12:53:50 PMMay 26
to blink-dev
Contact emails

bin...@chromium.org, mike...@chromium.org


Explainer

https://github.com/sbingler/Origin-Bound-Cookies


Specification

Link


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


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, scheme-bound cookies, origin bound cookies, origin-bound cookies, scheme bound cookie, scheme-bound cookie, origin bound cookie, origin-bound cookie, cookie, cookies


TAG review

None yet. Related: the review for a similar proposal was positive


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.



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?

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

Domenic Denicola

unread,
May 26, 2022, 2:10:49 PMMay 26
to Steven Bingler, blink-dev
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?

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 blink-dev+...@chromium.org.
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.

Steven Bingler

unread,
May 26, 2022, 3:00:07 PMMay 26
to blink-dev, Domenic Denicola, blink-dev, Steven Bingler
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.

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Domenic Denicola

unread,
May 26, 2022, 3:32:20 PMMay 26
to Steven Bingler, blink-dev, Domenic Denicola
On Thu, May 26, 2022 at 3:00 PM Steven Bingler <bin...@chromium.org> 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.
 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Johann Hofmann

unread,
Jun 1, 2022, 6:12:40 PMJun 1
to Domenic Denicola, Steven Bingler, blink-dev
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



Steven Bingler

unread,
Jun 1, 2022, 6:55:58 PMJun 1
to blink-dev, Johann Hofmann, Steven Bingler, blink-dev, Domenic Denicola
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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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 blink-dev+unsubscribe@chromium.org.

Steven Bingler

unread,
Jun 16, 2022, 5:43:27 PMJun 16
to blink-dev, Steven Bingler, Johann Hofmann, blink-dev, Domenic Denicola
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

Thomas Steiner

unread,
Jun 17, 2022, 3:28:13 AMJun 17
to Steven Bingler, blink-dev, Johann Hofmann, Domenic Denicola
Renamed on your behalf. For the record, this is possible via the "Edit all fields" link:

Screen Shot 2022-06-17 at 09.26.50.png

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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 blink-dev+...@chromium.org.

--
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 blink-dev+...@chromium.org.
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.


--
Thomas Steiner, PhD—Developer Relations Engineer (https://blog.tomayac.comhttps://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891

----- BEGIN PGP SIGNATURE -----
Version: GnuPG v2.3.4 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/
----- END PGP SIGNATURE -----

g16

unread,
Jun 27, 2022, 9:46:24 AMJun 27
to Steven Bingler, blink-dev
Hi

I have a question about cross-scheme cookies.

I've heard that a few people handle cookies on the server side when upgrading to WebSockets.

Developer cannot be opt-out scheme bindings. then, will not cookies set by https://example.com not be sent to wss://example.com ?

I'm sorry if they're wrong.

2022年5月27日(金) 1:53 Steven Bingler <bin...@chromium.org>:
--

Steven Bingler

unread,
Jun 27, 2022, 1:12:38 PMJun 27
to blink-dev, g16g...@gmail.com, blink-dev, Steven Bingler
Hello,

That's a good question.

> Developer cannot be opt-out scheme bindings. then, will not cookies set by https://example.com not be sent to wss://example.com ?
Cookies will be sent in your example.
This is because cookies are set and sent during the handshake phase of a WebSockets connection which is performed via HTTP. So your connection to wss://example.com will handshake via https://example.com which is the same scheme meaning that cookies will be sent.

- Steven

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

g16

unread,
Jun 28, 2022, 12:24:20 PMJun 28
to Steven Bingler, blink-dev
Hello, 

Thanks, that makes sense to me!

yuki

2022年6月28日(火) 2:12 Steven Bingler <bin...@chromium.org>:
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Reply all
Reply to author
Forward
0 new messages