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/CAEa0%2BkV3zEi%3DFomwa7j8U2uSGC-x4eAx_ZDUCiXQcXy6bGqMrA%40mail.gmail.com.
