Intent to Prototype: Schemeful Same-Site

[Steven Bingler]

Contact emails

bin...@chromium.org, davi...@chromium.org, kaust...@chromium.org

Explainer

https://html.spec.whatwg.org/multipage/origin.html#same-site

Summary

Modify the definition of same-site for cookies such that requests on the same registrable domain but across schemes are considered cross-site instead of same-site. E.g., http://site.example and https://site.example will now be considered cross-site to each other. Current plans target a M83-84 release.

Motivation

The SameSite cookie attribute offers defense against CSRF attacks but currently does not consider secure and insecure version of the same domain as being cross-site; because of this, a network attacker could impersonate http://site.example (or a subdomain) and use that to bypass SameSite protections on https://site.example. Changing the same-site computation to consider http://site.example and https://site.example as cross-site negates this type of attack.

This change would align the cookie definition of same-site, and Chrome’s future implementation, with the changes to the WHATWG definition as seen in the explainer. 

Note that WebSockets requests can send cookies but use different schemes from http(s). For purposes of this comparison wss:// and https:// are considered the same and similarly for ws:// and http://.

 

Risks

Interoperability and Compatibility

SameSite = {Lax,Strict} cookies will no longer be sent in cross-scheme[1] subresource requests i.e., http-to-https and https-to-http (mixed content), regardless of HTTP request method. Note that Chrome already blocks many types of mixed content and will block more in the future. 

SameSite = {Lax,Strict} cookies will no longer be sent in cross-scheme top-level POSTs.

SameSite = {Strict} cookies will no longer be sent in cross-scheme top-level navigations.

SameSite= {Lax,Strict} cookies will no longer be set in a response to a cross-scheme subresource request.

Sites relying on these behaviors may break. Breakage should be minimal however as metrics indicate that <5.5%[2] of all the cookies are sent with SameSite = {Lax,Strict} on a request and of those <0.3% are cross-scheme resulting in a total of <0.02% of all cookies sent being both cross-scheme and SameSite = {Lax,Strict}; <3.2% of all cookies are set with SameSite={Lax,Strict} on a response and <1.0% of those are cross-scheme resulting in a total of <0.032% cookies set being both cross-scheme and SameSite = {Lax,Strict}.

Edge: No signals

Firefox: No signals

Safari: No signals

Web/Framework developers: No signals

Activation

No activation is required.

Debuggability

A warning message will be added to the developer console in M82 to assist developers in finding these cases.

Enterprise policies will be added for 1) allow-listing a set of domains for which “Schemeful Same-Site” will be disabled and 2) completely disabling “Schemeful Same-Site”.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No tests exist at the moment. There are existing tests for the SameSite attribute which will be modified to include cross-scheme restrictions.

Link to entry on the feature dashboard

To be created.

[1]: For brevity “cross-scheme” in this context means sites which are schemelessly-same-site but have differing schemes. E.x.: http://site.example and https://site.example are considered cross-scheme.

[2]: These number include any cookies which are handled as {Lax,Strict}, such as if SameSite-by-default is enabled, but were captured before SameSite-by-default was activated for most users.

[EricLaw-MSFT]

The phrasing here: "Note that WebSockets requests can send cookies but use different schemes from http(s). For purposes of this comparison wss:// and https:// are considered the same and similarly for ws:// and http://." is a bit ambiguous.

I think you're saying "WebSocket handshake requests can carry cookies. For the purposes of this change, WebSockets targeting ws:// are considered same-scheme as http://, while WebSockets targeting wss:: are considered same-scheme as https://". Is that correct?

