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/CAL5BFfWo8VRaw_YHCj%2BUrqOAKSttkYM28KkSwJ4Pjv-QVRnXLA%40mail.gmail.com.
