Intent to Prototype and Ship: Control character handling in cookies

[Andrew Williams]

Contact emails
awi...@chromium.org, mike...@chromium.org

Explainer

https://github.com/httpwg/http-extensions/issues/1531

https://github.com/httpwg/http-extensions/pull/1589

Specification

https://github.com/httpwg/http-extensions/blob/main/draft-ietf-httpbis-rfc6265bis.md

Summary

Updates how control characters in cookie data are handled. Specifically, the tab character is now permitted, but all other control characters cause the entire cookie to be rejected (previously the \x00, \x0D, and \x0A characters in a cookie line caused it to be truncated instead of rejected entirely, which could have enabled malicious behavior in certain circumstances). This behavior is also in line with the latest drafts of RFC6265bis.

Blink component

Internals>Network>Cookies

Motivation

In the case where attacker controlled data is used to set a new cookie, having certain control characters truncate the cookie line could result in security-related cookie attributes being ignored.  This behavior may also lead to cookie data corruption when control characters are introduced, which may cause unpredictable behavior on the application side (more so than cookies not being set, which is a case that applications should already handle). Having control characters result in the whole cookie being rejected helps mitigate these concerns and aligns Chrome with RFC6265bis.  For the tab character, although it falls in the control character range (\x00 - \x1F, \x7F), it’s a printable character and allowed by other browsers. Treating it the same way that the space character is treated makes sense intuitively, eliminates a potential fingerprinting vector, and aligns Chrome with RFC6265bis.

Initial public proposal

TAG review

N/A: this change is already specified in RFC 6265bis and is a relatively minor change to what's already implemented in Chrome (to improve spec compliance).

TAG review status
Not applicable

Risks

N/A

Interoperability and Compatibility

WebKit / Safari:

 - All control characters except the tab character cause the cookie to be rejected if present in the name and cause the rest of the cookie line to be truncated if present in the value

 

Gecko / Firefox:

 - 0x00 in the cookie value causes the rest of the value to be truncated (but subsequent attributes are preserved)

 - 0x00 in the cookie name causes the rest of the name and the value to be truncated (but subsequent attributes are preserved)

 - 0x0d and 0x0a cause the entire cookie line to be truncated (attributes ignored)

 - 0x01 through 0x09 (the tab character), 0x0b through 0x0c, and 0x0e through 0x1f cause the cookie to be rejected if they are present in the name, but are allowed in the cookie value

 - 0x7f is allowed in the cookie name and cookie value

 

The following issues exist reporting these differences:

• Firefox - https://bugzilla.mozilla.org/show_bug.cgi?id=1702031#c1

• WebKit - https://bugs.webkit.org/show_bug.cgi?id=229088

 

Allowing tab characters in cookie names aligns Chrome with Safari but not Firefox, and allowing tabs in the cookie value aligns Chrome with both.

 

Regarding control characters (not including tab), what will change in Chrome is the handling of 0x00, 0x0d, and 0x0a characters.  Today, Chrome truncates cookie lines when these characters are encountered, and this intent proposes having these characters result in cookie rejection instead.  Rejecting cookie names containing these characters aligns Chrome with Safari but not Firefox, but rejecting cookie values containing these characters is inconsistent with existing Safari or Firefox behavior.  However, these changes unify Chrome’s control character handling behavior, better align Chrome with RFC6265bis, and also help prevent a class of cookie attribute removal attacks (when malicious input is used to build a cookie line under certain conditions).

 

Gecko: N/A - these changes seem too small to justify this effort
WebKit: N/A - these changes seem too small to justify this effort
Web developers: N/A - these changes are relatively small and are in alignment with the RFC, other browsers, and/or existing behavior

Debuggability

DevTools debugging support will be implemented along with this change. Rejected response cookies are already shown in DevTools in the Network panel, with a status explaining why they were rejected. Another status will be added to annotate cookies rejected due to control characters.

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

In Progress - https://chromium-review.googlesource.com/c/chromium/src/+/3084521

Flag name

UpdatedCookieControlCharacterChecks

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

M96

Link to entry on the Chrome Platform Status

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

Requesting approval to ship?

