Private Network Access / Local Network Access / CORS-RFC1918

> Update 2023Q2: this spec was known as "Private Network Access", got [renamed](https://github.com/WICG/local-network-access/issues/91) 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](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/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](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler) backed by http:// gateway on localhost API
- not in scope: `ipfs://` can't be used in subresources (yet)

Start with the linked Local Network Access explainer and the Chromium and WebKit discussions. Compare their requirements with the localhost and LAN gateway cases, including browser-extension redirects and ipfs:// handlers. Done means documenting the affected cases, identifying what is out of scope, and recording the QA needed; no repository file or test is named.

Written by the indexing model from the issue text.