Site identification and localhost

[martinthomson]

In general, we try to make http://localhost a valid choice for operating services in browser APIs, if only because that enables testing.

Right now, the specification explicitly rules out localhost, largely just because it isn't generally accessible using HTTPS. Should we take special steps to accommodate testing, or can we instead ask that people use self-signed certificates for testing this API? What other alternative approaches could we take?

[csharrison]

cc @mikewest who I chatted w/ about this a few weeks ago.

[mikewest]

I vaguely recall a conversation! :)

I didn't see anything in https://w3c.github.io/ppa/ that specifically limited localhost, so I'm likely missing context. That said, I do see some SecureContext annotations locking down the exposure of various IDL attributes. Those will be exposed on http://localhost in browsers that choose to consider that securely-transported (see https://w3c.github.io/webappsec-secure-contexts/#localhost), and it seems reasonable to me for developers to expect that the exposed bits would be available for testing.

What special steps might be necessary to support localhost? It's certainly not out of the question to point people to mkcert or similar if the work is onerous, but generally it's desirable to prioritize smoothing the path for web developers.

[martinthomson]

This is one of those cases where the API directly exposes sites to the concept of a "site". For localhost, the concept of site doesn't hold in quite the same way as it does for other sites.

The definition of site for a the tuple of scheme and - because the registrable domain for localhost is null - that means the tuple ("http", "localhost"). That's fine on face value, but I have a number of concerns. Maybe those concerns are out of scope for this work, but they are worth raising anyway.

Shared Control

The definition of site is created with the presumption of shared administrative control. That is, www.example.com and foo.example.com and all other named under .example.com are assumed to answer to a common authority, so there is some expectation that sharing state is acceptable.

That's not true for localhost, where the only shared authority is (maybe) the user, who is not obviously in control in quite the same way as we might expect site operators to be. Each open port on localhost could be controlled by an arbitrary entity who just happens to have an installed app.

Secure...hah!

The definition of "potentially trustworthy" relies on this idea that information is delivered to the other end "securely" without really defining what that means.

localhost is assumed to meet this standard, presumably because there is no hope of interception by adversaries. Or maybe it is more like it is because this is a convenient fiction that allows us to make exceptions for people doing testing over loopback interfaces.

That you have a slightly more controlled environment than a network is a story we might tell ourselves to sleep soundly, but in practice the port that one app opened yesterday could be available for another app to open tomorrow. HTTPS does address that concern because it allows the identity of the app to be cryptographically bound to something, even if it is just to a public key.

A Convenient Fiction

The fact that we regard localhost as an acceptable place to invoke these APIs is nothing more than a recognition of the value of the developer experience. We could pretend that it's all OK, but we have recent evidence of this being a bad assumption. That's why I like mkcert for this.

[erik-anderson]

Requiring a TLS certificate doesn't seem like much of a speed bump if we assume that the locally-installed app can also install a trusted root to ensure it's trusted. I suppose that depends on the OS and app source.

Even a non-localhost hostname + valid TLS cert also doesn't up the bar that much-- the adversary can just return loopback addresses for DNS resolutions (plus ensuring the cert is trusted).

What is the localhost restriction actually trying to accomplish? Should things be specified to disallow the use of the API if the document was loaded from a loopback address, independent of hostname? And to enable testing, perhaps have a browser testability switch to temporarily allow it (including for localhost)?

And, if that sort of complexity is warranted, should it instead be covered by some broader, more encompassing approach such as what's being explored in Chrome's local network access restrictions proposal? If that existed and introduced a user permission gate for this, would that be a better path?

[martinthomson]

What is the localhost restriction actually trying to accomplish?

Depends on what you are asking. The current text in PPA only requires that the site uses an "https" scheme, which doesn't eliminate localhost entirely, just http://localhost (that is, not https).

[erik-anderson]

Why not define it as requiring SecureContext, which allows http://localhost in many browsers? The current text is implicitly going out of its way to block http://localhost specifically.

If the concern is tracking enabled by a local server (e.g., emitting a durable device identifier), and we haven't solved it for other APIs (e.g., Fetch), adding local dev testing friction for this API doesn't make a lot of sense to me.

Even if the cert requirement is reasonable, I'm not sure it's a significant barrier for tracking. Perhaps if the user is using an OS/browser that makes it hard to trust a locally-installed cert and we assume CA/B Forum rules will discourage apps from distributing the private key for a publicly-issued cert, abuse might be difficult within those constraints.

But even then, wouldn't the app just use Fetch to http://localhost anyway? Shouldn't we focus on closing the hole entirely instead of adding minor local testing dev pain for PPA?

[martinthomson]

See above. I don't think that http+localhost should be considered as a "site".

[AramZS]

I have no objection to it not being usable on http+localhost as long as the reason why is clearly indicated to developers in the console.