Yes

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

Hey Andrew! Thanks for working on this, this seems like a significant compatibility gap (with security implications) that would be great to close.

On Tuesday, August 24, 2021 at 3:45:50 PM UTC+2 Andrew Williams wrote:

Contact emails
awi...@chromium.org, mike...@chromium.org

Explainer

https://github.com/httpwg/http-extensions/issues/1531

https://github.com/httpwg/http-extensions/pull/1589

Specification

https://github.com/httpwg/http-extensions/blob/main/draft-ietf-httpbis-rfc6265bis.md

Summary

Updates how control characters in cookie data are handled. Specifically, the tab character is now permitted, but all other control characters cause the entire cookie to be rejected (previously the \x00, \x0D, and \x0A characters in a cookie line caused it to be truncated instead of rejected entirely, which could have enabled malicious behavior in certain circumstances). This behavior is also in line with the latest drafts of RFC6265bis.

Blink component

Internals>Network>Cookies

Motivation

In the case where attacker controlled data is used to set a new cookie, having certain control characters truncate the cookie line could result in security-related cookie attributes being ignored.  This behavior may also lead to cookie data corruption when control characters are introduced, which may cause unpredictable behavior on the application side (more so than cookies not being set, which is a case that applications should already handle). Having control characters result in the whole cookie being rejected helps mitigate these concerns and aligns Chrome with RFC6265bis.  For the tab character, although it falls in the control character range (\x00 - \x1F, \x7F), it’s a printable character and allowed by other browsers. Treating it the same way that the space character is treated makes sense intuitively, eliminates a potential fingerprinting vector, and aligns Chrome with RFC6265bis.

In the past, moving to a stricter models that forbade certain characters resulted in at least some breakage of non-malicious content. I doubt this one would be significantly different.

Do you have a sense of the resulting breakage? If not, I think it'd make sense to add metrics to our cookie parsing algorithm and see what that breakage would look like.

  

Initial public proposal

TAG review

N/A: this change is already specified in RFC 6265bis and is a relatively minor change to what's already implemented in Chrome (to improve spec compliance).

I agree that this change is in lower layers than those the TAG usually deals with.

 

TAG review status
Not applicable

Risks

N/A

Interoperability and Compatibility

WebKit / Safari:

 - All control characters except the tab character cause the cookie to be rejected if present in the name and cause the rest of the cookie line to be truncated if present in the value

 

Gecko / Firefox:

 - 0x00 in the cookie value causes the rest of the value to be truncated (but subsequent attributes are preserved)

 - 0x00 in the cookie name causes the rest of the name and the value to be truncated (but subsequent attributes are preserved)

 - 0x0d and 0x0a cause the entire cookie line to be truncated (attributes ignored)

 - 0x01 through 0x09 (the tab character), 0x0b through 0x0c, and 0x0e through 0x1f cause the cookie to be rejected if they are present in the name, but are allowed in the cookie value

 - 0x7f is allowed in the cookie name and cookie value

 

The following issues exist reporting these differences:

• Firefox - https://bugzilla.mozilla.org/show_bug.cgi?id=1702031#c1

• WebKit - https://bugs.webkit.org/show_bug.cgi?id=229088

 

Allowing tab characters in cookie names aligns Chrome with Safari but not Firefox, and allowing tabs in the cookie value aligns Chrome with both.

 

Regarding control characters (not including tab), what will change in Chrome is the handling of 0x00, 0x0d, and 0x0a characters.  Today, Chrome truncates cookie lines when these characters are encountered, and this intent proposes having these characters result in cookie rejection instead.  Rejecting cookie names containing these characters aligns Chrome with Safari but not Firefox, but rejecting cookie values containing these characters is inconsistent with existing Safari or Firefox behavior.  However, these changes unify Chrome’s control character handling behavior, better align Chrome with RFC6265bis, and also help prevent a class of cookie attribute removal attacks (when malicious input is used to build a cookie line under certain conditions).

 

Gecko: N/A - these changes seem too small to justify this effort
WebKit: N/A - these changes seem too small to justify this effort

