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%2BkVLhR_G9m6Yc1dNEEkuf2u%2B0hB2vdroDb0Xzrrz0cWEAQ%40mail.gmail.com.
