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%2BkU0ibxik4Zy3JYUNKkAFAMicC7KY6U4TvFufZdPft7QsQ%40mail.gmail.com.