From a security and privacy POV, it seems unfortunate that this change would force a HTTPS subframe (https://example.com) to force its cookies to be SAMESITE=NONE in order to be available when its top-level host page is HTTP (http://example.com).

[David Benjamin]

On Monday, January 27, 2020 at 2:43:33 PM UTC-5, EricLaw-MSFT wrote:

The phrasing here: "Note that WebSockets requests can send cookies but use different schemes from http(s). For purposes of this comparison wss:// and https:// are considered the same and similarly for ws:// and http://." is a bit ambiguous.

I think you're saying "WebSocket handshake requests can carry cookies. For the purposes of this change, WebSockets targeting ws:// are considered same-scheme as http://, while WebSockets targeting wss:: are considered same-scheme as https://". Is that correct?

Yup. WebSockets carrying cookies at all was perhaps a mistake, but a bit late for that one. It isn't particularly helpful to treat wss:// as https:// as cross-site, so I think, as part of all this, we should spec WebSockets as mapping wss to https and ws to http, before entering cookie logic.

 

From a security and privacy POV, it seems unfortunate that this change would force a HTTPS subframe (https://example.com) to force its cookies to be SAMESITE=NONE in order to be available when its top-level host page is HTTP (http://example.com).

I disagree that this is unfortunate. It's true that it is more uses of SameSite=None to deal with, but it is desirable from both a security and privacy POV. http://example.com means "example.com and anyone on the network who wrote example.com in dry erase marker". That is really not the same entity as "example.com". Rather than mix things like that, sites should deploy HTTPS on the top-level URL too. Though as a temporary measure, yeah SameSite=None exists. (It's a bit fussy because SameSite=None requires Secure, which would make that cookie not sent over http://example.com. I suppose you could always have two cookies. But this is really just a bad state to be in general, so site owners should be strongly encouraged to migrate to HTTPS properly.)

Note the (still in progress) privacy threat model defines a site using the WHATWG definition which includes the scheme. That's, of course, still quite aspirational (e.g. the cookie jar itself is not currently split by scheme), but given the vastly different security levels, it's the right aspiration. This change is one step towards that aspiration.

https://w3cping.github.io/privacy-threat-model/#terminology

https://html.spec.whatwg.org/multipage/origin.html#same-site

[Anne van Kesteren]

On Mon, Jan 27, 2020 at 10:39 PM David Benjamin <davi...@chromium.org> wrote:
> Yup. WebSockets carrying cookies at all was perhaps a mistake, but a bit late for that one. It isn't particularly helpful to treat wss:// as https:// as cross-site, so I think, as part of all this, we should spec WebSockets as mapping wss to https and ws to http, before entering cookie logic.

That's how it has been defined through Fetch for quite a while now:
https://fetch.spec.whatwg.org/#websocket-opening-handshake.

[Yoav Weiss]

On Mon, Jan 27, 2020 at 6:17 PM Steven Bingler <bin...@chromium.org> wrote:

Contact emails

bin...@chromium.org, davi...@chromium.org, kaust...@chromium.org

Explainer

https://html.spec.whatwg.org/multipage/origin.html#same-site

Unfortunately, that's not an explainer. If you feel like a separate explainer document is too much for this change, maybe you could write down a few sentences explaining in plain language what this change is, the motivation behind it, and the user problems that it would solve.

Also, is a TAG review necessary? Since this as an incremental improvement over https://github.com/w3ctag/design-reviews/issues/373, maybe you can comment there to ask for guidance?

Summary

Modify the definition of same-site for cookies such that requests on the same registrable domain but across schemes are considered cross-site instead of same-site. E.g., http://site.example and https://site.example will now be considered cross-site to each other. Current plans target a M83-84 release.

Motivation

The SameSite cookie attribute offers defense against CSRF attacks but currently does not consider secure and insecure version of the same domain as being cross-site; because of this, a network attacker could impersonate http://site.example (or a subdomain) and use that to bypass SameSite protections on https://site.example. Changing the same-site computation to consider http://site.example and https://site.example as cross-site negates this type of attack.

This change would align the cookie definition of same-site, and Chrome’s future implementation, with the changes to the WHATWG definition as seen in the explainer. 

Note that WebSockets requests can send cookies but use different schemes from http(s). For purposes of this comparison wss:// and https:// are considered the same and similarly for ws:// and http://.

 

Risks

Interoperability and Compatibility

SameSite = {Lax,Strict} cookies will no longer be sent in cross-scheme[1] subresource requests i.e., http-to-https and https-to-http (mixed content), regardless of HTTP request method. Note that Chrome already blocks many types of mixed content and will block more in the future. 

SameSite = {Lax,Strict} cookies will no longer be sent in cross-scheme top-level POSTs.

SameSite = {Strict} cookies will no longer be sent in cross-scheme top-level navigations.

SameSite= {Lax,Strict} cookies will no longer be set in a response to a cross-scheme subresource request.

Sites relying on these behaviors may break. Breakage should be minimal however as metrics indicate that <5.5%[2] of all the cookies are sent with SameSite = {Lax,Strict} on a request and of those <0.3% are cross-scheme resulting in a total of <0.02% of all cookies sent being both cross-scheme and SameSite = {Lax,Strict}; <3.2% of all cookies are set with SameSite={Lax,Strict} on a response and <1.0% of those are cross-scheme resulting in a total of <0.032% cookies set being both cross-scheme and SameSite = {Lax,Strict}.

Edge: No signals

Firefox: No signals

Safari: No signals

Web/Framework developers: No signals

Can you reach out to increase the chance we'd have signals by I2S time?

 

Activation

No activation is required.

Debuggability

A warning message will be added to the developer console in M82 to assist developers in finding these cases.

Enterprise policies will be added for 1) allow-listing a set of domains for which “Schemeful Same-Site” will be disabled and 2) completely disabling “Schemeful Same-Site”.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No tests exist at the moment. There are existing tests for the SameSite attribute which will be modified to include cross-scheme restrictions.

