Seems like we've got a positive signal from Mozilla, along with a spec bug <https://github.com/whatwg/url/issues/632>.
LGTM1 to remove, while fixing that issue in spec (and potentially in implementation) On Sun, Aug 22, 2021 at 10:52 PM Matt Menke <mme...@google.com> wrote: > 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/CAL5BFfVzJT_Oy9G%2BuXdbxkUoS6qkLqM66b-rUg9NPq-CC0JPyg%40mail.gmail.com.
