Hi Ivan, Yeah, we've had a couple reports come in from the bugtracker. Most seem to have been caused by an extremely outdated OpenSSL (several even still vulnerable to Heartbleed!) and were resolved by the servers updating their OpenSSL. I've put together a troubleshooting doc here with the server bugs we're aware of: https://chromium.googlesource.com/chromium/src/+/main/docs/security/tls-sha1-server-signatures.md
I'll see about replying to the ones from outside our bugtracker. Thanks for pointing them out! On Mon, Oct 9, 2023 at 8:56 AM Ivan Radisson <ivan.radis...@gmail.com> wrote: > Some reports can be found here as well: > > > https://bugs.chromium.org/p/chromium/issues/list?q=ERR_SSL_PROTOCOL_ERROR&can=2 > > On Wednesday, September 27, 2023 at 6:04:54 PM UTC+1 David Benjamin wrote: > >> Yup, it's finch-gated. (Finch feature name in the original email.) >> >> >> On Wed, Sep 27, 2023, 11:11 Daniel Bratell <brat...@gmail.com> wrote: >> >>> LGTM2 (for the original request, just to be clear) >>> >>> I assume it will have the normal flag that will allow it to be turned >>> off if our interpretation is incorrect, since it is so hard to measure with >>> a high accuracy. >>> >>> /Daniel >>> On 2023-09-26 18:33, David Benjamin wrote: >>> >>> To clarify, I meant that we should apply this to WebRTC *in a >>> separate launch*. This one will just be HTTPS. We don't have numbers or >>> a flag for WebRTC right now, and we usually end up doing WebRTC separately >>> anyway, for better or worse. :-) >>> >>> On Tue, Sep 26, 2023 at 12:31 PM David Benjamin <davi...@chromium.org> >>> wrote: >>> >>>> Ah yeah, we should apply this to WebRTC too. Based on the kinds of >>>> issues we've seen, hopefully that one will be easy (I wouldn't expect >>>> WebRTC to be impacted by the kinds of server bugs we've seen), but >>>> certainly we'll need numbers. >>>> >>>> Measurement is a little complicated for HTTPS (we had to do this >>>> fallback dance to avoid a ton of false positives on old Schannel behavior, >>>> which is why we had to pick up transient network errors as a different >>>> source of false positives). But since WebRTC talks to different kinds of >>>> peers, I suspect you all can just histogram the server-selected algorithm >>>> with SSL_get_peer_signature_algorithm, and just assume that's an accurate >>>> enough predictor. (TLS is client-offer / server-select, so we never learn >>>> the server's full capabilities, only what it happened to pick in response >>>> to our ClientHello. This makes measurements inherently more complex >>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/RShdgyaDoX4/m/ly5-WQEBBgAJ> >>>> than measuring JavaScript API usage, but in simple cases just measuring >>>> the server selection gives good enough numbers.) >>>> >>>> On Tue, Sep 26, 2023 at 5:26 AM Philipp Hancke < >>>> philipp...@googlemail.com> wrote: >>>> >>>>> Should/can this also be applied to WebRTC's DTLS connections? >>>>> >>>>> (we don't have numbers but that can be fixed) >>>>> >>>>> Am Mo., 25. Sept. 2023 um 19:13 Uhr schrieb Yoav Weiss < >>>>> yoav...@chromium.org>: >>>>> >>>>>> LGTM1 to remove support, given that 0.009% of TLS connections divided >>>>>> by ~30 is roughly at our typical threshold. Also given the dominance of >>>>>> subresource TLS connections, it's likely that breakage would hit one of >>>>>> those subresources, making it less likely to cause functional damage >>>>>> (compared to e.g. the navigation request TLS connection). >>>>>> >>>>>> On Mon, Sep 25, 2023 at 6:03 PM David Adrian <dad...@google.com> >>>>>> wrote: >>>>>> >>>>>>> There are approximately 30x TLS connections relative to pageloads, >>>>>>> due to subresources. Once you have a TLS connection open for a main >>>>>>> frame, >>>>>>> I'm not sure how many page loads happen across it. Probably a lot, but >>>>>>> it's >>>>>>> still dominated by subresources. >>>>>>> >>>>>>> In practice, the 0.02% bound appears to have shaken out to sub 0.01% >>>>>>> (0.009%), determined by looking at differences in the "OK" result for >>>>>>> Net.SSL_Connection_Error. >>>>>>> >>>>>>> On Tue, Sep 19, 2023 at 8:59 PM Yoav Weiss <yoav...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Sep 20, 2023 at 12:47 AM David Benjamin < >>>>>>>> davi...@chromium.org> wrote: >>>>>>>> >>>>>>>>> On Tue, Sep 19, 2023 at 1:50 AM Yoav Weiss <yoav...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Tue, Sep 19, 2023 at 7:45 AM Yoav Weiss <yoav...@chromium.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On Tue, Sep 19, 2023 at 1:35 AM 'Jeffrey Yasskin' via blink-dev < >>>>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Mon, Sep 18, 2023 at 4:11 PM David Adrian <dad...@google.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> > This should probably be an "Intent to Deprecate and Remove" >>>>>>>>>>>>> rather than an "Intent to Ship". >>>>>>>>>>>>> >>>>>>>>>>>>> You're absolutely right that it should be, unfortunately >>>>>>>>>>>>> that's not the subject Chrome Status generated. I'll file an >>>>>>>>>>>>> issue. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Oops, yes, you did everything right here. There's already >>>>>>>>>>>> https://github.com/GoogleChrome/chromium-dashboard/issues/2749 >>>>>>>>>>>> about changing this subject line, and now >>>>>>>>>>>> https://github.com/GoogleChrome/chromium-dashboard/issues/3346 >>>>>>>>>>>> to align the Chrome Status UI with the launching-features page. >>>>>>>>>>>> >>>>>>>>>>>> > The RFC's introduction at >>>>>>>>>>>>> https://www.rfc-editor.org/rfc/rfc9155.html#name-introduction >>>>>>>>>>>>> is a pretty good explainer for why we should remove SHA-1 >>>>>>>>>>>>> signatures. >>>>>>>>>>>>> >>>>>>>>>>>>> Agreed. Noting in general, there is a large process mismatch >>>>>>>>>>>>> between TLS launches and the Blink launch process, as discussed in >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/CmlXjQeNWDI/m/r-AUe0OqAQAJ. >>>>>>>>>>>>> That's why this Intent looks a little different. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> I wouldn't categorize it as a large process mismatch. But that's >>>>>>>>>>> an orthogonal discussion. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> As for the launch itself, I'll note it's been at 10% on Finch >>>>>>>>>>>>> for a couple weeks and everything looks gray, so we should be >>>>>>>>>>>>> safe to ramp >>>>>>>>>>>>> up to 100%. The only thing of note was a correlation with an >>>>>>>>>>>>> unrelated >>>>>>>>>>>>> crash in Blink >>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1479083#c2>, >>>>>>>>>>>>> since the deprecation rollout was fairly large. It only showed at >>>>>>>>>>>>> 10%, not >>>>>>>>>>>>> 1%. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> How would we know of breakage in those 10%? Would that look like >>>>>>>>>> users filing issues? Something else? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> On Mon, Sep 18, 2023 at 3:53 PM Jeffrey Yasskin < >>>>>>>>>>>>> jyas...@google.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> This should probably be an "Intent to Deprecate and Remove" >>>>>>>>>>>>>> <https://www.chromium.org/blink/launching-features/#feature-deprecations> >>>>>>>>>>>>>> rather than an "Intent to Ship". I'll let an API owner say if >>>>>>>>>>>>>> there's a >>>>>>>>>>>>>> reason to re-send it; probably there isn't. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Sep 18, 2023 at 3:47 PM 'David Adrian' via blink-dev < >>>>>>>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Contact emails dad...@google.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Explainer None >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The RFC's introduction at >>>>>>>>>>>>>> https://www.rfc-editor.org/rfc/rfc9155.html#name-introduction >>>>>>>>>>>>>> is a pretty good explainer for why we should remove SHA-1 >>>>>>>>>>>>>> signatures. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Specification https://www.rfc-editor.org/rfc/rfc9155.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Summary >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Chrome is removing support for signature algorithms using >>>>>>>>>>>>>>> SHA-1 for server signatures during the TLS handshake. This does >>>>>>>>>>>>>>> not affect >>>>>>>>>>>>>>> SHA-1 support in server certificates, which was already >>>>>>>>>>>>>>> removed, or in >>>>>>>>>>>>>>> client certificates, which continues to be supported. SHA-1 can >>>>>>>>>>>>>>> be >>>>>>>>>>>>>>> temporarily re-enabled via the temporary >>>>>>>>>>>>>>> InsecureHashesInTLSHandshakesEnabled enterprise policy. This >>>>>>>>>>>>>>> policy will be >>>>>>>>>>>>>>> removed in Chrome 123. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Blink component Internals>Network>SSL >>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Search tags tls <https://chromestatus.com/features#tags:tls> >>>>>>>>>>>>>>> , ssl <https://chromestatus.com/features#tags:ssl>, sha1 >>>>>>>>>>>>>>> <https://chromestatus.com/features#tags:sha1> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> TAG review None >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> TAG review status Not applicable >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Risks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> At most 0.02% of page loads use the SHA1 fallback. However, >>>>>>>>>>>>>>> we cannot disambiguate between a flaky first connection, and >>>>>>>>>>>>>>> actually >>>>>>>>>>>>>>> requiring SHA1. We expect the actual amount is lower. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> Are we thinking that 0.02% is a loose upper bound? Is that >>>>>>>>>>> correct? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> As with anything in TLS, the protocol is client-offer / >>>>>>>>> server-select, which means we pick up all the implications of that. >>>>>>>>> We can >>>>>>>>> measure what the server selects, but that doesn't actually tell us >>>>>>>>> what >>>>>>>>> will happen if we change the ClientHello: >>>>>>>>> - Perhaps the server preferentially chooses SHA-1, but will pick >>>>>>>>> SHA-2 if not offered. (I.e. SHA-1-preferring instead of >>>>>>>>> SHA-1-requiring) >>>>>>>>> - Perhaps the server picks SHA-2 regardless but, for some odd >>>>>>>>> reason, breaks when SHA-1 is not offered. This could be a buggy, >>>>>>>>> non-compliant fingerprinting script, or some weird behavior. >>>>>>>>> >>>>>>>>> Usually, these effects are small enough that we just measure the >>>>>>>>> server selection and don't worry about it. Here, we could not do that. >>>>>>>>> First, we knew from previously sampling sites that some servers >>>>>>>>> (older IIS) >>>>>>>>> fall in the first category. These servers would not break, but would >>>>>>>>> seem >>>>>>>>> to break if we measure the server selection. We also knew, again from >>>>>>>>> sampling and due to the multiple places where this ClientHello field >>>>>>>>> is >>>>>>>>> used, the second category also shows up (in many cases, also older >>>>>>>>> IIS). >>>>>>>>> These servers would break but would seem not to if we measure the >>>>>>>>> server >>>>>>>>> selection. >>>>>>>>> >>>>>>>>> Thus, we used a different measurement strategy. We send a >>>>>>>>> SHA-1-less ClientHello and then, on error, retry with SHA-1 restored. >>>>>>>>> This >>>>>>>>> does not work for security (an attacker can always force us onto the >>>>>>>>> second >>>>>>>>> round), but it helps counteract the above effects for a more accurate >>>>>>>>> measurement... up to a point. Up to a point because, in exchange for >>>>>>>>> clearing those effects, we pick a different effect: transient network >>>>>>>>> errors will also trigger the retry. And thus our numbers inherently >>>>>>>>> have >>>>>>>>> noise at the scale of transient network errors. >>>>>>>>> >>>>>>>>> See also >>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/RShdgyaDoX4/m/ly5-WQEBBgAJ, >>>>>>>>> where we previously discussed this same client-offer / server-select >>>>>>>>> property. >>>>>>>>> >>>>>>>>> This is a difference from web platform things, where we can simply >>>>>>>>> observe in Chrome what APIs the site uses and moves on. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Any way to sample a few sites to validate that assumption? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> I'm not sure what you mean. Networks occasionally flake, so any >>>>>>>>> kind of fallback measurements will capture some flakiness. Sampling >>>>>>>>> sites >>>>>>>>> won't tell us anything about that. >>>>>>>>> >>>>>>>> >>>>>>>> For web platform features, where we have both usecounters in the >>>>>>>> HTTPArchive and potentially UKM, we can gather potentially breaking >>>>>>>> URLs/origins, grab a few dozens random names from the list and deep >>>>>>>> dive >>>>>>>> into them to see if they show breakage or not. >>>>>>>> >>>>>>>> I'm not sure that we have anything similar for the netstack, where >>>>>>>> we could e.g. report the failures in ways that enable us to later >>>>>>>> follow up >>>>>>>> and run a similar manual check. (e.g. by reporting the failing DNS name >>>>>>>> and/or IP) >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Also, are those 0.02% driven by origins? Specific user platforms? >>>>>>>>>> Something else? >>>>>>>>>> >>>>>>>>> >>>>>>>>> This is 0.02% of TLS connections (sorry, page loads was a typo). >>>>>>>>> >>>>>>>> >>>>>>>> OK, that seems better, as presumably the denominator is smaller >>>>>>>> then it would be for page loads (which is what we typically use). Do >>>>>>>> you >>>>>>>> have a sense of the difference between denominators? (so, how many page >>>>>>>> loads typically happen per TLS connection?) >>>>>>>> >>>>>>>> >>>>>>>>> This is another of those differences between networking and web >>>>>>>>> platform features. The denominator is unavoidably different because of >>>>>>>>> where in the stack this logic applies. Where it is actually an >>>>>>>>> incompatibility with a site, it will be based on the origin. This is >>>>>>>>> almost >>>>>>>>> always due to a bug in the server software because every TLS 1.2 >>>>>>>>> implementations supports SHA-2. (E.g. very very old OpenSSLs, with >>>>>>>>> several >>>>>>>>> known, unrelated security vulnerabilities have a bug where, with some >>>>>>>>> server software, mess this up.) >>>>>>>>> >>>>>>>>> Where it is a transient network error above it is, well, a >>>>>>>>> transient network error and presumably driven by network conditions. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> *Gecko*: Positive ( >>>>>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/812) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *WebKit*: Positive ( >>>>>>>>>>>>>>> https://github.com/WebKit/standards-positions/issues/196) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Web developers*: No signals >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Other signals*: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> WebView application risks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Does this intent deprecate or change behavior of existing >>>>>>>>>>>>>>> APIs, such that it has potentially high risk for Android >>>>>>>>>>>>>>> WebView-based >>>>>>>>>>>>>>> applications? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> None >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Debuggability >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> n/a, this happens pre-devtools >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>>>>>>>> Yes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>>> ? No >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Flag name on chrome://flags use-sha1-server-handshakes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Finch feature name DisableSHA1ServerSignature >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Requires code in //chrome? False >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Tracking bug >>>>>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=658905 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Launch bug https://launch.corp.google.com/launch/4233200 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Estimated milestones >>>>>>>>>>>>>>> Shipping on desktop 117 >>>>>>>>>>>>>>> OriginTrial desktop last 116 >>>>>>>>>>>>>>> OriginTrial desktop first 115 >>>>>>>>>>>>>>> DevTrial on desktop 115 >>>>>>>>>>>>>>> Shipping on Android 117 >>>>>>>>>>>>>>> OriginTrial Android last 116 >>>>>>>>>>>>>>> OriginTrial Android first 115 >>>>>>>>>>>>>>> DevTrial on Android 115 >>>>>>>>>>>>>>> OriginTrial webView last 116 >>>>>>>>>>>>>>> OriginTrial webView first 115 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Anticipated spec changes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Open questions about a feature may be a source of future web >>>>>>>>>>>>>>> compat or interop issues. Please list open issues (e.g. links >>>>>>>>>>>>>>> to known >>>>>>>>>>>>>>> github issues in the project for the feature specification) >>>>>>>>>>>>>>> whose >>>>>>>>>>>>>>> resolution may introduce web compat/interop risk (e.g., >>>>>>>>>>>>>>> changing to naming >>>>>>>>>>>>>>> or structure of the API in a non-backward-compatible way). >>>>>>>>>>>>>>> None >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>>> https://chromestatus.com/feature/4832850040324096 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Links to previous Intent discussions Intent to Experiment: >>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42JZz%3De_TRVwumqgTj-A7543BR7JLBUR_GzVN_oOWhKVvg%40mail.gmail.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>>>>>>> <https://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+...@chromium.org. >>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42LiSGgfN1trVXfrmCW0Upk9r9GK4XYZQm5Y8RSzphn_DA%40mail.gmail.com >>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42LiSGgfN1trVXfrmCW0Upk9r9GK4XYZQm5Y8RSzphn_DA%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+...@chromium.org. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXnM7SzAOh2y6hcuezDpo-yCW%3DtNg0%3D1ErEMCFN%3DSSpsQQ%40mail.gmail.com >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXnM7SzAOh2y6hcuezDpo-yCW%3DtNg0%3D1ErEMCFN%3DSSpsQQ%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+...@chromium.org. >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVPG6np80msDXGDyzqOMA6E-7mtqFQpDSw8w5m3X%3DEKOg%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVPG6np80msDXGDyzqOMA6E-7mtqFQpDSw8w5m3X%3DEKOg%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+...@chromium.org. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXorTe7SSPt8iZt5ZjVi0Qh8qd%2BPdEGMOzSQj45e0Z1VQ%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXorTe7SSPt8iZt5ZjVi0Qh8qd%2BPdEGMOzSQj45e0Z1VQ%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+...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaB5P6Ys%3DxMyB%3D7HvLJEa0Axp5uCcfbPQqurN2ADdasYgQ%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaB5P6Ys%3DxMyB%3D7HvLJEa0Axp5uCcfbPQqurN2ADdasYgQ%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/CAF8qwaCUHfxbY8QEryyCS6_%2BWjqzTRAV%2B4TAEG8Ym%2B8W-8p%3DJg%40mail.gmail.com.
