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.