Link to entry on the feature dashboard

To be created.

[1]: For brevity “cross-scheme” in this context means sites which are schemelessly-same-site but have differing schemes. E.x.: http://site.example and https://site.example are considered cross-scheme.

[2]: These number include any cookies which are handled as {Lax,Strict}, such as if SameSite-by-default is enabled, but were captured before SameSite-by-default was activated for most users.

--
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/c7ed7d25-f172-44cc-a9aa-730b8c81c390%40chromium.org.

[Domenic Denicola]

> Summary
> Modify the definition of https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-5.2 for cookies such that requests on the same registrable domain but across schemes are considered cross-site instead of same-site. E.g., http://site.example and https://site.example will now be considered cross-site to each other. Current plans target a M83-84 release.

This seems like a great change!

Just to confirm, the plan is to update draft-ietf-httpbis-rfc6265bis-03 at some point? It'd be good to have at least a specification pull request ready, if not a full specification, when Intent to Ship time comes.

(BTW, draft-ietf-httpbis-rfc6265bis-03 is a pretty cool document. I didn't know we had made so much progress on modernizing the cookie specification to describe actual user agent behavior in detail.)

[Steven Bingler]

Thanks for feedback Yoav,

To your points:

An explainer is in the works.

I'm looking into the TAG review.

I'm reaching out to get a sense of support with other browsers.

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

[Steven Bingler]

Hi Domenic,

Yes rfc6265bis is also going to be updated.

[Yoav Weiss]

Awesome, thanks! :)

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/c7ed7d25-f172-44cc-a9aa-730b8c81c390%40chromium.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/72a2df2a-a5f2-4d0b-8234-029e0ee884cb%40chromium.org.

[bay...@gmail.com]

 

