A proposal to restrict sites from accessing a users’ local network • Hacker News Board

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

#161

Post by G_o_D » Thu, Jun 05, 2025, 3:00 AM UTC

Cors doesnt stop POST request also not fetch with 'no-cors'supplied in javascript its that you cant read response that doesnt mean request is not sent by browser

Then again local app can run server with proxy that adds adds CORS headers to the proxied request and you can access any site via js fetch/xmlhttprequest interface, even extension is able to modify headers to bypass cors

Cors bypassing is just matter of editing headers whats really hard to or impossible to bypass in CSP rules,

Now facebook app itself is running such cors server proxy even without it an normal http or websocket server is enought to send metrics

Chrome already has flag to prevent locahost access still as said websocket can be used

Completely banning localhost is detrimental

Many users are using self hosted bookmarking, note app, pass managers like solutions that rely on local server

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

#162

Post by skybrian » Thu, Jun 05, 2025, 3:05 AM UTC

paxys wrote: post #71

skybrian wrote: post #36

While this will help to block many websites that have no business making local connections at all, it's still very coarse-grained. Most websites that need this permission only need to access one local server. Granting them access to everything violates the principle of least privilege. Most users don't know what's running on localhost or on their local network, so they won't understand the risk.

> Most users don't know what's running on localhost or on their local network, so they won't understand the risk. Yes, which is why they also won't understand when the browser asks if you'd like to allow the site to visit http://localhost:3146 vs http://localhost:8089 . A sensible permission message ("allow this site to access resources on your local network") is better than technical mumbo jumbo which will make them…

On a phone at least, it should be "do you want to allow website A to connect to app B."

