Why is the "local" / "private" distinction made?

[annevk]

It's not entirely clear to me why we bother making this distinction, especially if it's not forward compatible with IPv6.

This relates to #3 and #13.

[letitz]

We could at least classify link-local IPv6 addresses as private but not local, so the distinction is not entirely incompatible.

That said, this distinction seems to come from Opera's initial behavior.

Philosophically, intranet websites accessing something on localhost are pivoting through the browser to attack a more-private resource (other browsers on different hosts might not be able to access the target, or would get different results). In that light, they are part of the problem: the browser is opening up an avenue for a website to access a resource that the user might reasonably expect to be secure by virtue of being bound to loopback only. This could enable attackers to traverse networks, which seems bad.

I don't have a strong preference here, just trying to hash out arguments in favor of the status quo.

[annevk]

One thing that might be interesting to look at is whether we could always require a preflight for inter-non-local communication. That would sidestep the classification issue of private vs local. If we cannot require that it's probably still valuable to have the distinction. (Might have changed my mind a bit since I wrote OP.)

[letitz]

What do you mean by "inter-non-local communication"? Do you mean all requests between non-public endpoints?

If so, I have also been thinking about this. For the moment I'm keeping #1 in my pocket for later, but I'd be interested in pre-flighting all cross-origin non-public-to-public requests.

[annevk]

Not all, but all of requests between non-local addresses that are cross-origin, e.g., from 127.0.0.1 to 127.0.0.2 or 127.0.0.1:9000 to 127.0.0.1:9001.

[letitz]

(months pass)

Yes, I think that would be a good thing to do eventually. I suspect however that it would result in much more widespread breakage on the web.

Regarding the private vs local distinction: I reworded the definition in https://wicg.github.io/private-network-access/#ip-address-space-heading since we last chatted. I think the distinction makes a bit more sense in that light:

• local addresses mean something different for every host
• private addresses mean something different based on network position, but their meaning may be shared among multiple hosts

In this view, local addresses can reference endpoints that are not addressable by other hosts - going from an intranet website to localhost is thus a kind of privilege escalation.

[annevk]

So is the handshake currently identical? That is, public -> private is the same dance as private -> local? It looks that way, but I'm not confident. Or in other words, is the distinction only relevant for when to trigger the handshake?

So if we indeed were able to pull of requiring opt-in all the time it wouldn't really change the protocol? (Should we track this aspiration in its own issue?)

[letitz]

So is the handshake currently identical? That is, public -> private is the same dance as private -> local? It looks that way, but I'm not confident. Or in other words, is the distinction only relevant for when to trigger the handshake?

The handshake is indeed identical, modulo the origins involved just like in regular CORS.

So if we indeed were able to pull of requiring opt-in all the time it wouldn't really change the protocol?

Correct, nothing would change except that we would trigger the pre-flight in more cases.

(Should we track this aspiration in its own issue?)

I've been referencing #1 for this, but it's an old PR and not an issue... I've been too lazy to write up a real issue, but you're right that it would be best. I'll file one.

[annevk]

Thanks, I think I'm happy with this then.

[letitz]

Great! Closing this issue then. Thanks for the discussion! I also filed #39 to replace #1.