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/CAL5BFfXEPR2PWchN93%3DhewcX4eiia%3D7Kouic6B295u55OYRndQ%40mail.gmail.com.