(It's harder to do for the rest of the local network, though.)

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

#163

Post by Pxtl » Thu, Jun 05, 2025, 3:07 AM UTC

Honestly I think cross-site requests were a mistake. Tracking cookies, hacks, XSS attacks, etc.

My relationship is with your site. If you want to outsource that to some other domain, do that on your servers, not in my browser.

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

#164

Post by JdeBP » Thu, Jun 05, 2025, 3:13 AM UTC

profmonocle wrote: post #31

Assuming that RFC1918 addresses mean "local" network is wrong. It means "private". Many large enterprises use RFC1918 for private, internal web sites. One internal site I spend hours a day using has a 10.x.x.x IP address. The servers for that site are on the other side of the country and are many network hops away. It's a big company, our corporate network is very very large. A better definition of "local IP" would b…

Many years ago, before it was dropped, IP version 6 had a concept of "site local" addresses, which (if it had applied to version 4) would have encompassed the corporate intranet addresses that you are talking about. Routed within the corporate intranet; but not routed over corporate borders.

Think of this proposal's definition of "local" (always a tricky adjective in networking, and reportedly the proposers here have bikeshedded it extensively) as encompassing both Local Area Network addresses and non-LAN "site local" addresses.

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

#165

Post by emushack » Thu, Jun 05, 2025, 3:13 AM UTC

donnachangstein wrote: post #23

duskwuff wrote: post #19

Earlier quoted context omitted.

Or probing your local network for vulnerable HTTP servers, like insecure routers or web cameras. localhost is just the tip of the iceberg.

Can you define "local network"? Probably not. Most large enterprises own publicly-routable IP space for internal use. Internal doesn't mean 192.168.0.0/24. foo.corp.example.com could resolve to 9.10.11.12 and still be local. What about IPv6? It's a nonsense argument fraught with corner cases.

They define it the explainer this was originally based on: (https://github.com/WICG/private-network-access/blob/main/exp...)

Quote: We extend the RFC 1918 concept of private IP addresses to build a model of network privacy.

Concretely, there are 3 kinds of private network requests:

    public -> private
    public -> local
    private -> local

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

#166

Post by AStonesThrow » Thu, Jun 05, 2025, 3:15 AM UTC

Pxtl wrote: post #163

Honestly I think cross-site requests were a mistake. Tracking cookies, hacks, XSS attacks, etc. My relationship is with your site. If you want to outsource that to some other domain, do that on your servers, not in my browser.

Cross-site requests have been built in to the design of the WWW since the beginning. The whole idea of hyperlinking from one place to another, and amalgamating media from multiple sites into a single page, is the essence of the World Wide Web that Tim Berners-Lee conceived at CERN, based on the HyperCard stacks and Gopher and Wais services that had preceded it.

Of course it was only later that cookies and scripting and low-trust networks were introduced.

The WWW was conceived as more of a "desktop publishing" metaphor, where pages could be formatted and multimedia presentations could be made and served to the public. It was later that the browser was harnessed as a cross-platform application delivery front-end.

Also, many sites do carefully try to guard against "linking out" or letting the user escape their walled gardens without a warning or disclaimer. As much as they may rely on third-party analytics and ad servers, most web masters want the users to remain on their site, interacting with the same site, without following an external link that would end their engagement or web session.

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

#167

Post by 3eb7988a1663 » Thu, Jun 05, 2025, 3:18 AM UTC

socalgal2 wrote: post #153

I wish they'd (Apple/Micrsoft/Google/...) would do similar things for USB and Bluetooth. Lately, every app I install, wants bluetooth access to scan all my bluetooth devices. I don't want that. At most, I want the app to have to declare in their manifest some specific device IDs (short list) that their app is allowed to connect to and have the OS limit their connections to only those devices. For for example the Bose…

I am still holding out hope that eventually at least Apple will offer fake permission grants to applications. Oh, app XYZ "needs" to see my contact list to proceed? Well it gets a randomized fake list, indistinguishable from the real one. Similar with GPS.

I have been told that WhatsApp does not let you name contacts without sharing your address book back to Facebook.

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

#168

Post by [deleted] » Thu, Jun 05, 2025, 3:28 AM UTC

donnachangstein wrote: post #43

duskwuff wrote: post #32

Earlier quoted context omitted.

> Can you define "local network"? Sure - a destination is "local" if your machine has a route to that IP which isn't via a gateway. If your network is large enough that it consists of multiple routed network segments, and you don't have any ACLs between those segments, then yeah, you won't be fully protected by this browser feature. But you aren't protected right now either, so nothing's getting worse , it's just not…

> Sure - a destination is "local" if your machine has a route to that IP which isn't via a gateway. Fantastic. Well, Google doesn't agree The proposal defines it along RFC1918 address space boundaries. The spitballing back and forth in the GitHub issues about which imaginary TLDs they will or won't also consider "local" is absolutely horrifying.

[deleted]

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

#169

Post by AStonesThrow » Thu, Jun 05, 2025, 3:29 AM UTC

lilyball wrote: post #106

ale42 wrote: post #60

Earlier quoted context omitted.

The computer I use at work (and not only mine, many many of them) has a public IP address. Many internal services are on 10.0.0.0/8. How is this being taken into account?

Your computer's own IP address is completely irrelevant. What matters is the site hostname and the IP address it resolves to.

People believe that "my computer" or "my smartphone" has an Internet address, but this is a simplification of how it's really working.

The reality is that each network interface has at least one Internet address, and these should usually all be different.

An ordinary computer at home could be plugged into Ethernet and active on WiFi at the same time. The Ethernet interface may have an IPv4 address and a set of IPv6 addresses, and belong to their home LAN. The WiFi adapter and interface may have a different IPv4 address, and belongs to the same network, or some other network. The latter is called "multi-homing".

If you visit a site that reveals your "public" IP address(es), you may find that your public, routable IPv4 and/or IPv6 addresses differ from the ones actually assigned to your interfaces.

In order to be compliant with TCP/IP standards, your device always needs to respond on a "loopback" address in 127.0.0.0/8, and typically this is assigned to a "loopback" interface.

A network router does not identify with a singular IP address, but could answer to dozens, when many interface cards are installed. Linux will gladly add "alias" IPv4 addresses to most interface devices, and you'll see SLAAC or DHCPv6 working when there's a link-local and perhaps multiple routable IPv6 addresses on each interface.

The GP says that their work computer has a [public] routable IP address. But the same computer could have another interface, or even the same interface has additional addresses assigned to it, making it a member of that private 10.0.0.0/8 intranet. This detail may or may not be relevant to the services they're connecting to, in terms of authorization or presentation. It may be relevant to the network operators, but not to the end-user.

So as a rule of thumb: your device needs at least one IP address to connect to the Internet, but that address is associated with an interface rather than your device itself, and in a functional system, there are multiple addresses being used for different purposes, or held in reserve, and multiple interfaces that grant the device membership on at least one network.

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

#170

Post by dwattttt » Thu, Jun 05, 2025, 3:30 AM UTC

kccqzy wrote: post #74

parliament32 wrote: post #57

Earlier quoted context omitted.

> Your DNS responses should not change based on what network you are connected to. GeoDNS and similar are very broadly used by services you definitely use every day. Your DNS responses change all the time depending on what network you're connecting from. Further: why would I want my private hosts to be resolvable outside my networks? Of course DNS responses should change depending on what network you're on.

> but if you're inside our network perimeter and you look up their name, you get a private IP address and you have to use this IP address to talk to them In the linked article using the wrong DNS results in inaccessibility. GeoDNS is merely a performance concern. Big difference. > why would I want my private hosts Inaccessibility is different. We are talking about accessible hosts requiring different IP addresses to…

If you have two interfaces connected to two separate networks, you can absolutely have another host connected to the same two networks. That host will have a different IP for each of their interfaces, you could reach it on either, and DNS on each network should resolve to the IP it's reachable on on that network.