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.
