Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

51–60 of 392 posts

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

#51

Post by potholereseller »

AdmiralAsshat wrote: post #29

uBlock / uMatrix does this by default, I believe. I often see sites like Paypal trying to probe 127.0.0.1. For my "security", I'm sure...

It appears to not have been enabled by default on my instance of uBlock; it seems a specific filter list is used to implement this [0]; that filter was un-checked; I have no idea why. The contents of that filter list are here [1]; notice that there are exceptions for certain services, so be sure to read through the exceptions before enabling it.

[0] Filter Lists -> Privacy -> Block Outsider Intrusion into Lan

[1] https://github.com/uBlockOrigin/uAssets/blob/master/filters/...>

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

#52

Post by jay_kyburz »

grokkedit wrote: post #45
lucideer wrote: post #40

Earlier quoted context omitted.

> normal users could configure it themselves, just show a popup "this website wants to control local devices - allow/deny". MacOS currently does this (per app, not per site) & most users just click yes without a second thought. Doing it per site might create a little more apprehension, but I imagine not much.

problem is: without allowing it webUIs like synology won't work, since they require your browser to connect to the local network... as it is, it's not great

This proposal is for websites outside your network contacting inside your network. I assume local IPs will still work.

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

#54

Post by fn-mote »

ronsor wrote: post #49
michaelt wrote: post #44

Earlier quoted context omitted.

Doesn't most software just register a protocol handler with the OS? Then a website can hand the browser a zoommtg:// link, which the browser opens with zoom ? Things like Jupyter Notebooks will presumably be unaffected by this, as they're not doing any cross-origin requests. And likewise, when a command line tool wants you to log in with oauth2 and returns you to a localhost URL, it's a simple redirect not a cross-or…

That works if you want to launch an application from a website, but it doesn't work if you want to actively communicate with an application from a website.

This needs more detail to make it clear what you are wishing for that will not happen.

It seems like you're thinking of a specific application, or at least use-case. Can you elaborate?

Once you're launching an application, it seems like the application can negotiate with the external site directly if it wants.

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

#55

Post by fn-mote »

hello_computer wrote: post #39

just the fact that this comes from google is a hard pass for me. they sell so many adwords scams that they clearly do not give a damn about security. “security” from google is just another one of their trojan horses.

Don't post shallow dismissals. The same company runs Project Zero, which has a major positive security impact.

[1]: https://googleprojectzero.blogspot.com/

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

#57

Post by parliament32 »

kccqzy wrote: post #37
AStonesThrow wrote: post #11

Chris Siebenmann weighs in with thoughts on: Browers[sic] can't feasibly stop web pages from talking to private (local) IP addresses (2019) https://utcc.utoronto.ca/~cks/space/blog/web/BrowsersAndLoca...

The split horizon DNS model mentioned in that article is to me insane. Your DNS responses should not change based on what network you are connected to. It breaks so many things. For one, caching breaks because DNS caching is simplistic and is only cached with a TTL: no way to tell your OS to associate a DNS cached response to a network. I understand why some companies want this, but doing it on the DNS level is a mas…

> 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.

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

#59

Post by Wobbles42 »

donnachangstein wrote: post #12
mystifyingpoi wrote: post #10

I like this on the first glance. The idea of a random website probing arbitrary local IPs (or any IPs for that matter) with HTTP requests is insane. I wouldn't care if it breaks some enterprise apps or integrations - enterprises could reenable this "feature" via management tools, normal users could configure it themselves, just show a popup "this website wants to control local devices - allow/deny".

[flagged]

I do understand this sentiment, but isn't the tension here that security improvements by their very nature are designed to break things? Specifically the things we might consider "bad", but really that definition gets a bit squishy at the edges.

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

#60

Post by ale42 »

kccqzy wrote: post #34
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…

The article spends a lot of effort defining the words "local" and "private" here. It then says: > Note that local -> local is not a local network request So your use case won't be affected.

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?
Post reply on HN