Re: [w3ctag/design-reviews] Private Network Access (aka CORS-RFC1918) (#572)

> We discussed this again in our Virtual F2F, and had questions about legacy devices.
> As one goal is to ensure that you don't attack devices, legacy devices that can't be updated comes to mind, link printers.
> Most of those devices are usually advertised on the local network, so the UA might be able to figure them out and allowing access like a "paired" device (to avoid completely blocking them out).

The goal is not to block any and all accesses to local network devices, but rather to prevent CSRF attacks on them. As such, only requests initiated by more-public websites will be subject to new restrictions.

If such a device offers its own UI on http://printer.local, and the user navigates there by typing it in the URL bar, then no restrictions are applied and things will work as before.

As for pairing, that's an interesting question. Without using HTTPS to cryptographically authenticate the target device, granting access permissions seems to open the door to confused deputy issues. Are you suggesting "pairing" ceremonies between origins and devices advertising themselves using mDNS?

> Another issue is, should the local network be only the ip/netmask range and not the list of all the private ranges?

Currently, all IP ranges specified in RFC 1918 are considered `private`, as well as a few others. See [this algorithm](https://wicg.github.io/private-network-access/#determine-the-ip-address-space) in the spec. An earlier version of this spec proposed to rely on the IANA special-purpose address to define address spaces, but that was discouraged by network experts upon consultation: see https://github.com/WICG/private-network-access/issues/50.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/572#issuecomment-919255834