I somewhat agree that asking for a position here would be an overkill, but would love to get a signal from both Mozilla and Safari on their intents to align with the RFC. (the former seems more likely than the latter, as this seems like a CFNetwork issue)

At the same time, the issues seem sufficient for that purpose, assuming folks there respond.

Web developers: N/A - these changes are relatively small and are in alignment with the RFC, other browsers, and/or existing behavior

Yeah, developers are unlikely to be happy about this from a breakage perspective, even if it'd reduce compat issues. The main thing we can do about that is ensure breakage is minimal before shipping.

[Daniel Bratell]

Even if browsers are currently slightly incompatible, it seems this change will short term make them more incompatible. As Yoav said, it would be good to have an idea about how common this is, i.e. how often will cookies that are today truncated instead be rejected?

/Daniel

--
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/e2de8b96-8878-47fe-99e2-5497b96c9adcn%40chromium.org.

[Andrew Williams]

Thanks for the feedback/questions Yoav and Daniel.

We have some metrics on Chrome's existing behavior to truncate cookie lines containing \x00, \x0d, and \x0a (specifically, in cases where the truncation affects the cookie name or the cookie value).  The percentage of cookies with truncated names or values is quite low, although I'm still waiting on approval to release the exact percentage.  We don't have any metrics for cases where truncation affected cookie attribute parsing (for example, the malicious case this intent aims to address) or where truncation was harmless (for example, a newline as the last character in the cookie line), though.  Especially for the latter case, it does seem plausible that certain sites could be constructing cookie lines in such a way that control characters slip in unnoticed.  We will add new metrics to cover these cases so that we can better predict the level of breakage that these changes may have.

-Andrew

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/44805dc7-edd8-218d-dcbe-9c589509b633%40gmail.com.

[Andrew Williams]

Here is the percentage for the metric mentioned in my last email: over a 7 day period, 0.00004% of cookies seen in the stable version of Chrome had truncated names and/or values.

Ultimately our plan is to ship this feature behind a kill switch that we could flip if major issues are reported. With that in mind, and given the low number of truncated cookie names/values observed via our existing metrics, would it make sense to implement and collect the new metrics in parallel with rolling out the changes described in this I2P&S? Or do you think taking the more cautious approach and implementing/collecting the new metrics before landing this change is a better way forward (despite taking more time)?

-Andrew

[Yoav Weiss]

Hey Andrew,

Given that the metrics are not a superset of what you're trying to deprecate, could you please add CountDeprecation metrics of the case you are intending to deprecate? That would ensure .e.g deprecation reports are sent to folks that happen to have such cookies.

Even though you haven't really asked, from my perspective, it's also fine to add a console deprecation message at this point, in parallel to the metrics.

Cheers :)

Yoav

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/e2de8b96-8878-47fe-99e2-5497b96c9adcn%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+unsubscribe@chromium.org.

[Ian Clelland]

On Fri, Sep 3, 2021 at 4:55 AM Yoav Weiss <yoav...@chromium.org> wrote:

Hey Andrew,

Given that the metrics are not a superset of what you're trying to deprecate, could you please add CountDeprecation metrics of the case you are intending to deprecate? That would ensure .e.g deprecation reports are sent to folks that happen to have such cookies.

Even though you haven't really asked, from my perspective, it's also fine to add a console deprecation message at this point, in parallel to the metrics.

FYI, CountDeprecation will take care of adding that console message for you, as well as:

 - Generating a report object which can be seen with a ReportingObserver,

 - Sending that report to any configured endpoints for the document, and

 - Counting the usage for UMA, so that we can track the (hopefully) declining usage of the deprecated feature.

Ian

Cheers :)

Yoav

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/e2de8b96-8878-47fe-99e2-5497b96c9adcn%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/44805dc7-edd8-218d-dcbe-9c589509b633%40gmail.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/fcb32661-cecb-4f5a-a29d-9f3cdfbc5395n%40chromium.org.

[Andrew Williams]

Sounds good - we will add the CountDeprecation metrics. Thanks for the suggestion, Yoav, and thank you Ian for the additional info.

-Andrew

[Yoav Weiss]

Sounds good! Can you please ping this thread once results start coming in? Thanks! :)

