3 are needed On Thu, Aug 26, 2021, 17:53 Matt Menke <mme...@google.com> 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 <yoavwe...@chromium.org> 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 <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/CAL5BFfWDjPt7vJ8pK0H65byTLMV7jNTBdA4pOpLUAg3%2B26jW8Q%40mail.gmail.com.
