#751: Private Network Access (aka CORS-RFC1918) permission to relax mixed content

Visit on Github.

Opened Jun 28, 2022

Wotcher TAG!

I'm requesting a TAG review of Private Network Access permission to relax mixed content.

A new permission to relax mixed content restrictions for private network resources while secure context restriction enabled on public websites which initialed request to private network.

  • Explainer: [url]
  • Security and Privacy self-review: [url]
  • GitHub repo: [url]
  • Primary contacts (and their relationship to the specification):
    • Yifan Luo (@iVanlIsh), Google, specifier / implementer
    • Titouan Regoudy (@letitz), Google, specifier / implementer ( on leave )
    • Mike West (@mikewest), Google, original specifier / implementer
  • Organization driving the design: Google
  • External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/guide/edit/5954091755241472

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
  • The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
  • Existing major pieces of multi-stakeholder review or discussion of this design: https://github.com/WICG/private-network-access/issues/23
  • Major unresolved issues with or opposition to this design: None
  • This work is being funded by: Google

You should also know that...

The major part of the spec has already been reviewed in https://github.com/w3ctag/design-reviews/issues/572 Here we forced on permission part to relax mixed content restrictions.

We'd prefer the TAG provide feedback as :

🐛 open issues in our GitHub repo for each point of feedback

Discussions

2022-07-London

Minutes

Max: a proposed mechanism for the UA to have a security role -- for example a request to access the local IP address - policy to have restriction on that but option for the UA to set that - ok for this kind of request it's allowed. In summary it's trying to solve security issues... e.g. an attacker which could access to local IP address could change the config of the home router. Comment: they only focus on IPv4 -- they don't have IPv6...

Yves: IPv6 local network more identifiable - even easier than knowing the ranges for IPv4. Link local addresses.. I think the IPv6 case is simpler. Otherwise this looks good to me as well. when you want to create something secure you need to sign something to look legit. Allowing plain http request on the local network ... to be considered secure - should be valid option. Provided your wifi is secure and noone has access to your local network. It solves issues around key management and signatures.

Dan: Clearly. I've seen this with my printer. You have to acess by HTTP, if you want to use HTTPS, you have to self-sign a cert, and install it on the printer, and nobody does that. And then you have to install it on every machine.

Yves: Other way to do this: devices on your local network talking to a remote place to manage signatures, and... it's bad.

It will solve lots of issues. IF your local network is properly secured, it should be fine.

Dan: we close?

Yves: with ipv6 comment.

Hadley: Also - most local networks are delivered by a router form your ISP - it just works, turn it on.

Yves: and usually proper security?

Hadley: how much existing install base breaks?

Yves: it won't break existing things... only in the sense that if you rely on something being broken it won't be the case.

Dan: so for this to work, does anything of the newtork need to change? You could have the same wifi router with no updates to its firmware, and you get a new printer...

Yves: it's the browser that needs to know that it can do this. Nothing changes in the underlying network.

Yves: a prompt will warn users ... in the explainer it says it's behind a prompt.

agreed to close, Yves to wrote closing comment