LGTM2, with less caution than Yoav. :) This seems safe to me, and philosophically correct for the platform. Good luck shipping it!
-mike On Wed, Dec 1, 2021 at 11:41 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > 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? > > On Tuesday, November 30, 2021 at 2:17:27 PM UTC+1 Andrew Williams wrote: > >> 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/CAKXHy%3Dfkne6UrwsxRAouHv_w0q9bj8886rbk6KK017cV23EFAg%40mail.gmail.com.
