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 On Monday, June 27, 2022 at 9:46:24 AM UTC-4 [email protected] wrote: > 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 <[email protected]>: > >> 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. >> >> >> 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/75f002c7-4e6b-4426-b4c2-f981fcc56e37n%40chromium.org.
