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

Original Article ↗ Hacker News Discussion ↗

A Google-backed proposal to require browser permission before websites can contact devices on a user’s local network is drawing both praise as a long-overdue security fix and concern about breakage of legitimate tools. Commenters highlight real abuses — from tracking tricks that use localhost to potential attacks on poorly secured routers and IoT gear — but worry about permission fatigue, coarse-grained controls that grant access to an entire LAN, and the impact on workflows like OAuth callbacks, local dev servers and device dashboards. Many see the idea as necessary hardening of the web’s security model, while urging better primitives for safe local access and questioning Google’s broader influence over web standards.

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.