1481298 - (private-network-access) [meta] (Local) Private Network Access

Status: NEW

(Core :: DOM: Networking, enhancement, P5)

Description

[Blake Kaplan (:mrbkap) (inactive)]

Bug 1475445 was filed because there's a mochitest testing that we have an implementation of [1]. We don't seem to implement it and I can't find an existing bug on file to do so. Anne, Is this something we want to do?

[1] https://wicg.github.io/cors-rfc1918/

Comment 1

[Anne (:annevk)]

I'm not sure, I don't think we've really discussed it thus far. It seems reasonable, if Chrome can somehow prove it to work, but there's a lot of legacy local network hardware that'd be impacted as I understand it. Maybe mt has thoughts?

Comment 2

[Martin Thomson [:mt:]]

The operating principle here is that "local" things might somehow use the fact that a client is also local to privilege that client.  That is, a server might use the fact a client is on the local network or local link to somehow authorize that client.

This is reasonable on the face of it, and the increase in complexity for fetch is minor.  However, I think that it creates the wrong incentives.  We've been very careful to tell people not to use access to a network as a signal like this.  That is, we tell people that they need to implement good access control, no matter what they assume about their network environment (if a browser is deployed to that network, imagine what else could be there!).  Implementing a feature like this would - at some level - legitimize bad practice.

We have also left bug 354493 unfixed for a very long time now (this spec is mentioned there).  The last attempt bounced four years ago.  This is a less disruptive change, but I suspect that it will still cause breakage.  mcmanus might know more.

Comment 6

[Valentin Gosu [:valentin] (he/him)]

Update: This feature is on the Necko roadmap. We will probably schedule some implementation effort in 2024.