Open lidel opened 3 years ago
This spec got renamed to "Local Network Access" (https://github.com/WICG/local-network-access/issues/91):
It got renamed to "Private Network Access" again ;-)
Also:
Intent to Prototype: Private Network Access permission to relax mixed content:
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.
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 settingAccess-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 extensionHowever, 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:ipfs://
handler (registerProtocolHandler backed by http:// gateway on localhost APIipfs://
can't be used in subresources (yet)