Cheers :)

Yoav

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/e2de8b96-8878-47fe-99e2-5497b96c9adcn%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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/44805dc7-edd8-218d-dcbe-9c589509b633%40gmail.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.

[Mike West]

I don't think `countDeprecation` is going to work here, insofar as that's a Blink-layer concept, and the network stack isn't going to have an understanding of page views or use counters or etc. If we've wired things up such that deprecation reports can be triggered from the network stack, lovely, but I'm not sure that's the case.

Another approach that might be reasonable to approach might be to roll this out on a percentage-basis, starting with a substantial portion of beta, then rolling to stable iff we're confident in that experience?

This feels like both the right directional and philosophical thing to do with cookies. I'd like to see it ship, and a staged rollout might well be a reasonable way of gaining confidence in our ability to do so?

-mike

Cheers :)

Yoav

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/e2de8b96-8878-47fe-99e2-5497b96c9adcn%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/44805dc7-edd8-218d-dcbe-9c589509b633%40gmail.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/fcb32661-cecb-4f5a-a29d-9f3cdfbc5395n%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/984b9bba-57f7-4145-9e1e-ee50601aae68n%40chromium.org.

[Yoav Weiss]

I may very well be wrong, but it seems like CookieUtils::EmitCookieWarningsAndMetrics has the right plumbing to reach RenderFrameHost, and from it, get a ReportingSource that can enable us to send deprecation reports (even if through a different mechanism than CountDeprecation).

Ian - thoughts on the above?

[Ian Clelland]

That looks right -- that code path won't get you anywhere near adding a console message, as far as I can tell, but you would be able to queue a report that way. Ideally, we'd have something like deprecation.cc for browser-side that would handle the UMA as well as formatting the report body consistently. As a first pass, until we have more that one browser-generated deprecation report, just generating and queuing it would work.

[Andrew Williams]

Thanks for the feedback Mike, Yoav, and Ian.  I will explore the feasibility of using CountDeprecation (or something similar) from the cookie-related code and will report back once I have an update on this.

-Andrew

[Steven Bingler]

Hi Ian and Yoav,

I believe the general guidance now for warning users of some change is to use DevTools Issues rather than console warnings. Would using Issues, instead of console warnings, be acceptable to you? (This would be in addition to the reports.)

Also, for posterity, it is possible to emit a console warning starting from EmitCookieWarningsAndMetrics() with a little work. We used to do just that for SameSite warnings before we transitioned them to DevTools Issue [1] [2] (many refactors ago). It looks like most of the necessary functions still exist, so it shouldn't be too hard to recreate that functionality if needed.

Thanks,

Steven

Cheers :)

Yoav

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/e2de8b96-8878-47fe-99e2-5497b96c9adcn%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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/44805dc7-edd8-218d-dcbe-9c589509b633%40gmail.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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fcb32661-cecb-4f5a-a29d-9f3cdfbc5395n%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+unsubscribe@chromium.org.

[Yoav Weiss]

On Fri, Sep 17, 2021 at 6:36 PM Steven Bingler <bin...@chromium.org> wrote:

Hi Ian and Yoav,

I believe the general guidance now for warning users of some change is to use DevTools Issues rather than console warnings. Would using Issues, instead of console warnings, be acceptable to you? (This would be in addition to the reports.)

I don't believe the API OWNERS have a stand on console warnings vs. issues for deprecations. Whatever is the general guidance that will make this visible for developers seems good to me, assuming that issues are prominent in the UI and manage to grab the median developer's attention.

Thanks,

Steven

Cheers :)

Yoav

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/e2de8b96-8878-47fe-99e2-5497b96c9adcn%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/44805dc7-edd8-218d-dcbe-9c589509b633%40gmail.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/fcb32661-cecb-4f5a-a29d-9f3cdfbc5395n%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.

[Daniel Bratell]

The last thing happening in this thread was that we decided to wait for data. What is the current status of those usecounters, have they reached the user base now?

/Daniel

[Andrew Williams]

Hi Daniel,

Thanks for following up on this. UMA metrics to count the prevalence of \x00, \x0d, and \x0a characters in cookie strings will roll out with the M96 release.  We'll post back here once those metrics are available.

