Private Network Access / Local Network Access / CORS-RFC1918

[lidel]

Update 2023Q2: this spec was known as "Private Network Access", got renamed to "Local Network Access" since then.

Explainer: https://github.com/WICG/cors-rfc1918/blob/master/explainer.md

https://wicg.github.io/private-network-access/ → https://wicg.github.io/local-network-access https://web.dev/cors-rfc1918-feedback/ https://groups.google.com/a/chromium.org/g/blink-dev/c/cPiRNjFoCag https://lists.webkit.org/pipermail/webkit-dev/2021-May/031836.html https://chromestatus.com/feature/5436853517811712

Summary

The proposal is to restrict "private network requests" for subresources to secure contexts.

Chromium is leading this and will deny CORS access to LAN and loopback addresses by default, and allow them only when additional CORS flag Access-Control-Request-Private-Network: true is sent by the server's response during preflight response.

This is a good thing, because it closes security issue of websites probing insecure services with default admin passwords etc.

Impact on localhost IPFS gateway

IIUC this does not impact our main use case (running IPFS gateway on localhost) because "private network request" is defined in those changes as a request crossing an address space boundary to a more-private address space. In the local gateway case, the root document is already localhost, there is no context-crossing, so we are good.

Impact on LAN IPFS gateway / node /relay

Impacts our p2p connectivity story. Need to be analyzed further.

Impact on JS on regular pages

Websites won't be able to load subresources from local HTTP ports API and Gateway unless IPFS node responds with Access-Control-Request-Private-Network: true to the preflight request. This is great news for securing API port even further.

Unlike the API port, Gateway one has pretty liberal CORS policy. We already allow CORS with *, but not sure if we want setting Access-Control-Request-Private-Network: true. Doing cross-origin requests is not something people do, the only use case for JavaScript is sniffing if user is running a local gateway, but AFAIK there is no practical use of this in JS on regular pages.

Impact on ipfs:// handlers and our browser extension

However, cross-origin load of subresources is something what IPFS Companion does, and could also be a factor when ipfs:// registration over registerProtocolHandler backed by a local gateway gets more popular.

The preflight header Access-Control-Request-Private-Network: true can be easily added to the gateway logic, however there are some unknowns that depend on vendor implementation, and require additional QA, namely:

• [ ] on-the-fly redirects applied by ipfs-companion browser extension (in the past we had bugs where Firefox and Chromium validated CORS around  chrome.webRequest in different order, and there are no specs for webextension behavior, so.. )
  • not impacted, https://audius.co/trending loads chunks from local gateway
• [ ] ipfs:// handler (registerProtocolHandler backed by http:// gateway on localhost API
  • not in scope: ipfs:// can't be used in subresources (yet)

[lidel]

This spec got renamed to "Local Network Access" (https://github.com/WICG/local-network-access/issues/91):

• https://wicg.github.io/local-network-access

[lidel]

It got renamed to "Private Network Access" again ;-)

Also:

Intent to Prototype: Private Network Access permission to relax mixed content:

• https://groups.google.com/a/chromium.org/g/blink-dev/c/6MczoSFGiHo/m/IigYuhu7AwAJ

IPFS would benefit from a way to lift mixed-content for trusted LANs. For example, it would allow JS nodes (and @helia/verified-fetch) to opportunistically use a LAN IPFS nodes as a local block cache, when present.