Intent to Deprecate and Remove: Special handling of localhost6 and localhost6.localdomain6 hosts

[Frédéric Wang]

Contact emails

fw...@chromium.org

Explainer

None

Specification

https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy

https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06

API spec

Yes

Summary

Currently, "localhost6" and "localhost6.localdomain6" host names resolve to the IPV6 loopback address ::1 only, bypassing native DNS, and corresponding origins are treated as secured. The goal of this entry is to remove this non-standard behavior.

Blink component

Blink>Network

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This will improve interoperability since there is no specification defining this behavior and no plans in WebKit/Firefox to implement it.

There is a potential risk to break websites relying on these host names. It seems this was implemented ten years ago, motivated by existing DNS resolution in some Linux distributions. Public usage seems very low : on 218315452 urls from HTTPArchives, only 1 really uses localhost6 as a URL host and only as a JS example (namely https://hello-renovation.jp/assets/js/stories_recommender.js ) that is less than 0.000000005%.

People willing to continue to treat localhost6 and localhost6.localdomain6 specially for local development or specific systems can still configure native DNS. Chromium also implements a special allow list as permitted by the specification: https://source.chromium.org/chromium/chromium/src/+/master:services/network/public/cpp/is_potentially_trustworthy.h;l=43;drc=bf799475f9ff40b7e1e2be2fd3a68911c4f047ee

Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1220810) Firefox implemented the specification for "localhost" but not the non-standard values "localhost6" or "localhost6.localdomain6" which were never discussed.

WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=171934) There is not an official position, some Apple people have expressed interest for implementing this "localhost" resolution (currently native DNS on macOS/iOS don't do that), others had concerns about allowing websites to access localhost addresses and so make them trustworthy. Introducing "localhost6" and "localhost6.localdomain6" would only make harder to reach a consensus, while Chrome making a step towards the spec / other browsers could be appreciated.

Web developers: Positive Developers were positive about making Firefox/WebKit more interoperable with Chrome.

Security

This is reducing the scope of "potentially trustworthy" so making security stricter.

Is this feature fully tested by web-platform-tests?

No

We could potentially write some if we had more host names in https://web-platform-tests.org/running-tests/from-local-system.html#hosts-file-setup

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1153337

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5698580851458048

This intent message was generated by Chrome Platform Status.

-- 
Frédéric Wang

[Mike West]

LGTM1. This aligns us with other vendors' behavior regarding these domain names, and removes a Chromium weirdness that was both undertested and unspecified. I don't expect it to be used at all publicly, and I don't think it's going to be possible for us to understand its usage in private networks given those networks characteristics. Since it was never supported in any non-Chromium browser, and its support in Chromium was initially predicated on its presence in specific platforms' /etc/hosts file, I expect minimal breakage. Developers can work around this removal by a) dropping the "6" from their pages (`localhost` is both interoperable and secure), b) adding `localhost6`, etc to their local /etc/hosts, or c) adding `localhost6` to their DNS resolver. Any seem workable.

I don't think this needs a TAG review, since it isn't specified anywhere, and isn't implemented in any other browser. We're aligning with the rest of the platform, which seems a priori reasonable.

-mike

[Jochen Eisinger]

lgtm2

--
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/f8203c4b-4c4b-4994-93be-b9008dc4e630n%40chromium.org.

[Frédéric Wang]

On 09/12/2020 15:20, Mike West wrote:

LGTM1. This aligns us with other vendors' behavior regarding these domain names, and removes a Chromium weirdness that was both undertested and unspecified. I don't expect it to be used at all publicly, and I don't think it's going to be possible for us to understand its usage in private networks given those networks characteristics. Since it was never supported in any non-Chromium browser, and its support in Chromium was initially predicated on its presence in specific platforms' /etc/hosts file, I expect minimal breakage. Developers can work around this removal by a) dropping the "6" from their pages (`localhost` is both interoperable and secure), b) adding `localhost6`, etc to their local /etc/hosts, or c) adding `localhost6` to their DNS resolver. Any seem workable.

Thanks Mike, just a nit: for b) or c) I think one might need to do something to keep "localhost6" potentially trustworthy. However, I think this option is enough:

Chromium also implements a special allow list as permitted by the specification: https://source.chromium.org/chromium/chromium/src/+/master:services/network/public/cpp/is_potentially_trustworthy.h;l=43;drc=bf799475f9ff40b7e1e2be2fd3a68911c4f047ee

-- 
Frédéric Wang

[Yoav Weiss]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjhuifswRbBCFiaY%3DWZOTRAW7wtZtTYp205syjwMpk%3DdP%3Dtyg%40mail.gmail.com.