Regarding deprecation warnings, we've mapped out how to generate DevTools Issues that would warn developers when cookies containing these characters are detected, but we haven't implemented anything yet.  Also, we haven't implemented the sending of deprecation reports yet. Both are still on our radar, though.

-Andrew

[Chris Harrelson]

Hi Andrew,

M96 has now shipped. Is the UseCounter data now available?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkWGVtOGPxUqQfk5u5Ds9BfiR5Ks%3DjkBp8NQ9AS2w-cL9g%40mail.gmail.com.

[Andrew Williams]

Hi Chris,

We've collected 7 days worth of metrics since M96 went live, and the number of cookie strings containing a \x00, \x0d, or \x0a character is very small compared to the total number of cookie strings processed.  I'll post the percentages here once I get approval to do so, likely next week given the holiday in the U.S..

-Andrew

[Andrew Williams]

Regarding cookie strings that get truncated in Chrome today but that still get treated as valid:

0.0007 % of valid cookie strings were truncated by a \x0a character
<0.0001 % of valid cookie strings were truncated by a \x0d character
<0.0001 % of valid cookie strings were truncated by a \x00 character

Thus, with the proposed change to reject cookie strings containing any of these characters, 0.0007% of cookie strings would be rejected.

-Andrew

[Yoav Weiss]

LGTM1 to ship given the low numbers, although we still want to do this carefully.

Are such cookies currently issuing deprecation reports? Have we talked to Chrome Enterprise folks about their thoughts on adding an enterprise policy?

Thanks,

Steven

Cheers :)

Yoav

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/e2de8b96-8878-47fe-99e2-5497b96c9adcn%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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/44805dc7-edd8-218d-dcbe-9c589509b633%40gmail.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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fcb32661-cecb-4f5a-a29d-9f3cdfbc5395n%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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/984b9bba-57f7-4145-9e1e-ee50601aae68n%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+unsubscribe@chromium.org.

[Mike West]

LGTM2, with less caution than Yoav. :)

This seems safe to me, and philosophically correct for the platform. Good luck shipping it!

-mike

Thanks,

Steven

Cheers :)

Yoav

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/e2de8b96-8878-47fe-99e2-5497b96c9adcn%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/44805dc7-edd8-218d-dcbe-9c589509b633%40gmail.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/fcb32661-cecb-4f5a-a29d-9f3cdfbc5395n%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/984b9bba-57f7-4145-9e1e-ee50601aae68n%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.

[Daniel Bratell]

LGTM3

/Daniel

[Andrew Williams]

Thanks for the LGTMs Yoav, Mike, and Daniel!

Yoav, we haven't implemented warnings of any kind (DevTools Issues or deprecation reports via the Reporting API) for this yet... This effort has been on the backburner but I aim to revisit it soon. Also, I'm happy to reach out to Chrome Enterprise about this - do you have a recommendation regarding a good PoC? Also, our plan is still to implement this behind a feature flag that could be disabled via Finch in the event that significant breakage is encountered (although I know Finch updates are not a panacea).

-Andrew

[Daniel Bratell]

I can't point to any individual and https://www.chromium.org/developers/enterprise-changes points to a mailing list, so I guess that mailing list, or those frequenting it, is a start point.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkU7EN5yMxj3sNXdn_jWJdA4ni%3D3RLjxj17oVKrcxqxEXA%40mail.gmail.com.

[Mike Taylor]

Thanks Daniel - I looped Andrew in off-list to some Enterprise folks.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1bd79b49-6404-b315-1c61-acfe0ca4f24b%40gmail.com.

[Yoav Weiss]

On Wed, Dec 1, 2021 at 7:02 PM Andrew Williams <awi...@chromium.org> wrote:

Thanks for the LGTMs Yoav, Mike, and Daniel!

Yoav, we haven't implemented warnings of any kind (DevTools Issues or deprecation reports via the Reporting API) for this yet...

That part seems paramount before starting with the actual removal. What timelines do you have in mind?

[Andrew Williams]

