Still LGTM from me too. On Wed, Aug 23, 2023 at 8:58 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
> Still LGTM > > On Wed, Aug 23, 2023 at 5:47 PM Chris Thompson <cth...@chromium.org> > wrote: > >> We have iterated on the Fetch spec PR >> <https://github.com/whatwg/fetch/pull/1655> and believe it is ready to >> land modulo some editorial tweaks. >> > > Please be sure to follow up on the PR once the reviewers get back to it. > > >> >> From our 1% Stable experiment, we saw a substantial decrease in insecure >> plaintext HTTP navigation requests, and no regressions in Core Web Vitals >> metrics. >> >> We would like to proceed with this Intent-to-Ship, doing a gradual >> rollout to 100% in order to continue monitoring potential breakage. >> >> We did see a possible regression in renderer crash proportion, but we >> have not been able to identify a plausible cause or crash signature. Due to >> this possible stability risk we will be coordinating our gradual rollout >> with release owners. I can update this thread each time we increase our >> rollout percentage. >> >> - Chris >> >> >> >> >> On Wed, Jul 19, 2023 at 9:01 PM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> LGTM3 with similar conditions. If the PR takes an unreasonable amount of >>> time to land, please let us know. >>> >>> On Wed, Jul 19, 2023 at 9:02 PM Chris Harrelson <chris...@chromium.org> >>> wrote: >>> >>>> LGTM2 with the same conditions as Daniel. Thanks also for following up >>>> with a summary before proceeding with rollout! >>>> >>>> On Wed, Jul 19, 2023 at 11:56 AM Chris Thompson <cth...@chromium.org> >>>> wrote: >>>> >>>>> Thanks Daniel. As a quick update, this was just enabled at 1% Stable >>>>> in M115 (released yesterday). We have not seen any blockers come up from >>>>> Beta, but since issues may arise mainly in the long tail of sites we might >>>>> not see anything until Stable anyway. We'll keep an eye on our >>>>> experimental >>>>> rollout and follow up here with a summary. >>>>> >>>>> On Wed, Jul 19, 2023 at 11:52 AM Daniel Bratell <bratel...@gmail.com> >>>>> wrote: >>>>> >>>>>> I've been waiting a bit to see if the experiment would blow anything >>>>>> up, but if it doesn't, and continue to not do so, then >>>>>> >>>>>> LGTM1 as soon as the PR has landed. >>>>>> >>>>>> /Daniel >>>>>> On 2023-06-14 17:40, Yoav Weiss wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Thursday, June 8, 2023 at 5:53:49 PM UTC+2 Chris Thompson wrote: >>>>>> >>>>>> On Wed, Jun 7, 2023 at 9:41 PM Yoav Weiss <yoavwe...@chromium.org> >>>>>> wrote: >>>>>> >>>>>> Thanks for working on this! >>>>>> >>>>>> On Wed, Jun 7, 2023 at 11:44 PM Chris Thompson <cth...@chromium.org> >>>>>> wrote: >>>>>> >>>>>> Thanks all. Some updates: >>>>>> >>>>>> - We have filed a TAG review request >>>>>> <https://github.com/w3ctag/design-reviews/issues/853> >>>>>> - We are working on writing WPTs and we will update this thread >>>>>> when those are ready -- thanks for the added details about how those >>>>>> are run >>>>>> - We have added a `Non-Authoritative-Reason: HttpsUpgrades` >>>>>> header to the synthetic redirects (CL >>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/4584420>, >>>>>> which we are planning to merge back to M-115) >>>>>> - We are continuing to iterate on the spec PR >>>>>> >>>>>> For now we will continue to provide updates on this I2S -- closer to >>>>>> M115 going to Stable we may send an I2E to request the ability to proceed >>>>>> with a 1% Stable experiment if we have not yet been able to resolve >>>>>> everything here. >>>>>> >>>>>> @Harald Alvestrand <h...@google.com> : In general, this feature >>>>>> should work fine with captive portals. A captive portal that intercepts >>>>>> HTTPS connections will result in a certificate error, which will cause >>>>>> the >>>>>> upgrade to fail and automatically fall back to HTTP. Alternatively, the >>>>>> captive portal could reset the connection for HTTPS requests, which would >>>>>> accomplish the same. >>>>>> >>>>>> We have had one report of a middlebox that returned an HTTP 404 error >>>>>> over HTTPS instead of rejecting the connection, causing breakage (the >>>>>> upgraded HTTPS page would load but have useless content). We do not >>>>>> believe >>>>>> the browser should fallback on *application* level errors, as they >>>>>> do not provide a useful signal that the site does not support HTTPS -- in >>>>>> the vast majority of cases the same application error will occur over >>>>>> HTTP >>>>>> as well. (This specific case was an enterprise situation, with an >>>>>> enterprise installed root certificate making the middlebox's HTTPS work, >>>>>> and we have enterprise policies to allow organizations to disable >>>>>> upgrades >>>>>> for affected hosts.) >>>>>> >>>>>> >>>>>> What's our plan to tackle such issues? Do we have an enterprise >>>>>> policy in place? >>>>>> >>>>>> >>>>>> >>>>>> We have two enterprise policies for this feature: >>>>>> >>>>>> - HttpsUpgradesEnabled >>>>>> <https://chromeenterprise.google/policies/#HttpsUpgradesEnabled> can >>>>>> be used to disable this feature on managed clients (we have a similar >>>>>> policy <https://chromeenterprise.google/policies/#HttpsOnlyMode> >>>>>> for Chrome's HTTPS-First Mode, i.e. the opt-in "Always use secure >>>>>> connections" setting) >>>>>> - HttpAllowlist >>>>>> <https://chromeenterprise.google/policies/#HttpAllowlist> can be >>>>>> used to allowlist hostnames or hostname patterns -- these will then >>>>>> not be >>>>>> upgraded on managed clients (this also applies to HTTPS-First Mode) >>>>>> >>>>>> There are two "escape hatches" for users who encounter breakage and >>>>>> need to fall back to HTTP, although from prior measurement we expect this >>>>>> to be rare: >>>>>> >>>>>> - If the user explicitly types an "http://"; URL into the Omnibox >>>>>> (with the scheme), we skip upgrading that navigation and add the host >>>>>> to >>>>>> the allowlist. >>>>>> - If the user sets the "Insecure Content" content setting ( >>>>>> chrome://settings/content/insecureContent) to "Allowed" for the >>>>>> site, then we skip upgrading navigations. (This setting also disables >>>>>> mixed >>>>>> content autoupgrading >>>>>> >>>>>> <https://w3c.github.io/webappsec-mixed-content/level2.html#upgrade-algorithm> >>>>>> -- >>>>>> for HTTPS Upgrades and HTTPS-First Mode we rely on Mixed Content >>>>>> Level 2 to >>>>>> ensure no plaintext subresource requests are sent.) >>>>>> >>>>>> >>>>>> That makes sense! >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jun 7, 2023 at 1:02 AM Harald Alvestrand <h...@google.com> >>>>>> wrote: >>>>>> >>>>>> How will this affect login to captive portals (WiFi login), which >>>>>> frequently rely on rewriting HTTP requests? >>>>>> >>>>>> >>>>>> On Tue, Jun 6, 2023 at 12:00 AM 'Panos Astithas' via blink-dev < >>>>>> blink-dev@chromium.org> wrote: >>>>>> >>>>>> On Wed, May 31, 2023 at 7:31 AM Mike West <mk...@google.com> wrote: >>>>>> >>>>>> >>>>>> -mike >>>>>> >>>>>> >>>>>> On Wed, May 31, 2023 at 4:17 PM Rick Byers <rby...@chromium.org> >>>>>> wrote: >>>>>> >>>>>> As a long-time user of HTTPS-first mode, I'm excited to see this ship >>>>>> ASAP! >>>>>> >>>>>> On Wed, May 31, 2023, 5:29 a.m. 'Mike West' via blink-dev < >>>>>> blink-dev@chromium.org> wrote: >>>>>> >>>>>> On Fri, May 26, 2023 at 1:32 AM Chris Thompson <cth...@chromium.org> >>>>>> wrote: >>>>>> >>>>>> On Thu, May 25, 2023 at 3:36 AM Mike West <mk...@chromium.org> wrote: >>>>>> >>>>>> I am enthusiastic about this (and not just because it should allow us >>>>>> to deprecate/remove `Upgrade-Insecure-Requests`). A few comments inline: >>>>>> >>>>>> On Thu, May 25, 2023 at 1:13 AM Chris Thompson <cth...@chromium.org> >>>>>> wrote: >>>>>> >>>>>> Contact emailscth...@chromium.org, dadr...@google.com >>>>>> >>>>>> Explainerhttps://github.com/dadrian/https-upgrade/blob/main/ >>>>>> explainer.md >>>>>> >>>>>> Specificationhttps://github.com/whatwg/fetch/pull/1655 >>>>>> >>>>>> >>>>>> Thanks for putting this together! I'll leave some comments on the PR. >>>>>> Given that we haven't gotten any feedback from Fetch editors, it might be >>>>>> prudent to let them take a pass before locking in our current behavior. >>>>>> >>>>>> >>>>>> Yes, hopefully we can get some feedback, but I'm optimistic that we >>>>>> won't be locking in behavior if we ship this as it should hopefully be >>>>>> not >>>>>> site or user visible, so if we need to change the behavior to align >>>>>> cross-browser we can iterate. >>>>>> >>>>>> >>>>>> I left a few comments last week. I think the PR needs some work >>>>>> before we can reasonably expect it to land in Fetch. >>>>>> >>>>>> >>>>>> I agree (and left a few comments of my own). Would it be possible to >>>>>> make some progress on this? Once the comments are addressed and we feel >>>>>> good about the PR's state, could we use the Mozilla position as support >>>>>> and >>>>>> publish the PR for review? (It's currently marked as a draft, which may >>>>>> explain why it wasn't reviewed by Fetch editors) >>>>>> >>>>>> >>>>>> Friendly ping on making progress on the PR! :) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Do we have tests in place for this behavior in Web Platform Tests? >>>>>> https://wpt.fyi/results/mixed-content/tentative/autoupgrades?label= >>>>>> experimental&label=master&aligned holds some tests for subresources, >>>>>> but I didn't see any around navigation or fallback behavior (which seems >>>>>> like it might need some WPT infrastructure change to produce a domain >>>>>> that's only served over HTTP). >>>>>> >>>>>> >>>>>> We do not have Web Platform Tests but we can look into adding them. >>>>>> Currently this is implemented in //chrome which I think might make this >>>>>> more difficult (my understanding is that the WPT suite is run against >>>>>> content_shell rather than chrome). We are currently relying on browser >>>>>> tests for our integration testing. >>>>>> >>>>>> >>>>>> WPT is a pretty important part of shipping features that affect the >>>>>> platform. It would be ideal if we could share these tests with our >>>>>> friends >>>>>> at other vendors (and update existing tests that might be expecting >>>>>> different behavior). Shifting the implementation to //content to make >>>>>> that >>>>>> possible would also have the advantage of helping other Chromium >>>>>> embedders >>>>>> ship this feature, which would be excellent for consistency in the >>>>>> project. >>>>>> >>>>>> >>>>>> Note that the official WPT results on wpt.fyi are using full Chrome >>>>>> builds. IIRC there are other features that require Chrome. I personally >>>>>> only consider having WPTs passing on upstream infra to be blocking I2S. >>>>>> @Panos >>>>>> Astithas <pastit...@google.com> can say more authoritatively. >>>>>> >>>>>> >>>>>> Indeed, upstream WPT results use full Chrome (and Firefox, Safari, >>>>>> etc.) through wptrunner. Soon, this will also be the case when running >>>>>> WPT >>>>>> in Chromium CI on Linux, once some blockers have been resolved. >>>>>> >>>>>> Panos >>>>>> >>>>>> +1 to the benefits of having this in content, but I personally think >>>>>> that's outside the scope of API owners so not something that should block >>>>>> an I2S. >>>>>> >>>>>> >>>>>> I agree with this. I didn't mean to imply that //content >>>>>> implementation was necessary, but that _having_ web platform tests is >>>>>> important for interop. Browser tests are less useful in that regard. :) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Summary >>>>>> >>>>>> Automatically and optimistically upgrade all main-frame navigations >>>>>> to HTTPS, with fast fallback to HTTP. >>>>>> >>>>>> >>>>>> Blink componentInternals>Network>SSL >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL> >>>>>> >>>>>> TAG reviewFetch change process does not mention a TAG review, >>>>>> therefore this is N/A (https://github.com/whatwg/fetch#pull-requests) >>>>>> >>>>>> >>>>>> Blink's process does mention a TAG review. I think it would be a good >>>>>> idea to put this in front of them. I also think they will appreciate it, >>>>>> since it's directly in line with their previous guidance (e.g. >>>>>> https://www.w3.org/2001/tag/doc/web-https). >>>>>> >>>>>> >>>>>> >>>>>> Sure, we can file a TAG review. I'll update this thread once that's >>>>>> done. >>>>>> >>>>>> >>>>>> TAG review statusNot applicable >>>>>> >>>>>> Risks >>>>>> >>>>>> >>>>>> Interoperability and Compatibility >>>>>> >>>>>> *Gecko*: Positive (https://github.com/mozilla/ >>>>>> standards-positions/issues/800) Firefox is offering a similar >>>>>> feature already in their private browsing mode by default >>>>>> >>>>>> *WebKit*: No signal (https://github.com/WebKit/ >>>>>> standards-positions/issues/185) >>>>>> >>>>>> *Web developers*: No signals. This feature is not exposed directly >>>>>> to web developers or users. However, HTTPS adoption is now standard >>>>>> practice (>90% of page loads in Chrome use HTTPS), and automatically >>>>>> upgrading navigations to HTTPS would avoid unnecessary redirects from >>>>>> HTTP >>>>>> to HTTPS for site owners. The `upgrade-insecure-requests` header has some >>>>>> similar functionality, and according to HTTP-Archive is found on ~6% of >>>>>> all >>>>>> requests. >>>>>> >>>>>> *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? >>>>>> >>>>>> >>>>>> Debuggability >>>>>> >>>>>> Chrome will upgrade these navigations to HTTPS using a 307 internal >>>>>> redirect, which will be visible in the Network panel of Developer Tools. >>>>>> >>>>>> >>>>>> For HSTS, we synthesize a `Non-Authoritative-Reason` header on the >>>>>> synthetic redirect that tells developers why the redirect happened. Is >>>>>> that >>>>>> a pattern y'all will follow here as well? If so, it's probably a good >>>>>> idea >>>>>> to document it somewhere; I don't think we've explained that header >>>>>> well. :) >>>>>> >>>>>> >>>>>> Good idea. I'll get a CL up to add this to our implementation, and it >>>>>> seems reasonable to merge back to M115. We can include a mention of it in >>>>>> any public facing documentation we write about this. I'm also looking >>>>>> into >>>>>> whether we can add NetLog events for the upgrade and fallback steps which >>>>>> could help with triaging bug reports. >>>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>> Mac, Linux, Chrome OS, Android, and Android WebView)?No >>>>>> >>>>>> Currently not available on Android WebView. We are implementing this >>>>>> first for Chrome and will consider bringing this to WebView (likely as an >>>>>> embedder opt-in) as follow up work. >>>>>> >>>>>> >>>>>> Is this feature fully tested by web-platform-tests >>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>> ?No >>>>>> >>>>>> Flag namehttps-upgrades >>>>>> >>>>>> Requires code in //chrome?True >>>>>> >>>>>> >>>>>> Can you spell out what's required here? Just enterprise policy work, >>>>>> or are there other things embedders would need to implement to make this >>>>>> functionality work? >>>>>> >>>>>> >>>>>> This feature is currently implemented in //chrome with some support >>>>>> code in content/'s NavigationRequest. I think it would be feasible to >>>>>> migrate the core of this into content/ -- we use an >>>>>> URLRequestLoaderInterceptor and a NavigationThrottle to implement the >>>>>> upgrading and fallback logic. This is currently shared with Chrome's >>>>>> HTTPS-First Mode (controlled by Chrome's "Always use secure connections" >>>>>> setting). If we did migrate this logic to content/, embedders would need >>>>>> to >>>>>> add their own support for at least (1) how to handle allowlisting >>>>>> hostnames, and (2) enterprise policies for enabling/disabling the feature >>>>>> and exempting hostnames. We do not have a design ready for making this >>>>>> change though. >>>>>> >>>>>> >>>>>> As mentioned above, it would be ideal for the pieces of this change >>>>>> that affect the platform to be available in //content so they flow into >>>>>> content_shell and other embedders. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id= >>>>>> 1394910 >>>>>> >>>>>> Launch bughttps://launch.corp.google.com/launch/4235192 >>>>>> >>>>>> Sample links >>>>>> http://example.com will upgrade to https://example.com. >>>>>> http://www.alwayshttp.com will upgrade to https://www.alwayshttp.com but >>>>>> fall back to http://www.alwayshttp.com because the site doesn't >>>>>> support HTTPS. >>>>>> >>>>>> Estimated milestonesShipping on desktop115Shipping on Android115 >>>>>> >>>>>> We are planning to do a field trial to gradually roll out this >>>>>> feature to Chrome clients in Chrome 115. >>>>>> >>>>>> >>>>>> Over what time period do you expect to ramp up to 100%? If you expect >>>>>> it to push beyond the M115 timeframe, it might be reasonable to frame >>>>>> this >>>>>> as an intent to experiment to give folks a little more time to weigh in >>>>>> on >>>>>> the Fetch PR. >>>>>> >>>>>> >>>>>> We are hoping to ramp up to 100% within M115, but it may end up >>>>>> completing in M116. >>>>>> >>>>>> (We could do an I2E, but it did not seem like a good fit as there is >>>>>> no Origin Trial component, this does not require developer involvement, >>>>>> etc. Our understanding was even doing a non-OT 1% Stable rollout required >>>>>> sending an I2S and getting LGTMs from API OWNERS. Let us know if you >>>>>> think >>>>>> we should reassess our launch plan.) >>>>>> >>>>>> >>>>>> We do have an experimentation path for running a Finch experiment on >>>>>> stable/beta users (confusingly(?) under "Origin Trial" >>>>>> <https://www.chromium.org/blink/launching-features/#:~:text=Depending%20on%20your,required%20before%20proceeding.> >>>>>> in our documentation; we could probably improve that). >>>>>> >>>>>> I think I'd recommend that path to avoid any delays that might come >>>>>> up in getting Fetch updated to support this feature. I'd LGTM an I2E @ >>>>>> 50% >>>>>> beta/1% stable to gain confidence in the fallback mechanism at scale. For >>>>>> I2S, I'm a little worried about the state of the spec and its eventual >>>>>> interoperability across vendors. I'd like to get that hammered down >>>>>> before >>>>>> making it harder to change details that developers might come to rely >>>>>> upon. >>>>>> >>>>>> -mike >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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). >>>>>> https://github.com/whatwg/fetch/pull/1655 >>>>>> >>>>>> Link to entry on the Chrome Platform Statushttps://chromestatus.com/ >>>>>> feature/6056181032812544 >>>>>> >>>>>> Links to previous Intent discussionsIntent to prototype: >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/mgJqym5-Xek/m/ >>>>>> 0EAN6v7CCQAJ >>>>>> >>>>>> 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+unsubscr...@chromium.org. >>>>>> To view this discussion on the web visit https://groups.google.com/a/ >>>>>> chromium.org/d/msgid/blink-dev/CAKXHy%3DdPs5Spya9QBVmFYdeTJevs6jML% >>>>>> 3DNmU7SEApOshNRmHCg%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdPs5Spya9QBVmFYdeTJevs6jML%3DNmU7SEApOshNRmHCg%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/CAJ8Nf20mYRwXxCjadR5MuQ5DPj7nH >>>>>> a6MGEkFe5576W1tZ8MkPQ%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ8Nf20mYRwXxCjadR5MuQ5DPj7nHa6MGEkFe5576W1tZ8MkPQ%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/CALMy46Q--Fj9qV%3D28_ >>>>>> CY9au4h-Gc%3D3dYWPFNeT1g-wdmQxEvSQ%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46Q--Fj9qV%3D28_CY9au4h-Gc%3D3dYWPFNeT1g-wdmQxEvSQ%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/4bb5bcde-794b-44ea-9a04-2c3837eac96dn%40chromium.org >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4bb5bcde-794b-44ea-9a04-2c3837eac96dn%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/CALMy46S28jD1qa6imSeDvR8L33WkNeS3xh2gTkSu91Rr97ZCVQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46S28jD1qa6imSeDvR8L33WkNeS3xh2gTkSu91Rr97ZCVQ%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/CAL5BFfX3oKUmq4F%3DzHZ06_nc-KiVqLN8umYrsgqgCckmP1u1gQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX3oKUmq4F%3DzHZ06_nc-KiVqLN8umYrsgqgCckmP1u1gQ%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/CAOMQ%2Bw9gmhqStDux2u6etJR2Z%2BSS_n%3Dj0S1t_fatROiTe8hB8g%40mail.gmail.com.
