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 <yoavwe...@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 <yoavwe...@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 <jrobb...@google.com> - 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 <yoavwe...@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 <yoavwe...@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 < >>>>>>>>>> yoavwe...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Aug 18, 2021 at 8:47 PM 'Matt Menke' via blink-dev < >>>>>>>>>>> blink-dev@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 proposalhttps://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+unsubscr...@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+unsubscr...@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/CAOqqYVF2YadL8h6hREorqgGrKTb2zU-xkzmhsOpDfdpQ%2BeNX2Q%40mail.gmail.com.
