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 On Wed, Nov 24, 2021 at 12:14 PM Andrew Williams <awil...@chromium.org> wrote: > 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 > > On Wed, Nov 24, 2021 at 11:29 AM Chris Harrelson <chris...@chromium.org> > wrote: > >> Hi Andrew, >> >> M96 has now shipped. Is the UseCounter data now available? >> >> On Thu, Nov 4, 2021 at 7:33 PM Andrew Williams <awil...@chromium.org> >> wrote: >> >>> 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 >>> >>> On Thu, Nov 4, 2021 at 2:37 PM Daniel Bratell <bratel...@gmail.com> >>> wrote: >>> >>>> 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 >>>> On 2021-09-20 07:59, Yoav Weiss wrote: >>>> >>>> >>>> >>>> On Fri, Sep 17, 2021 at 6:36 PM Steven Bingler <bing...@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. >>>> >>>> >>>>> 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 >>>>> <https://chromium.googlesource.com/chromium/src.git/+/1cc31f46c2e6ae658a97b92fbc8c556eba382d3e/content/browser/frame_host/cookie_utils.cc#128>] >>>>> [2 >>>>> <https://chromium.googlesource.com/chromium/src.git/+/1cc31f46c2e6ae658a97b92fbc8c556eba382d3e/content/browser/frame_host/render_frame_host_impl.cc#8309>] >>>>> (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 >>>>> >>>>> On Friday, September 17, 2021 at 8:45:10 AM UTC-7 Andrew Williams >>>>> wrote: >>>>> >>>>>> 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 >>>>>> >>>>>> On Fri, Sep 10, 2021 at 10:11 AM Ian Clelland <iclell...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> 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. >>>>>>> >>>>>>> On Fri, Sep 10, 2021 at 6:42 AM Yoav Weiss <yoavwe...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> I may very well be wrong, but it seems like >>>>>>>> CookieUtils::EmitCookieWarningsAndMetrics >>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/cookie_utils.cc;l=97;drc=8afc9e45a7e96afda8f22ef044d1e7cdc5a6f75a;bpv=1;bpt=1> >>>>>>>> has >>>>>>>> the right plumbing to reach RenderFrameHost, and from it, get a >>>>>>>> ReportingSource >>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_frame_host_impl.cc;l=1730;drc=8afc9e45a7e96afda8f22ef044d1e7cdc5a6f75a?q=RenderFrameHost&ss=chromium%2Fchromium%2Fsrc> >>>>>>>> that >>>>>>>> can enable us to send >>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_frame_host_impl.cc;l=10676;drc=8afc9e45a7e96afda8f22ef044d1e7cdc5a6f75a;bpv=1;bpt=1?q=RenderFrameHost&ss=chromium%2Fchromium%2Fsrc> >>>>>>>> deprecation reports (even if through a different mechanism than >>>>>>>> CountDeprecation). >>>>>>>> >>>>>>>> Ian - thoughts on the above? >>>>>>>> >>>>>>>> On Thu, Sep 9, 2021 at 9:21 PM Mike West <mk...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Sep 9, 2021 at 1:03 PM Yoav Weiss <yoavwe...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Sounds good! Can you please ping this thread once results start >>>>>>>>>> coming in? Thanks! :) >>>>>>>>>> >>>>>>>>>> On Wednesday, September 8, 2021 at 3:59:36 AM UTC+2 Andrew >>>>>>>>>> Williams wrote: >>>>>>>>>> >>>>>>>>>>> Sounds good - we will add the CountDeprecation metrics. Thanks >>>>>>>>>>> for the suggestion, Yoav, and thank you Ian for the additional info. >>>>>>>>>>> >>>>>>>>>>> -Andrew >>>>>>>>>>> >>>>>>>>>>> On Fri, Sep 3, 2021 at 10:07 AM Ian Clelland < >>>>>>>>>>> iclell...@chromium.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Sep 3, 2021 at 4:55 AM Yoav Weiss < >>>>>>>>>>>> yoavwe...@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 >>>>>>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/deprecation.cc;drc=f6f22e82bcd0d50f390b23ee9688c58de5ae0bdc;bpv=1;bpt=1;l=702?q=deprecation&ss=chromium> >>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> On Wednesday, September 1, 2021 at 5:05:44 PM UTC+2 Andrew >>>>>>>>>>>>> Williams wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Aug 27, 2021 at 1:45 PM Andrew Williams < >>>>>>>>>>>>>> awil...@chromium.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for the feedback/questions Yoav and Daniel. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We have some metrics >>>>>>>>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/700dc7fe1578ab5e0e50a6304f2a1960005b8f8b:tools/metrics/histograms/metadata/cookie/histograms.xml;l=56;bpv=1;bpt=0> >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Aug 26, 2021 at 2:22 PM Daniel Bratell < >>>>>>>>>>>>>>> bratel...@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2021-08-25 16:18, Yoav Weiss wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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 awil...@chromium.org, >>>>>>>>>>>>>>>>> miketa...@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 >>>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ECookies> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/uBxq9uCpKx0/m/A5LI0NbyAAAJ>: >>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 <https://www.chromestatus.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+unsubscr...@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 >>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e2de8b96-8878-47fe-99e2-5497b96c9adcn%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 >>>>>>>>>>>>>>>> blink-dev+unsubscr...@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 >>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/44805dc7-edd8-218d-dcbe-9c589509b633%40gmail.com?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 blink-dev+unsubscr...@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 >>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fcb32661-cecb-4f5a-a29d-9f3cdfbc5395n%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 blink-dev+unsubscr...@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 >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/984b9bba-57f7-4145-9e1e-ee50601aae68n%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 blink-dev+unsubscr...@chromium.org. >>> 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkWGVtOGPxUqQfk5u5Ds9BfiR5Ks%3DjkBp8NQ9AS2w-cL9g%40mail.gmail.com?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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkUaj_3ev_ONZojmTm1kS0-qstnEYW9wwvzxUXhgaawJTw%40mail.gmail.com.