Thanks for the link, Daniel, and thank you to Mike as well for sending me a Chrome Enterprise PoC to reach out to.

Yoav, do you think waiting two or three months between when we implement DevTools Issues / deprecation reports for this and when we do the removal would be sufficient?  Is there a precedent for the minimum amount of time to provide notice for changes like this that don't seem like they will have widespread impact but that we want to proceed with caution on nonetheless?

-Andrew

[Yoav Weiss]

On Thu, Dec 2, 2021 at 8:14 PM Andrew Williams <awi...@chromium.org> wrote:

Thanks for the link, Daniel, and thank you to Mike as well for sending me a Chrome Enterprise PoC to reach out to.

Yoav, do you think waiting two or three months between when we implement DevTools Issues / deprecation reports for this and when we do the removal would be sufficient? 

That sounds reasonable to me. The known risk seems low, I'm mostly concerned about the unknown risk. I'm hoping that a couple of months of deprecation reports + enterprise policy can help us reduce risks on that front.

[Andrew Williams]

Awesome, thanks for the feedback, Yoav.

The Chrome Enterprise team also recommended having an enterprise policy in for this change just in case, and they recommended having it be available for at least a couple of milestones after we've implemented the change.  We will plan on that as well.

I'll post back here once we have an update on implementing the DevTools Issue + deprecation reporting.

-Andrew 

[Andrew Williams]

Hey everyone,

A few updates on this - TL;DR: we'd like to proceed with a subset of what was originally proposed.

 - During implementation we found some differences in how cookies containing \x00, \x0D, and \x0A characters are handled when set via JavaScript and set via Set-Cookie headers. For cookies set via headers, Chrome rejects the entire HTTP response if a \x00 character is present. For the \x0D and \x0A characters, the HTTP header parsing code treats each character as if it was a \x0D\x0A (CRLF) character sequence, truncating Set-Cookie header strings that contain these characters before the cookie parsing code gets them. This behavior is not specific to parsing the Set-Cookie header, and seems counter to the spec. It would be great to change this if possible, but we would need new metrics to gauge how common this is since our existing metrics were only collected from the point of view of the cookie parsing code. Also, we'd want a new blink-dev thread for this, since we'd likely want to change this behavior for header parsing in general. We'd like to defer on changing the header parsing behavior for now. One step we did take towards this is updating the existing cookie control character handling WPTs to test setting via headers as well so that behavior by other browsers can be seen. 

 - Whether to allow the tab character inside of a cookie name, value, attribute name, or attribute value (i.e. internal tabs) is currently being discussed and the spec position might be reconsidered. We'd like to defer on changing Chrome's current handling of this until that is resolved. Since Chrome blocks cookies containing internal tabs today, changing it to allow cookies with internal tabs should cause minimal breakage, so it should be safe to accompany this change with a blink-dev PSA.

 - What's remaining is to block cookies set via Javascript from containing \x00, \x0D, and \x0A characters. For this we've had deprecation reporting and DevTools warnings (both implemented via a call to CountDeprecation) in place for a while, and we recently added an enterprise policy so that enterprises can disable this change if needed once it's enabled. Also, we re-checked the existing metrics for this recently and usage is less than it was in our previous analysis for all characters.

Do we need a completely new I2S for shipping the subset of these changes (affecting only cookies set via JavaScript), or can we receive new LGTMs on this thread and proceed with the rollout afterward?

Thanks!

-Andrew

[Daniel Bratell]

My LGTM still stands for the remaining subset. I don't think you need a new thread for it. Good detecting to figure all of that out.

/Daniel

[Chris Harrelson]

Same here. No need to wait for further approvals, go ahead with the subset (but please don't forget to update the chromestatus.com entry accordingly).

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/53c31488-63c8-fa27-4446-9536205fc674%40gmail.com.

[Andrew Williams]

Thanks Daniel and Chris! I've enabled this change in the Chrome tip-of-tree and updated the chromestatus.com entry accordingly

-Andrew

[Yoav Weiss]

Still LGTM on my end as well!

On Thu, Aug 17, 2023 at 6:05 PM Julio Cardozo <bhf...@gmail.com> wrote:

Obrigado pela atençao de voces