Intent to Deprecate and Remove: Special handling of localhost.localdomain host

[Frédéric Wang]

Hello,

Please find below my intent to remove special handling for "localhost.localdomain" host name. This intent is very similar to the localhost6 and localhost6.localdomain that I sent earlier. The reason why I sent this separately is that contrary to localhost6 where a rough regex search on HTTPArchive essentially led to 0 matches, similar search for localhost.localdomain has an upper bound of 0.000009% pages corresponding to potential real usages.

So while for now my CL at https://chromium-review.googlesource.com/c/chromium/src/+/2577688 just removes "localhost.localdomain", it's possible that we want to be more careful (introduce a pref flag, use counter, etc) before unshipping. I'm welcoming suggestions from API owners on that point.

Thanks,

---------

Contact emails

fw...@chromium.org

Explainer

None

Specification

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

API spec

Yes

Design docs

https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06
https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy

Summary

Currently, host name "localhost.localdomain" resolve to the loopback addresses ::1 and 127.0.0.1, bypassing native DNS, and corresponding origin is treated as secured. The goal of this entry is to remove this non-standard behavior.

Movation

Standards describe an optional resolution of the "localhost" host name and trustworthiness of corresponding origin [1] [2]. Users have complained about inconsistency between Chromium (which implements the spec), Firefox (which only implemented it recently) and WebKit (where patches are being submitted). Hopefully things can be make consistent and the specification a bit stricter. However, Chromium also has similar but non-standard behavior for "localhost.localdomain". Removing this would help to make things more predictable for users.

Blink component

Blink

TAG review

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 relatively low (see detailed analysis below). People willing to continue to treat localhost.localdomain 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 value "localhost.localdomain" which was 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 "localhost.localdomain" 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 (see corresponding bug reports).

Detailed analysis:  Performed on BigQuery's response_bodies.2020_10_01_desktop, based on about 218315452 urls of HTTPArchive.

Pages containing a quoted string with localhost.localdomain were extracted  (more precisely, those matching the regexp r"[\"\'`][^\"\'`]*(?:localhost.localdomain)[^\"\'`]*[\"\'`]") and 8334 urls were found (for a total of 8746 matched strings).

- 6533 of them contains a match of the form globalStorage["localhost.localdomain"] (corresponding to an API from Firefox < 13) the remaining cases represent less than 0.000009% of the original set.

For the remaining cases:
- 895 contain a match corresponding to an array of localhost names like "localhost","localhost.localdomain".
- 675 contain a match corresponding to a fallback expression like ||"localhost.localdomain".
- The remaining cases represent ~0.000001% of the original set.

If you search in the chromium source you'll find various matches https://source.chromium.org/search?q=localhost.localdomain

but often they just seem to be used as illustrative purpose or a default placeholder than implying a real semantic.

Security

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

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

No

Tracking bug

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

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5668106045227008

This intent message was generated by Chrome Platform Status.

-- 
Frédéric Wang

[Mike West]

LGTM1, for the same reasons as the `localhost6` intent. The risk here is not different in kind, and I expect the success of one is as likely as the success of the other.

-mike

--
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/7d70969b-2b03-534c-a6e0-615c41118183%40igalia.com.

[yo...@yoav.ws]

LGTM2

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b7383eab-9ac1-4792-84e5-4ea0b56ea291n%40chromium.org.