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/CAL5BFfWSa--F723gQJyk_9CwWPDySe7X%2Bge7UAut%2BxqmY4ETDg%40mail.gmail.com.
