On Thu, Dec 2, 2021 at 8:14 PM Andrew Williams <awil...@chromium.org> wrote:
> Thanks for the link, Daniel, and thank you to Mike as well for sending me > a Chrome Enterprise PoC to reach out to. > > Yoav, do you think waiting two or three months between when we implement > DevTools Issues / deprecation reports for this and when we do the removal > would be sufficient? > That sounds reasonable to me. The known risk seems low, I'm mostly concerned about the unknown risk. I'm hoping that a couple of months of deprecation reports + enterprise policy can help us reduce risks on that front. > Is there a precedent for the minimum amount of time to provide notice for > changes like this that don't seem like they will have widespread impact but > that we want to proceed with caution on nonetheless? > > -Andrew > > On Wed, Dec 1, 2021 at 4:02 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> >> >> On Wed, Dec 1, 2021 at 7:02 PM Andrew Williams <awil...@chromium.org> >> wrote: >> >>> Thanks for the LGTMs Yoav, Mike, and Daniel! >>> >>> Yoav, we haven't implemented warnings of any kind (DevTools Issues or >>> deprecation reports via the Reporting API) for this yet... >>> >> >> That part seems paramount before starting with the actual removal. What >> timelines do you have in mind? >> >> >>> This effort has been on the backburner but I aim to revisit it soon. >>> Also, I'm happy to reach out to Chrome Enterprise about this - do you have >>> a recommendation regarding a good PoC? Also, our plan is still to implement >>> this behind a feature flag that could be disabled via Finch in the event >>> that significant breakage is encountered (although I know Finch updates are >>> not a panacea). >>> >>> -Andrew >>> >>> On Wed, Dec 1, 2021 at 7:26 AM Daniel Bratell <bratel...@gmail.com> >>> wrote: >>> >>>> LGTM3 >>>> >>>> /Daniel >>>> On 2021-12-01 12:31, Mike West wrote: >>>> >>>> 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/CAL5BFfVv5OYCrKNF2N3mr-gFmdjtpv7LOVdV-wWoUw9fMXy4%2BQ%40mail.gmail.com.
