Sorry, that should be "before instantiating content" (Or "before calling ContentMain")
On Sun, Aug 22, 2021 at 4:51 PM Matt Menke <mme...@google.com> wrote: > I've poked around here, and I'm not sure it's possible to wire this up to > a base::Feature. Headless runs some code before instantiating context, > including parsing a remote debugging IP address from the command line. > This results in calling the IPv4 parser before content, and thus the global > feature list, is loaded, which results in the feature code CHECKing. Even > if we figured out a way to work around this, I'm concerned that other code > not exercised by the trybots may be doing the same thing, which could > result in a lot of unexpected surprises. > > I guess we could add a command line switch to bypass the check, though > that's more difficult to use than a base::Feature, and can't be set > server-side. Open to other ideas. > > On Fri, Aug 20, 2021 at 10:16 AM Matt Menke <mme...@google.com> wrote: > >> On second thought, doesn't seem to be any benefit to a partial rollout on >> prerelease channels, so probably just land it with an enabled by default >> base::Feature. >> >> On Fri, Aug 20, 2021 at 7:57 AM Matt Menke <mme...@google.com> wrote: >> >>> I'm planning to ship it behind a feature (enabled by default, after >>> experimenting on pre-release channels) to allow emergency disabling. >>> >>> On Fri, Aug 20, 2021 at 12:53 AM Yoav Weiss <yoavwe...@chromium.org> >>> wrote: >>> >>>> OK, I'm convinced that these are not "real" hosts, and that breaking >>>> them will not result in actual user-visible breakage. Would it be possible >>>> to ship this with a server-side flag that'd enable us to quickly revert in >>>> case we're wrong? >>>> >>>> On Thu, Aug 19, 2021 at 6:09 PM Matt Menke <mme...@google.com> wrote: >>>> >>>>> So given information on this thread, I think the ways these can >>>>> succeed are possibly: >>>>> 1) Entries in the HOSTS file. >>>>> 2) Intermediary DNS servers or MitMs typo squatting, or actively >>>>> attacking the user. >>>>> 3) Local DNS servers providing additional DNS results. >>>>> 4) Suffix search (which would trigger on, e.g., "1533.67.89" but not >>>>> "67.89.1533") >>>>> 5) mDNS >>>>> 6) Local tools injecting DNS lookup results. >>>>> >>>>> Unfortunately, we don't have a good way to gather hard data on which >>>>> are more common. Given that there are potential security implications >>>>> here, I'm reluctant to wait for another round of data gathering, though we >>>>> could probably distinguish cases 4) and 5) from the others, and 1) as >>>>> well, >>>>> at least on some platforms. Also not sure how useful just knowing about >>>>> those cases would be. >>>>> On Thursday, August 19, 2021 at 11:54:29 AM UTC-4 Harald Alvestrand >>>>> wrote: >>>>> >>>>>> Thanks - I misremembered which end of the class B network got jammed >>>>>> together. 67.89.31533 is indeed the one that is "legal" syntax, and so of >>>>>> course 67.89.1 is too. >>>>>> >>>>>> >>>>>> On Thu, Aug 19, 2021 at 3:20 PM Matt Menke <mme...@google.com> wrote: >>>>>> >>>>>>> Note that 127.0.1 is mapped to 127.0.0.1 by GURL, following the URL >>>>>>> spec, so that would generally not make it to the DNS resolver (unless >>>>>>> something tried to resolve it directly). Per the URL spec, >>>>>>> "31533.67.89" >>>>>>> would not be normalized by GURL, but "67.89.31533" would be converted to >>>>>>> 67.89.123.45. My instrumentation was at the DNS layer, so "127.0.1" and >>>>>>> "67.89.31533" would not show up as problematic hostnames in my metrics, >>>>>>> though "31533.67.89" would. >>>>>>> >>>>>>> On Thu, Aug 19, 2021 at 9:10 AM Harald Alvestrand <h...@google.com> >>>>>>> wrote: >>>>>>> >>>>>>>> An interesting property of all-numeric hostnames is that they *may* >>>>>>>> be legitimate IPv4 addresses using highly archaic IP address formats - >>>>>>>> we're so used to the 123.45.67.89 syntax that we forget that >>>>>>>> 31533.67.89 >>>>>>>> once was regarded as a legitimate way to encode the same address >>>>>>>> (class B >>>>>>>> notation). >>>>>>>> >>>>>>>> There are also certain resolvers that will "helpfully" map an >>>>>>>> all-numeric hostname presented in DNS to an IP address without asking >>>>>>>> anyone. >>>>>>>> So if those two bugs (or "archaic features") occur together, the >>>>>>>> result may be a successful resolution. >>>>>>>> >>>>>>>> No idea why it would occur more often on Android than on Windows, >>>>>>>> though. And my Linux boxes don't resolve 127.0.1 to anything. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Aug 19, 2021 at 2:42 PM Yoav Weiss <yoav...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Interesting! What happens then in the "successful resolution" case >>>>>>>>> Matt mentioned? >>>>>>>>> >>>>>>>>> On Thu, Aug 19, 2021 at 2:39 PM Harald Alvestrand <h...@google.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Department of odd facts: >>>>>>>>>> >>>>>>>>>> - The ICANN rules for new TLDs forbid all top level domain names >>>>>>>>>> that start with a digit >>>>>>>>>> - The IDNA rules for bidirectional scripts forbid domain names >>>>>>>>>> that start with a digit (Unicode bidi afficandoes will know why) >>>>>>>>>> - The only real reason why leading digits aren't outlawed in >>>>>>>>>> domain names at the second level is 3com. >>>>>>>>>> >>>>>>>>>> It seems safe to say that no legitimate fully qualified hostname >>>>>>>>>> will ever have a last component consisting only of digits. >>>>>>>>>> That means the only time we could get a legitimate hostname is >>>>>>>>>> for something that has to be resolved via a search path. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Aug 19, 2021 at 2:33 PM Yoav Weiss <yoav...@chromium.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Aug 19, 2021 at 2:28 PM Matt Menke <mme...@google.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> I created the title using Chrome Status's deprecation >>>>>>>>>>>> template, so any confusion should be blamed on that. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> +Jason Robbins - on the title issues. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I used the "Draft Intent to Deprecate and Remove email" button, >>>>>>>>>>>> and assume I'd need to do a "Draft Intent to Ship email" before >>>>>>>>>>>> shipping to >>>>>>>>>>>> stable, after a 50% trial on prerelease channels. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> There's no need for 2 emails for removals. We can discuss the >>>>>>>>>>> full deprecation, experimentation/trials and removal on stable here. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Aug 19, 2021 at 3:15 AM Yoav Weiss < >>>>>>>>>>>> yoav...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Aug 18, 2021 at 11:36 PM Matt Menke <mme...@google.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Aug 18, 2021 at 5:23 PM Yoav Weiss < >>>>>>>>>>>>>> yoav...@chromium.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Aug 18, 2021 at 11:18 PM Matt Menke < >>>>>>>>>>>>>>> mme...@google.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Aug 18, 2021 at 4:53 PM Yoav Weiss < >>>>>>>>>>>>>>>> yoav...@chromium.org> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Aug 18, 2021 at 8:47 PM 'Matt Menke' via blink-dev >>>>>>>>>>>>>>>>> <blin...@chromium.org> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Contact emailsmme...@google.com >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ExplainerNone >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Specificationhttps://url.spec.whatwg.org/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Summary >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Most hostnames that aren't valid IPv4 addresses, but end >>>>>>>>>>>>>>>>>> in numbers are treated as valid, and looked up via DNS (e.g., >>>>>>>>>>>>>>>>>> http://foo.127.1/). Per the Public Suffix List spec, the >>>>>>>>>>>>>>>>>> eTLD+1 of the hostname in that URL should be "127.1". If >>>>>>>>>>>>>>>>>> that is ever fed >>>>>>>>>>>>>>>>>> back into a URLs, "http://127.1/ <http://127.0.0.1/>" is >>>>>>>>>>>>>>>>>> mapped to "http://127.0.0.1/"; by the URL spec, which >>>>>>>>>>>>>>>>>> seems potentially dangerous. "127.0.0.0.1" could also >>>>>>>>>>>>>>>>>> potentially be used >>>>>>>>>>>>>>>>>> to confuse users. We want to reject URLs with these >>>>>>>>>>>>>>>>>> hostnames. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Blink componentInternals>Network>DNS >>>>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3EDNS> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Motivation >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Most hostnames that aren't valid IPv4 addresses, but end >>>>>>>>>>>>>>>>>> in numbers are treated as valid hostnames, and looked up via >>>>>>>>>>>>>>>>>> DNS. Example >>>>>>>>>>>>>>>>>> hostnames: 127.0.0.0.1, foo.0.1, 10.0.0.09, 08.1.2.3. These >>>>>>>>>>>>>>>>>> can be >>>>>>>>>>>>>>>>>> problematic for the following reason: * " >>>>>>>>>>>>>>>>>> http://foo.127.1/"; has an eTLD+1 of "127.1", per the >>>>>>>>>>>>>>>>>> public suffix list spec. If that's ever used as the hostname >>>>>>>>>>>>>>>>>> in a new URL, >>>>>>>>>>>>>>>>>> however, as in "http://127.1 <http://127.0.0.1/>", it >>>>>>>>>>>>>>>>>> will then get mapped to "http://127.0.0.1/";, per the URL >>>>>>>>>>>>>>>>>> spec, which is a different host, which is not safe. * " >>>>>>>>>>>>>>>>>> http://127.0.0.0.1"; and "http://1.2.3.09";, both of which >>>>>>>>>>>>>>>>>> are looked up via DNS rather than failing or being treated >>>>>>>>>>>>>>>>>> as IPv4 >>>>>>>>>>>>>>>>>> hostnames, also seem potentially confusing. While no exploit >>>>>>>>>>>>>>>>>> is currently >>>>>>>>>>>>>>>>>> known here, we want to remove support for these as a >>>>>>>>>>>>>>>>>> preventative security >>>>>>>>>>>>>>>>>> measure. The URL spec has been updated so that any URL with >>>>>>>>>>>>>>>>>> a hostname >>>>>>>>>>>>>>>>>> ending in a number that's not an IPv4 address (including, >>>>>>>>>>>>>>>>>> e.g., >>>>>>>>>>>>>>>>>> http://foo.1./, but not http://foo.1../) is considered >>>>>>>>>>>>>>>>>> invalid. Since this is part of the URL spec, not the DNS >>>>>>>>>>>>>>>>>> spec, we want to >>>>>>>>>>>>>>>>>> reject these URLs are the GURL layer, for URLs with >>>>>>>>>>>>>>>>>> appropriate protocols >>>>>>>>>>>>>>>>>> (http, https, ws, wss, file). For consistency, we should >>>>>>>>>>>>>>>>>> also fail DNS >>>>>>>>>>>>>>>>>> lookup attempts of these sorts of hostnames. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Initial public proposal >>>>>>>>>>>>>>>>>> https://github.com/whatwg/url/pull/619 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> TAG reviewNot required for an Intent to Deprecate, I >>>>>>>>>>>>>>>>>> believe. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> TAG review statusNot applicable >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Risks >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Any URL with an affected hostname will fail to load, and >>>>>>>>>>>>>>>>>> will need to be migrated to another hostname. URLs of this >>>>>>>>>>>>>>>>>> form do appear >>>>>>>>>>>>>>>>>> to be in use, though it's not clear under what >>>>>>>>>>>>>>>>>> circumstances. No entry in >>>>>>>>>>>>>>>>>> the public suffix list is affected. Affected URLs make up no >>>>>>>>>>>>>>>>>> more than >>>>>>>>>>>>>>>>>> 0.0003% of hostnames looked up via the host resolver on any >>>>>>>>>>>>>>>>>> platform, and >>>>>>>>>>>>>>>>>> are basically not used in any file URLs, according to our >>>>>>>>>>>>>>>>>> metrics. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Do we have reason to believe these hostnames are not >>>>>>>>>>>>>>>>> legitimate ones? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Unfortunately, we have no insight into them - they could be >>>>>>>>>>>>>>>> mistyped URLs sent to typo squatting ISPs that OSX lets >>>>>>>>>>>>>>>> through but the >>>>>>>>>>>>>>>> Windows host resolver blocks, and various flavors of Linux >>>>>>>>>>>>>>>> treat >>>>>>>>>>>>>>>> differently. Or they could be mapped via a hosts file, or >>>>>>>>>>>>>>>> they could be >>>>>>>>>>>>>>>> hostnames that only resolve on public networks. Could be some >>>>>>>>>>>>>>>> network tool >>>>>>>>>>>>>>>> that uses them when installed locally, but is only available >>>>>>>>>>>>>>>> on certain >>>>>>>>>>>>>>>> platforms. No reason to think one possibility is more likely >>>>>>>>>>>>>>>> than the >>>>>>>>>>>>>>>> others. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Do we have UKM for them that would enable us to test a >>>>>>>>>>>>>>> random sample? >>>>>>>>>>>>>>> I'm concerned about blocking those hostnames if they are >>>>>>>>>>>>>>> legitimate, as that's something that a web developer can't do >>>>>>>>>>>>>>> anything >>>>>>>>>>>>>>> about. >>>>>>>>>>>>>>> So even if the number of hosts is small, I'd like to get >>>>>>>>>>>>>>> more certainty that they are *not* legitimate hosts before >>>>>>>>>>>>>>> blocking them. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> We have UKM on their number (0.0003% of DNS lookups on OSX, >>>>>>>>>>>>>> less elsewhere - we can't meaningfully instrument percent of >>>>>>>>>>>>>> created GURLs), but we don't have their hostnames, what they >>>>>>>>>>>>>> resolve to, or >>>>>>>>>>>>>> know anything else about them, unfortunately. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Navigation to a subset of these as frame URLs were broken at >>>>>>>>>>>>>> one point - I'm pretty sure the breakage even made it to stable: >>>>>>>>>>>>>> https://crbug.com/1173238. There were no reports of >>>>>>>>>>>>>> problems. Only non-IPv4 URLs where the last two components were >>>>>>>>>>>>>> broken, >>>>>>>>>>>>>> though, and it didn't affect subresources. On OSX and Android, >>>>>>>>>>>>>> over 99% of >>>>>>>>>>>>>> successfully resolved problematic hostnames fit into that >>>>>>>>>>>>>> bucket, though on >>>>>>>>>>>>>> Linux, only about 2% do. >>>>>>>>>>>>>> >>>>>>>>>>>>>> That doesn't give us any hard conclusions, except they're >>>>>>>>>>>>>> either not deliberate navigations on OSX/Android, or they're not >>>>>>>>>>>>>> navigations. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> :| >>>>>>>>>>>>> >>>>>>>>>>>>> One more question: Is this an intent to Prototype or an intent >>>>>>>>>>>>> to deprecate? The title is a bit unclear.. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On OSX and Android, about 90% of host resolver lookups >>>>>>>>>>>>>>>>>> for these hostnames succeed, 60% do on Linux, and 2% on >>>>>>>>>>>>>>>>>> Windows and >>>>>>>>>>>>>>>>>> ChromeOS. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Do you know where those failures are coming from? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Could be typos, could be the Windows and ChromeOS host >>>>>>>>>>>>>>>> resolvers don't let them through. Since we've had no filed >>>>>>>>>>>>>>>> bugs about >>>>>>>>>>>>>>>> them, I suspect the failures are not deliberate navigations or >>>>>>>>>>>>>>>> intended >>>>>>>>>>>>>>>> network requests. I'm much more interested in where the >>>>>>>>>>>>>>>> successes are >>>>>>>>>>>>>>>> coming from, myself. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> To allow for emergency disabling in case of wider than >>>>>>>>>>>>>>>>>> expected breakage, I intend to add a feature for it, and do >>>>>>>>>>>>>>>>>> a 50% field >>>>>>>>>>>>>>>>>> trial on pre-release channels, though plan to just enable >>>>>>>>>>>>>>>>>> the feature, >>>>>>>>>>>>>>>>>> rather than do a gradual rollout to stable, given the low >>>>>>>>>>>>>>>>>> usage. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Gecko: Positive ( >>>>>>>>>>>>>>>>>> https://github.com/whatwg/url/pull/619#issuecomment-890826499 >>>>>>>>>>>>>>>>>> <https://www.chromestatus.com/admin/features/launch/5679790780579840/1?intent=1> >>>>>>>>>>>>>>>>>> ) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Can you file an official position request? >>>>>>>>>>>>>>>>> https://bit.ly/blink-signals >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Done for Mozilla: >>>>>>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/568 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Should I also do this for WebKit as well? They have in >>>>>>>>>>>>>>>> process CLs, so not sure if it's still needed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Agree that in-flight patches for WebKit are a sufficient >>>>>>>>>>>>>>> positive signal. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> WebKit: In development ( >>>>>>>>>>>>>>>>>> https://bugs.webkit.org/show_bug.cgi?id=228826) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Web developers: No signals >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Activation >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This breaks anything using one of these domains, and >>>>>>>>>>>>>>>>>> requires migrating to other hostnames. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Security >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> None >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Debuggability >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> These will act like any other invalid URL. Behavior is >>>>>>>>>>>>>>>>>> context dependent. Since this is logic deep within GURL, and >>>>>>>>>>>>>>>>>> GURLs are >>>>>>>>>>>>>>>>>> created in a great many places, console warnings >>>>>>>>>>>>>>>>>> specifically for this seem >>>>>>>>>>>>>>>>>> not practical. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>>>>>> ?No. Javascript URL construction is tested, but URLs >>>>>>>>>>>>>>>>>> are used in a great many other places, which don't have test >>>>>>>>>>>>>>>>>> coverage, since DNS lookups for these domains must succeed >>>>>>>>>>>>>>>>>> in the first >>>>>>>>>>>>>>>>>> place for the tests to be meaningful. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Flag name >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Requires code in //chrome?False >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Tracking bughttps://crbug.com/1237032 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Estimated milestones >>>>>>>>>>>>>>>>>> DevTrial on desktop 95 >>>>>>>>>>>>>>>>>> DevTrial on Webview 95 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>>>>>> https://www.chromestatus.com/feature/5679790780579840 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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+...@chromium.org. >>>>>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEK7mvq%2Bfnau%3DE%2BONhe0kr9HOpN84eCpoub84%3DswKzPkrGzi5A%40mail.gmail.com >>>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEK7mvq%2Bfnau%3DE%2BONhe0kr9HOpN84eCpoub84%3DswKzPkrGzi5A%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/CAL5BFfWB4wVuGshgPaLVXp%3DYsWUiXgJhUABD3ZFJ9xbhg1J3ww%40mail.gmail.com >>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWB4wVuGshgPaLVXp%3DYsWUiXgJhUABD3ZFJ9xbhg1J3ww%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/CAEK7mvqcQ6p2%2B7bN83LwGQZmX1u9u-M%2B2ZiEEO47O88RM3O9QA%40mail.gmail.com.
