Incorperate let-localhost-be-localhost

[annevk]

As part of defining DNS cache partitioning, we could integrate https://tools.ietf.org/html/draft-west-let-localhost-be-localhost into Fetch, so at least it's a requirement for browsers.

@youennf are there any Apple-specific concerns with this plan? I'm not sure where you all are at with this.

cc @fred-wang

[youennf]

localhost host name has a specific treatment so I think it is good to make sure it is using the loopback interface.
I am less sure about other localhost URLs. Are Chrome and Firefox consistently implementing this draft?

[annevk]

I think so, yes.

[youennf]

We actually recently started to treat *.localhost similarly to 'localhost' in some code paths.
This seems like a good requirement to add.

[fred-wang]

For the record, these are related webkit bugs I'm working on : https://bugs.webkit.org/show_bug.cgi?id=218623 https://bugs.webkit.org/show_bug.cgi?id=218627

I think there were internal discussions at Apple about this stuff, I'm cc'in @othermaciej and @hober who might know better the status.

[hober]

I see @youennf already chimed in. I saw some relevant discussion in the HTTP WG where @johnwilander had thoughts, perhaps he can share them here.

[johnwilander]

This is what I said first on the WebKit Slack, then on one of the Bugzillas referenced above:

We discussed this extensively in the W3C WebAppSec group back in 2016 or so. Our position was that loopback connections should only be allowed in Secure Contexts or if the top frame is loaded from the loopback itself. No other browser was interested in that at the time so we didn't change anything.

Since then, the amount of fingerprinting attacks against the loopback interface has increased. Therefore, we are mostly interested in further restricting loopback connections.

I'm personally still in favor of restricting loopback to Secure Contexts which obviously requires not treating it as mixed content (in Secure Contexts).

[annevk]

That's interesting and also something that ought to be defined, perhaps as part of https://wicg.github.io/cors-rfc1918/ or Mixed Content, but it seems separable from how localhost is resolved.

In trying to determine how to best address the latter in Fetch the main roadblock I encountered as that this should apply to all connections a browser makes, including those from WebRTC and WebSocket, and I'm not entirely sure how to best address that yet. Thoughts and ideas very much appreciated.

[alvestrand]

Note - current version is https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02, and the draft expired in 2018.

[annevk]

@alvestrand indeed, but all browsers plan to enforce it so we'll specify it in Fetch instead.