#572: Private Network Access (aka CORS-RFC1918)

Visit on Github.

Opened Nov 16, 2020

Hi there friendly TAG members,

I'm requesting a TAG review of CORS-RFC1918.

CORS-RFC1918 is a web specification which aims to protect websites accessed over the private network (either on localhost or a private IP address) from malicious cross-origin requests.

Further details:

  • I have reviewed the TAG's API 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, I think?
  • Existing major pieces of multi-stakeholder review or discussion of this design: https://github.com/WICG/cors-rfc1918/issues/
  • Major unresolved issues with or opposition to this design: none
  • This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

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

Discussions

2021-01-Kronos

Minutes

Hadley: the big picture concept makes sense to me...

Hadley: CORS over private networks...

Hadley: 3 layers - localhost, private IP addresses, and public IP addresses. Local, private and public as layers... And mapping IP addresses agains them... They are in RFC-1918.

Peter: the web site can make requests to web sites on local addresses - like your printer - and without CORS prefetch. A lot of these devices presume they will run on a firewall are not secure. What they want to do - make any request on local host or a private network we do a CORS pre-flight and include a special header. Prevents the browser to making requests to local devices unless they specifically opt in. Some concerns - e.g. HP has 2 /8 networks... Every device on their network has 2 IPv4 addresses ... in IPv6 that is the norm. Many ISPs give you IPv6...

Peter: this doesn't stop you from opening up a connection to your device... it only stops an external web site from knowing if you're out of magenta.

Dan: IPv6 very common.

Peter: some variance on what ISPs give you...

2021-03-15

Minutes

Hadley: comment from mike - Mike has good will, however...

Peter: could be that everyone thinks this is the right direction but they are happy with Chrome to lead the way and see what breaks...

Dan: not enough input from other parties. I'd love to know mnot's view on this, it leads to IETF territory.

Hadley: in one of the issues linked, Anne has expressed support.

Dan: do we have any concern about it?

Yves: if there is no implementation traciton - it won't reach a point where it will be implemented in a reasonable way...

Peter: my key concern is about ipv6 - how to tell private from public. Not everyone uses NAT... ipv6 can be tricky. Their response addresses one of the issues. They do have issues tracking these things. I'm OK to let them grind away at it.

Yves: there are link local addresses in ipv6.

Peter: some isps will give you an entire ..

[discussion on the ins and outs of ipv6]

Peter: my computer for example gets a public ipv6 address but i have 2 other /64 subnets behind my firewall. .. so might be considered public but actually private... but they know about this problem.

Dan: close it and say "we've already expressed our feedback - we look forward to hearing about your implementation experience" and I have reached out to Mark.

[proposed close

2021-03-22

Minutes

Dan: Will ask Wendy for a liaison with IETF on the issue.

2021-03-29

Minutes

Peter: we pinged folks about IETF coordination

Dan: haven't heard anything back. I will ping Martin Thompson.

2021-07-19

Minutes

Yves: a bit wary. understand the cocnern about use of older hardware but why not us a proxy of some kind?

2021-07-26

Minutes

Yves: won't be here for 3 weeks

Dan: generally supportive but they need to engage with ietf feedback.. they want us to see how they've engaged with the ietf feedback.. re-review because they rewrote the fetch integration section to be "less handwavey". [leaves comment]

2021-08-23

Minutes

Dan: last comment from the requester.. saying there's been a lot of changes which address some of our issues [leaves comment]

Yves: will look next week

2021-09-27

Minutes

Yves: I need to reply - they didn't understand what I meant on diffeence between local network and privsate network - devices physically on your local network. I will reply on that.

Peter: agree they didn't seem to understand...

2021-09-Gethen

Minutes

Yves: protecting things on private networks - but requires devices to implement this specification. I was wondering if it woudl be better to ahve the browser do some gatekeeping... Using MDNS these local services broadcast if they are on local network - browser could listen to those... and then the browser filter the request to anything on local network to see if it's accessible or not.. to access devices that are not up to date.. http not https, ... here it requires devices to be updated.

Rossen: In model you described - shift the responsibility into the UA - requires any UA to have similar capabilities -- Slack, Email client, chat system, to implement the same or similar capability. That approach is seemingly spreading that problem...

Yves: this is for something where the main page is on the internet but you want to talk to something on your local network...

Yves: printers.. advertises itself as e.g. airprint device... can be accessed using http. If the browser forbids all request on local network - allow only things that are advertised... ask the user "do you want to be able to share it" with external pages... user can say yes or no.

Dan: could that become a fingerprinting vector...

Yves: maybe if you have ways to list all devices...

Dan: Web Bluetooth e.g. provides a browser mediated choose function and does not provide a list back to the web site...

[discussion of risks associated with home applicanes]

Rossen: It's even worse when access is granted to gas stoves or vehicles, cars etc.

Dan: they need to address the issue of how to deal with legacy devices...

Peter: I don't think everything that broadcasts mdns should be easily accessible this way - e.g. security cameras... Other issue is that we have the issue of a general service discover mechanism - this should be tied into that. I think the MDNS idea is good but there needs to be a user prompt in the way... Also I do like that they called out that the UA can specify ipv6 public ranges as being public...

[Discussion getting into the ipv6 weeds and what constitutes a private address in an ipv6 network...]

Yves: should we consider local networks.. everything behind the router? what's in the rfc?

Peter: it should be configurable. They did take it into account tho it's weak - a "may".

[yves to leave comment]

2021-10-11

Minutes

Yves: not much since my last commet. We gave feedback we need to care about older devices. We could give feedback that the rest is ok but this point is sitll pending.

Dan: closed as satisfied with concerns?

Yves: yes we should express concerns.

Peter: do we have issues open in their repo? I'd feel more comfortable closing this if we had them.

Yves: I'll check it.

Peter: after doing that then close and comment with satisifed-with-concerns.

2021-12-Madripoor

Minutes

Yves: the goal was to ensure legacy devices that cannot be updated can still be available ... otherwise blocking everything else... also focusing on the difference between private network and local network... difference between what you have in your LAN and a private network.

reviewing response

Yves: the first part - part of dealing with legacy devices that might not be upgraded to support this specification but not related to this specificaiton directly. On the 2nd part it's up to the user agent to decide what devices they want to surface or not. There needs to be agreement between the browsers. But not something that can be decided in the review.

Dan: Can I suggest that we close this then with a "satisfied"?

Yves: yes. I will close it.