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/CAOMQ%2Bw_W7W%2BXYGc2mKoNgYu8GsKEsn0n67GWKuWiw6d9wYKzPw%40mail.gmail.com.