From a security and privacy POV, it seems unfortunate that this change would force a HTTPS subframe (https://example.com) to force its cookies to be SAMESITE=NONE in order to be available when its top-level host page is HTTP (http://example.com).

I disagree that this is unfortunate. It's true that it is more uses of SameSite=None to deal with, but it is desirable from both a security and privacy POV.

Yes, of course HTTPS is great and everyone should use it for everything. Having said that, it is undesirable, from a security, privacy, and compatibility POV to force a site which hopes to protect itself with SameSite cookies to instead use SameSite=NONE on its cookies because it must accommodate some legacy configuration whereby a secure subframe is embedded within an insecure parent page.

This is bad for privacy, because the whole point of SameSite=NONE is to create cookies that stick out like a sore thumb and, eventually, flag them for review/deletion/expiry, etc.

This is bad for security, because we've now weakened the security model for SameSite, whereby previously-working CSRF defense against, say, a POST from badguy.com, is now unavailable because a site that needs its secure subframes cannot use SameSite without breaking.

This is (possibly) bad for compatibility, because we're changing the behavior of a security mechanism after we've shipped it, potentially breaking web content.

[David Benjamin]

On Thu, Jan 30, 2020 at 3:06 PM <bay...@gmail.com> wrote:

 

From a security and privacy POV, it seems unfortunate that this change would force a HTTPS subframe (https://example.com) to force its cookies to be SAMESITE=NONE in order to be available when its top-level host page is HTTP (http://example.com).

I disagree that this is unfortunate. It's true that it is more uses of SameSite=None to deal with, but it is desirable from both a security and privacy POV.

Yes, of course HTTPS is great and everyone should use it for everything. Having said that, it is undesirable, from a security, privacy, and compatibility POV to force a site which hopes to protect itself with SameSite cookies to instead use SameSite=NONE on its cookies because it must accommodate some legacy configuration whereby a secure subframe is embedded within an insecure parent page.

This is bad for privacy, because the whole point of SameSite=NONE is to create cookies that stick out like a sore thumb and, eventually, flag them for review/deletion/expiry, etc.

Indeed. Cookies which need to be sent in cross-scheme embeddings are problematic. This is precisely something sites should be looking at. Note the target privacy threat model, which defines site to include scheme.

https://w3cping.github.io/privacy-threat-model/#terminology

This change is also one of the ones needed to fix the web's reliance on HSTS as a workaround for cookies insufficiently checking schemes. This is needed to fix HSTS's privacy problems without introducing other problems as a side effect. See the writeup below:

https://github.com/mikewest/strict-navigation-security#a-proposal

 

This is bad for security, because we've now weakened the security model for SameSite, whereby previously-working CSRF defense against, say, a POST from badguy.com, is now unavailable because a site that needs its secure subframes cannot use SameSite without breaking.

SameSite without checking scheme is not a functional CSRF defense under the usual web platform threat model. Today, a POST from a network attacker still sends SameSite cookies. Sites using SameSite for CSRF defenses did not actually get CSRF defenses. The scheme needs to be incorporated for it to actually work.

 

This is (possibly) bad for compatibility, because we're changing the behavior of a security mechanism after we've shipped it, potentially breaking web content.

Yup. All fixes to problems in the web platform carry compatibility risk, which is why we measure the impact of any change.

[Eric Lawrence]

> SameSite without checking scheme is not a functional CSRF defense under the usual web platform threat model.

Sorry, I'm not sure what you mean here. Are you suggesting:

1. The SameSite feature was not considered a CSRF defense until Chrome 83

or

2. There exists somewhere a documented threat model for the web platform that does not distinguish between the capabilities of a network MITM and any arbitrary website?

...or have I missed your point entirely and you're saying something else?

thanks!

[David Benjamin]

On Thu, Jan 30, 2020 at 5:05 PM Eric Lawrence <elaw...@chromium.org> wrote:

> SameSite without checking scheme is not a functional CSRF defense under the usual web platform threat model.

Sorry, I'm not sure what you mean here. Are you suggesting:

1. The SameSite feature was not considered a CSRF defense until Chrome 83

or

2. There exists somewhere a documented threat model for the web platform that does not distinguish between the capabilities of a network MITM and any arbitrary website?

...or have I missed your point entirely and you're saying something else?

I'm saying that the threat model for security of an HTTPS origin assumes a network attacker. After all, the entire point of using HTTPS is to protect against network attackers. I think formally documenting threat models in high-level web specs is a fairly recent practice, but HTTPS uses TLS which documents its security properties.

That means security mechanisms for standard attacks on HTTPS origins should not be bypassable by a network attacker. It wouldn't be reasonable to, say, add a mechanism for the DNS to affect an HTTPS document's CSP policy. SameSite was originally specified to not check the scheme. Sadly, as a consequence of that, it only ends up providing CSRF protection under a weaker threat model without network attackers. This proposal is to fix it to meet the usual HTTPS threat model.

(Note, per the links below, this proposal also aligns with the target privacy threat model document, and is on path to fixing HSTS as a covert tracking vector.)

--

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/00a187bf-5b50-4c63-92b0-e7cb78026568%40chromium.org.

[bin...@google.com]

Updating the I2P

Contact emails

bin...@chromium.org, davi...@chromium.org, kaust...@chromium.org

Explainer

https://github.com/sbingler/schemeful-same-site

https://www.chromestatus.com/feature/5096179480133632

[1]: For brevity “cross-scheme” in this context means sites which are schemelessly-same-site but have differing schemes. E.x.: http://site.example and https://site.example are considered cross-scheme.

[2]: These number include any cookies which are handled as {Lax,Strict}, such as if SameSite-by-default is enabled, but were captured before SameSite-by-default was activated for most users.

[bay...@gmail.com]

For Edge, I think you can put us down as "Neutral" or, failing that, "Public Mixed Signals." I think it's reasonable to Prototype/Experiment with this and see what it breaks. I think the Explainer is good, and I especially think the "Examples" section at the bottom is great.

I think the threat being addressed here is legitimate, but I worry about the compatibility impact of the change, and I fear that some sites may respond by just blindly marking their cookies as "SameSite: None". There's a history of WebDevs learning "Oh, yeah, to make cookies work you just have to utter these strange incantations and they'll start working..." and not really trying to understand what those incantations actually do under the covers. The semantics of SameSite are already pretty confusing, and this adds another wrinkle to them; I'd almost wish we would just jump directly to Scheme-Bound Cookies insofar as that might make things easier to reason about.

A few other issues:

1. Could we exempt __HOST and __SECURE cookies from this feature? Such cookies should already be immune from HTTP->HTTPS exploit, and this alternative might help encourage adoption of these prefixes and avoid causing sites to start sprinkling SameSite=None on all their new cookies.

2. I assume this change will continue to apply when both "http://site" and "https://site" are both secure contexts (specifically, http[s]://localhost)? Originally I was going to propose that we should not change behavior for that case (because there's no security value in doing so), but in thinking about it further, it seems like having the change apply to localhost as well might prevent a web developer from getting a surprise when moving from self-hosting their dev site locally to publishing it to a live/production site.

3. In the explainer, it says "This means that both secure and insecure origins will retain access to the same set of cookies. I.e., if a user visits http://site.example and it sets a cookie then when that user then visits https://site.example the site can still read that same cookie." I don't think that's generally true, unless the cookie is explicitly set with SameSite=None, right?

[David Benjamin]

On Thu, May 21, 2020 at 6:54 PM <bay...@gmail.com> wrote:

For Edge, I think you can put us down as "Neutral" or, failing that, "Public Mixed Signals." I think it's reasonable to Prototype/Experiment with this and see what it breaks. I think the Explainer is good, and I especially think the "Examples" section at the bottom is great.

I think the threat being addressed here is legitimate, but I worry about the compatibility impact of the change, and I fear that some sites may respond by just blindly marking their cookies as "SameSite: None". There's a history of WebDevs learning "Oh, yeah, to make cookies work you just have to utter these strange incantations and they'll start working..." and not really trying to understand what those incantations actually do under the covers. The semantics of SameSite are already pretty confusing, and this adds another wrinkle to them; I'd almost wish we would just jump directly to Scheme-Bound Cookies insofar as that might make things easier to reason about.

A few other issues:

1. Could we exempt __HOST and __SECURE cookies from this feature? Such cookies should already be immune from HTTP->HTTPS exploit, and this alternative might help encourage adoption of these prefixes and avoid causing sites to start sprinkling SameSite=None on all their new cookies.

The __Host- and __Secure- prefixes are not immune from this attack. They prevent the cookie from being leaked when the destination origin is HTTP, which is to do with cookie confidentiality and integrity. They do nothing about the initiator origin being HTTP, which is to do with CSRF.

[EricLaw-MSFT]

> The __Host- and __Secure- prefixes are not immune from this attack.

> They prevent the cookie from being leaked when the destination origin is HTTP, which is to do with cookie confidentiality and integrity.

> They do nothing about the initiator origin being HTTP, which is to do with CSRF.

The __Host and __Secure cookie prefixes can only be used on cookies set from HTTPS with the Secure attribute, meaning that you cannot create a cookie with such a prefix from a HTTP context. A prefixed-cookie is thus inherently scheme-bound (HTTPS only) which I think is an interesting and useful characteristic. But you're right that SchemeBoundedness won't provide the same anti-CSRF protections as SameSite.

[David Benjamin]

On Fri, May 22, 2020 at 5:28 PM 'EricLaw-MSFT' via blink-dev <blin...@chromium.org> wrote:

> The __Host- and __Secure- prefixes are not immune from this attack.

> They prevent the cookie from being leaked when the destination origin is HTTP, which is to do with cookie confidentiality and integrity.

> They do nothing about the initiator origin being HTTP, which is to do with CSRF.

The __Host and __Secure cookie prefixes can only be used on cookies set from HTTPS with the Secure attribute, meaning that you cannot create a cookie with such a prefix from a HTTP context. A prefixed-cookie is thus inherently scheme-bound (HTTPS only) which I think is an interesting and useful characteristic. But you're right that SchemeBoundedness won't provide the same anti-CSRF protections as SameSite.

It is a very useful characteristic! In terms of deviations between cookies and the standard same-origin policy, is probably the one with the most security impact. I hope we can improve on that situation in time. But it doesn't directly apply here, so it wouldn't make sense to introduce an exception here. That would force sites to choose whether to fix the cookie scopes, or the CSRF protections, but not both.

 

--

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/8933ced9-846b-412f-88eb-852fab681380%40chromium.org.

[Steven Bingler]

Thanks for your input! I've updated the Chrome Platform Status page to indicate mixed signals for Edge.

On Thursday, May 21, 2020 at 3:54:35 PM UTC-7, bay...@gmail.com wrote:

For Edge, I think you can put us down as "Neutral" or, failing that, "Public Mixed Signals." I think it's reasonable to Prototype/Experiment with this and see what it breaks. I think the Explainer is good, and I especially think the "Examples" section at the bottom is great.

... I'd almost wish we would just jump directly to Scheme-Bound Cookies insofar as that might make things easier to reason about.

Just to clarify here for other readers; “Schemeful same-site” and “Scheme-Bound Cookies” are similar, insofar that they both affect in what ways cookies may be sent/set, but one is not a subset of the other. To keep it brief:

• “Schemeful same-site” affects the browsing contexts cookies will be sent/set in.

• If you're in a cross-site browsing context (either because the scheme is different or because you're on a different registrable domain) a SameSite=Strict cookie will never be sent, regardless of the connection secureness.

• This is the proposal this I2P is about.

• “Scheme-bound cookies” affects the connections the cookies will be sent/set on. 

• If a cookie was set by a secure connection then it will never be sent on an insecure connection, even if the browsing context is same-site.

A quick example in which these two proposals would behave different:

1. A user navigates to https://website.example which contains some embedded resources which want to set and read cookies.

1. A response to the request for https://website.example/setsacookie.jpg has a set-cookie line: ‘mycookie=val; SameSite=Strict’

2. The user then navigates to http://website.example which is the same page as before, served over an insecure connection.

3. The browser checks to see if it can send the cookie to http://website.example/readsacookie.jpg

1. In the current world (i.e. without either proposal) this cookie is allowed to be sent as this is a same-site context: only the registrable domain matters and they match.

2. “Schemeful same-site” would also allow this cookie to be sent, as we're still in a same-site context when considering scheme: the user is on http://website.example and the cookie wants to be sent to http://website.example

3. “Scheme-bound cookies” would not allow this cookie to be sent, as the connection isn't the same as the one the cookie was set by: the cookie was set on https and is trying to be sent on http.

4. Immediately after the browser checks to see if it can send the cookie to https://website.example/readsacookie2.jpg

1. In the current world the cookie is allowed to be sent as this is a same-site context: the registrable domains match.

2. “Schemeful same-site” would not allow this cookie to be sent, as we're now in a cross-site context: the user is on http://website.example and the cookie wants to be sent to https://website.example.

3. “Scheme-bound cookies” would allow this cookie to be sent, as the connection is the same as the one the cookie was set by: the cookie was set on https and is trying to be sent on https.

This also applies to SameSite=Lax cookies and I’m ignoring any sort of mixed content upgrading/blocking.

 

Finally, I kindly request that any questions regarding “Scheme-bound cookies” be directed here, this way we can keep this thread on topic.

A few other issues:

1. Could we exempt __HOST and __SECURE cookies from this feature? Such cookies should already be immune from HTTP->HTTPS exploit, and this alternative might help encourage adoption of these prefixes and avoid causing sites to start sprinkling SameSite=None on all their new cookies.

I agree with David on this point. 

2. I assume this change will continue to apply when both "http://site" and "https://site" are both secure contexts (specifically, http[s]://localhost)? Originally I was going to propose that we should not change behavior for that case (because there's no security value in doing so), but in thinking about it further, it seems like having the change apply to localhost as well might prevent a web developer from getting a surprise when moving from self-hosting their dev site locally to publishing it to a live/production site.

Yes, this will apply to localhosts. 

3. In the explainer, it says "This means that both secure and insecure origins will retain access to the same set of cookies. I.e., if a user visits http://site.example and it sets a cookie then when that user then visits https://site.example the site can still read that same cookie." I don't think that's generally true, unless the cookie is explicitly set with SameSite=None, right?

This is one of those cases where scheme-bound cookies and schemeful same-site show their differences, see my above example on why this is true. I'll update the explainer to try and clear this up more proactively. 

Thanks

[Steven Bingler]

A small change to this I2P:

Instead of warning messages being added to the developer console they have instead been added as new issue types to the DevTools Issues tab which should prevent spamming developers.

I believe that console warnings generally warrant an I2S or I2D, but should I create an intent to launch these issues?

Example of a new issue

Thanks,

Steven

[Yoav Weiss]

On Thu, Oct 1, 2020 at 10:40 PM Steven Bingler <bin...@chromium.org> wrote:

A small change to this I2P:

Instead of warning messages being added to the developer console they have instead been added as new issue types to the DevTools Issues tab which should prevent spamming developers. 

I believe that console warnings generally warrant an I2S or I2D, but should I create an intent to launch these issues?

From my perspective, since this is not spamming developers' consoles, no I2D is needed.

I think you can go ahead with it for now, assuming other API owners don't think differently.

 

--

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/f9015992-16a1-4b36-b5fd-5885242f127en%40chromium.org.