LGTM2 On Thu, Aug 26, 2021 at 9:14 AM Matt Menke <[email protected]> wrote:
> Re-sending this in groups UI, since my last two emails took 2 days to show > up, and my latest one hasn't shown up on the groups UI yet. > > No, I'm not - I don't think there's a reasonable way to do this. GURLs > are not constructed in a single place. This affects navigations to URLs, > favicon URLs, fetch URLs, URLs constructed directly, redirects to URLs, > proxy URLs, PAC script URLs, headless debugging URLs, DoH URLs, etc. > > On Thursday, August 26, 2021 at 11:56:42 AM UTC-4 Yoav Weiss wrote: > >> Also, are you planning to have a deprecation period with e.g. console >> errors to let developers know this will break soon? >> >> On Thu, Aug 26, 2021, 17:54 Yoav Weiss <[email protected]> wrote: >> >>> 3 are needed >>> >>> On Thu, Aug 26, 2021, 17:53 Matt Menke <[email protected]> wrote: >>> >>>> Is one LGTM enough for intent-to-deprecates, or do I need 3? >>>> >>>> On Mon, Aug 23, 2021 at 3:50 AM Yoav Weiss <[email protected]> >>>> wrote: >>>> >>>>> 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 <[email protected]> wrote: >>>>> >>>>>> Sorry, that should be "before instantiating content" (Or "before >>>>>> calling ContentMain") >>>>>> >>>>>> On Sun, Aug 22, 2021 at 4:51 PM Matt Menke <[email protected]> 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 <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>>> 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 < >>>>>>>>> [email protected]> 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 <[email protected]> >>>>>>>>>> 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 <[email protected]> >>>>>>>>>>>> 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 < >>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Interesting! What happens then in the "successful >>>>>>>>>>>>>>> resolution" case Matt mentioned? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Aug 19, 2021 at 2:39 PM Harald Alvestrand < >>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thu, Aug 19, 2021 at 2:28 PM Matt Menke < >>>>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Wed, Aug 18, 2021 at 11:36 PM Matt Menke < >>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Wed, Aug 18, 2021 at 5:23 PM Yoav Weiss < >>>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Wed, Aug 18, 2021 at 11:18 PM Matt Menke < >>>>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Wed, Aug 18, 2021 at 4:53 PM Yoav Weiss < >>>>>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Wed, Aug 18, 2021 at 8:47 PM 'Matt Menke' via >>>>>>>>>>>>>>>>>>>>>>> blink-dev <[email protected]> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Contact [email protected] >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>>>>> [email protected]. >>>>>>>>>>>>>>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>>>>>>> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cff2a72a-f37b-4cc9-aeff-51ea86c47674n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cff2a72a-f37b-4cc9-aeff-51ea86c47674n%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-mPBO%3DCEKZmehnpZKaOMNLqFjhXZmXzP4agJ9e%3D4jUFQ%40mail.gmail.com.
