A proposal to restrict sites from accessing a users’ local network

Security motivation and threat models

• Many commenters support restricting public sites from talking to localhost or private IPs, calling current behavior “insane” given:
  • Web pages can already issue HTTP requests to LAN devices and localhost (including no-cors “simple” requests, <img> and <form> CSRF, WebSockets, DNS rebinding, timing attacks).
  • Examples discussed: Meta/Facebook localhost tracking IDs, Zoom’s localhost server zero‑day, routers/printers/dev servers with unauthenticated or weakly checked endpoints, Bitcoin or JSON‑RPC APIs with poor Content‑Type checks.
• Clarifications: CORS mainly governs whether JS can read responses; many “simple” requests still reach local devices and can change state or trigger exploits even if the response is opaque.

Legitimate use cases that might break

• Wide range of existing patterns rely on browser→local HTTP:
  • Desktop helpers behind web UIs (password managers, CAD/3D mouse support, 3D printers, Plex‑style dashboards, enterprise agents, OAuth redirect listeners on localhost).
  • IoT and NAS/router management UIs using a single cloud page that CORS‑fetches metrics directly from multiple local devices.
  • Local signing with smartcards/e‑IDs, local LLM/AI servers, Jupyter, test report viewers, LAN file‑sharing tools (e.g. PairDrop).
• Some argue these are better implemented as:
  • Browser extensions with native messaging, custom protocol handlers, or fully local/static UIs.
  • UIs hosted on the device itself; but others describe severe pain around HTTPS, certificates, and “secure context” APIs for devices without public domains.

Permissions, UX, and granularity

• Many welcome per‑site browser prompts (“this site wants to access devices on your local network”) similar to camera/mic.
• Others think prompts are largely ineffective, citing macOS/iOS/UAC patterns where users reflexively click “Allow,” especially when sites instruct them to do so.
• Concerns that the proposed permission is coarse‑grained (all local hosts/ports) and violates least‑privilege; suggestions include:
  • Firewall‑like controls (CIDRs, ports, localhost vs LAN vs VPN) and possibly mDNS‑backed, human‑readable device names in prompts.
  • API surfaces for extensions to enforce more detailed policies (some of which were weakened by Chrome’s Manifest V3).

Definitions of “local” and IPv6 / enterprise edge cases

• Debate over using RFC1918 as “local”:
  • Enterprises often run massive 10/8 networks across many hops; some clients have public IPs but access RFC1918 services via VPN or site‑to‑site tunnels.
  • CGNAT and IPv6 (global addressing with ULAs/link‑local) blur local vs remote; some say there is no robust way to infer “site‑local” from an IPv6 address alone.
• Several prefer admin‑configurable policies (group policy CIDR lists), or basing decisions on origin+destination categories rather than raw address classes.

Trust in Google and standards politics

• Significant skepticism that Google’s motives are purely security‑driven; some see this as raising the bar for self‑hosted/local solutions while Google’s own tracking and ads remain untouched.
• Others counter that the threat (local probing, tracking, and exploitation) is real and that a vendor‑neutral spec any browser can adopt is still valuable despite Google’s market power.

Alternatives and current mitigations

• Users mention:
  • uBlock Origin’s “Block outsider intrusion into LAN” list, Firefox’s Behave extension, legacy IE security zones, Safari on iOS already asking per‑site for local access.
• Some advocate going further and generally clamping down on cross‑site requests, pushing aggregation back to servers instead of browsers.