Intent to Deprecate and Remove: Non-ASCII characters in cookie domain attributes

[Johann Hofmann]

Contact emails

joha...@chromium.org

Explainer

None

Specification

https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/#section-5.5

Summary

To align with the latest specification in RFC 6265bis, Chromium will reject cookies with a "Domain" attribute that contains a non-ASCII character (e.g. Domain=éxample.com).

Blink component

Blink>Network

Motivation

Support for IDN domain attributes in cookies has been long unspecified, with Chromium, Safari and Firefox all behaving differently. https://github.com/httpwg/http-extensions/issues/1707 fixes this issue by standardizing Firefox's behavior of rejecting cookies with non-ASCII domain attributes. Since Chromium has previously accepted non-ASCII characters and tried to convert them to normalized punycode for storage, we will now apply stricter rules and require valid ASCII (punycode if applicable) domain attributes.

Initial public proposal

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

There is a general risk of breakage compared to past Chromium versions from rejecting previously accepted cookies, but UMA measurements show the percentage of cookies with non-ASCII characters (including potentially invalid cookies) to be below 0.0001%. This change improves interoperability by aligning with what Firefox is shipping and what Safari aims to ship as well.

Gecko: Positive (https://github.com/httpwg/http-extensions/issues/1707)

WebKit: Positive (https://github.com/httpwg/http-extensions/issues/1707)

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Debuggability

TBD

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

Yes

Flag name

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1296537

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5534966262792192

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

What's the deprecation period you had in mind?

Also, from a technical perspective, it might be worthwhile to talk to folks that did past cookie related deprecations, to make sure you're reusing the same path for reporting them to the devtools. Also also, it'd be great if that deprecation would result in Deprecation Reports, if at all feasible.

On Fri, Jun 3, 2022 at 12:21 PM Johann Hofmann <joha...@chromium.org> wrote:

Contact emails

joha...@chromium.org

Explainer

None

Specification

https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/#section-5.5

Summary

To align with the latest specification in RFC 6265bis, Chromium will reject cookies with a "Domain" attribute that contains a non-ASCII character (e.g. Domain=éxample.com).

Blink component

Blink>Network

Motivation

Support for IDN domain attributes in cookies has been long unspecified, with Chromium, Safari and Firefox all behaving differently. https://github.com/httpwg/http-extensions/issues/1707 fixes this issue by standardizing Firefox's behavior of rejecting cookies with non-ASCII domain attributes. Since Chromium has previously accepted non-ASCII characters and tried to convert them to normalized punycode for storage, we will now apply stricter rules and require valid ASCII (punycode if applicable) domain attributes.

Initial public proposal

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

There is a general risk of breakage compared to past Chromium versions from rejecting previously accepted cookies, but UMA measurements show the percentage of cookies with non-ASCII characters (including potentially invalid cookies) to be below 0.0001%.

Any public use counters you could share?

Or is that something we couldn't add due to cookies being processed outside the renderer?

 

This change improves interoperability by aligning with what Firefox is shipping and what Safari aims to ship as well.

Gecko: Positive (https://github.com/httpwg/http-extensions/issues/1707)

WebKit: Positive (https://github.com/httpwg/http-extensions/issues/1707)

Our typical process for getting such signals is https://bit.ly/blink-signals

At the same time, as you said above, Mozilla is already shipping the behavior you want to align on here. 

Can you send a request to webkit-dev, letting them know that we're moving on that front?

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Debuggability

TBD

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

Yes

Flag name

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1296537

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5534966262792192

This intent message was generated by Chrome Platform Status.

--
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/CAD_OO4hVsjFA06ytmbNvn-bfUXDGur0ESSMxEO-o-96sCNAiOQ%40mail.gmail.com.

[Mike Taylor]

Usage is quite low, but it would be good to know if there are any patterns that might affect certain locales more than others. Is there any way we can get a sample list of domains to spot check?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUdCoWru_bd826snHc24eHk7uUYW_HJF-ox0ihaqanX9g%40mail.gmail.com.

[Johann Hofmann]

Hi Mike and Yoav, thank you for the guidance.

Regarding public use counters, devtools messaging, reporting and getting more precise information on domains:

I'm working on getting a devtools deprecation warning in place, and the other pieces should be easy to integrate from there, according to sbingler. Happy to report back once that's done.

> What's the deprecation period you had in mind?

Usage is quite low but there's also no particular rush on this, so I was thinking of a deprecation period of two releases after we get developer warnings in place, which might happen by M105, so estimated M107.

> Our typical process for getting such signals is https://bit.ly/blink-signals

Huh! I read that document and interpreted "Statement made through an Official Standards Process for that implementation" as given since both Mozilla and Apple voiced their support in the HTTP WG. If this is the case, asking them to confirm via their standards positions channels feels somewhat noisy, no?

> At the same time, as you said above, Mozilla is already shipping the behavior you want to align on here.

 

Right, I'll update the status to "Shipping", apologies.

> Can you send a request to webkit-dev, letting them know that we're moving on that front?

I'm happy to do that, or alternatively ping John on the GitHub issue if you agree with me that this is preferable (being more targeted and less noisy) to an email to webkit-dev.

Thanks!

[Yoav Weiss]

On Monday, June 6, 2022 at 6:57:53 AM UTC+2 Johann Hofmann wrote:

Hi Mike and Yoav, thank you for the guidance.

Regarding public use counters, devtools messaging, reporting and getting more precise information on domains:

I'm working on getting a devtools deprecation warning in place, and the other pieces should be easy to integrate from there, according to sbingler. Happy to report back once that's done.

That's great, thanks!!

 

> What's the deprecation period you had in mind?

Usage is quite low but there's also no particular rush on this, so I was thinking of a deprecation period of two releases after we get developer warnings in place, which might happen by M105, so estimated M107.

Sounds reasonable.

 

> Our typical process for getting such signals is https://bit.ly/blink-signals

Huh! I read that document and interpreted "Statement made through an Official Standards Process for that implementation" as given since both Mozilla and Apple voiced their support in the HTTP WG. If this is the case, asking them to confirm via their standards positions channels feels somewhat noisy, no?

IIRC, WebKit folks were fine with quoting support from webkit engineers as a replacement for an official request, but Mozilla were not. In this case, this may be sufficient.

Chris - do I remember correctly? Should we add such an exception to our docs?

 

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4hVsjFA06ytmbNvn-bfUXDGur0ESSMxEO-o-96sCNAiOQ%40mail.gmail.com.

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

[Daniel Bratell]

If Mozilla is already shipping this behaviour, then there is no need to ask them if they support that change. We do assume that they approve of all functionality they are shipping.

On the other hand, I saw no response to Mike Taylor's question about localized error spots: The usage is globally low, but is it possible that it is significantly higher in some country? I do not think it's likely if this is already Mozilla's behaviour, but his suggestion to take a look at a few affected sites seems like an easy way to calm any concerns.

/Daniel

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/33018c98-5b51-4f8e-8f1c-411d8154ba33n%40chromium.org.

[Mike Taylor]

Thanks Daniel! Johann and I chatted offline yesterday and he's got a plan to look into this, and will follow up once he has more data.

[Chris Harrelson]

On Wed, Jun 8, 2022 at 12:14 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Monday, June 6, 2022 at 6:57:53 AM UTC+2 Johann Hofmann wrote:

Hi Mike and Yoav, thank you for the guidance.

Regarding public use counters, devtools messaging, reporting and getting more precise information on domains:

I'm working on getting a devtools deprecation warning in place, and the other pieces should be easy to integrate from there, according to sbingler. Happy to report back once that's done.

That's great, thanks!!

 

> What's the deprecation period you had in mind?

Usage is quite low but there's also no particular rush on this, so I was thinking of a deprecation period of two releases after we get developer warnings in place, which might happen by M105, so estimated M107.

Sounds reasonable.

 

> Our typical process for getting such signals is https://bit.ly/blink-signals

Huh! I read that document and interpreted "Statement made through an Official Standards Process for that implementation" as given since both Mozilla and Apple voiced their support in the HTTP WG. If this is the case, asking them to confirm via their standards positions channels feels somewhat noisy, no?

IIRC, WebKit folks were fine with quoting support from webkit engineers as a replacement for an official request, but Mozilla were not. In this case, this may be sufficient.

Chris - do I remember correctly? Should we add such an exception to our docs?

Unfortunately this doesn't count as a signal. An email to webkit-dev is required, with response, to count as anything other than "No signals". I'm glad they agreed to this change in the HTTP WG though, that's a good sign.

Also, I can see how "Official Standards Process" can be construed as an ambiguous term; I've clarified to "Official Standards Signal Process" in the signals document that it means the process spelled out in the last section there.

 

 

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/CAD_OO4hVsjFA06ytmbNvn-bfUXDGur0ESSMxEO-o-96sCNAiOQ%40mail.gmail.com.

--
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/CAL5BFfUdCoWru_bd826snHc24eHk7uUYW_HJF-ox0ihaqanX9g%40mail.gmail.com.

--
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/33018c98-5b51-4f8e-8f1c-411d8154ba33n%40chromium.org.

[Johann Hofmann]

Understood, thanks for clarifying that, Chris!

[Daniel Bratell]

On 2022-06-09 04:22, Martin Thomson wrote:

On Wed, Jun 8, 2022 at 10:55 PM Daniel Bratell <brat...@gmail.com> wrote:

If Mozilla is already shipping this behaviour, then there is no need to ask them if they support that change. We do assume that they approve of all functionality they are shipping.

I want to address this point, as I think Chris Harrelson has done.  Just because something ships in Firefox, that doesn't mean we think that it is good for the web.  There's something of a long list of things we don't like, but ship for various reasons despite that.  To pick an example that isn't particularly controversial, we still ship unsecured HTTP.

So we do appreciate you asking directly rather than making inferences and then potentially misrepresenting our position.

To save a bit of time on this bit of minutiae: this change is good and the work that Johann, Mike, and others on the Chrome team have done to improve compatibility with cookies is greatly appreciated.

Correction appreciated! I was way too cavalier with that statement.

/Daniel

[Martin Thomson]

On Wed, Jun 8, 2022 at 10:55 PM Daniel Bratell <brat...@gmail.com> wrote:

If Mozilla is already shipping this behaviour, then there is no need to ask them if they support that change. We do assume that they approve of all functionality they are shipping.

I want to address this point, as I think Chris Harrelson has done.  Just because something ships in Firefox, that doesn't mean we think that it is good for the web.  There's something of a long list of things we don't like, but ship for various reasons despite that.  To pick an example that isn't particularly controversial, we still ship unsecured HTTP.

[Johann Hofmann]

Thanks everyone, a quick update:

Thank you Martin for chiming in, I really appreciate your comment! I updated the Chromestatus entry to reflect the browser signals more accurately.

I also sent a request for position to webkit-dev.

Addressing Mike's and Daniel's concern about localized hot spots (sorry for the delay):

Looking at global usage data, it seems to be consistently low in all countries. There are some regional differences, with Brazil, Croatia and Belarus having slightly elevated usage at 0.2%, all likely subject to randomness/noise as we're looking at a very small subset of data at this point. We might be able to find out more about those during deprecation, but overall I'm not very concerned.

Thanks!

Johann

[Chris Harrelson]

LGTM1

--

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/CAD_OO4hs%2BgbCuXxWgOmVoVQ9zv9hRnnKYwi%2BMS9ciX76%3DVD%2Buw%40mail.gmail.com.

[Mike Taylor]

LGTM2

[Daniel Bratell]

LGTM3 - I agree that those local peaks are not scary enough so this should be ok to ship.

(This might be a duplicate but I'm not going to wait any longer for my first mail to arrive!)

/Daniel