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

231–240 of 392 posts

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

#231

Post by numpad0 »

ale42 wrote: post #205
numpad0 wrote: post #100

Earlier quoted context omitted.

10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 are all private addresses per RFC1918 and documents superseding it(5735?). If it's like 66.249.73.128/27 or 164.13.12.34/12, those are "global" IP. 1: https://www.rfc-editor.org/rfc/rfc1918 2: https://www.rfc-editor.org/rfc/rfc5735 3: https://en.wikipedia.org/wiki/Private_network

Yes that's the point: many of our work PCs have global public IPs from something like 128.130.0.0/15 (not this actual block, but something similar), and many internal services are on 10.0.0.0/8. I'm not sure I get exactly how the proposal is addressing this. How does it know that 128.130.0.0/15 is actually internal and should be considered for content loaded from an external site?

My reading is this just adds a dialog box before browser loads RFC1918 ranges. At IP layer, a laptop with 128.130.0.123 on wlan0 should not be able to access 10.0.10.123:80, but I doubt they bother to sanity check that. Just blindly assuming all RFC1918 and only RFC1918 are local should do the job for quite a while.

btw, I've seen that kind of network. I was young, and it took me a while to realize that they DHCP assign global IPs and double NAT it. That was weird.

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

#232

Post by nothrabannosir »

shantnutiwari wrote: post #214
nothrabannosir wrote: post #174

Earlier quoted context omitted.

In iOS you can share a subset of your contacts. This is functionally equivalent and works as you described for WhatsApp.

>In iOS you can share a subset of your contacts. the problem is, the app must respect that. WhatsApp, for all the hate it gets, does . "Privacy" focused Telegram doesnt-- it wouldnt work unless I shared ALL my contacts-- when I shared a few, it kept complaining I had to share ALL

iOS generally solves this through App Store submission reviews so I’m surprised this isn’t a rule and that telegram got away with it. “Apps must not gate functionality behind receiving access to all contacts vs a subset” or something. They definitely do so for location access, for example.

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

#233

Post by blacklion »

kuschku wrote: post #101
michaelt wrote: post #97

Earlier quoted context omitted.

I don't think this proposal will stop you visiting the management UI for devices like switches and NASes on the local network. You'll be able to visit http://192.168.0.1 and it'll work just fine? This is just about blocking cross-origin requests from other websites. I probably don't want every ad network iframe being able to talk to my router's admin UI.

That's not what I'm talking about. A common example is this: 1. I visit ui.manufacturer.tld 2. I click "add device" and enter 192.168.0.230, repeating this for my other local devices. 3. The website ui.manufacturer.tld now shows me a dashboard with aggregate metrics from all my switches and routers, which it collects by fetch(...) ing data from all of them. The manufacturers site is just a static page. It stores the…

If it is truly static site/page, download it and open from local disk. And nudge vendor to release it as archive which can be downloaded and unpacked locally.

It has a multitude of benefits comparing opening it from vendor site each time:

1) It works offline.

2) It works if vendor site is down.

3) It works if vendor restrict access to it due to acquisition, making it subscription-based, discontinuation of feature "because fuck you".

4) It works if vendor goes out of business or pivot to something else.

5) It still works with YOUR devices if vendor decides to drop support for old ones.

6) It still works with YOUR versions of firmwares if vendor decides to push new ones, with features which are user-hostile (I'm looking at you, BambuLab).

7) It cannot be compromised, as copy on vendor site can be If your system is compromised, you have bigger problems than forged UI for devices. Even best of vendors have data breaches this days.

8) It cannot upload your data if vendor goes rogue.

Downsides? If you really need to update it, you need to re-download it manually. Not a big hassle, IMHO.

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

#234

Post by formerly_proven »

lyu07282 wrote: post #198
varenc wrote: post #171

Earlier quoted context omitted.

This tag: triggers a local network GET request without any CORS involvement.

Exactly you can also trigger forms for POST or DELETE etc. this is called CSRF if the endpoint doesn't validate some token in the request. CORS only protects against unauthorized xhr requests. All decades old OWASP basics really.

That highly ranked comments on HN (an audience with way above average-engineer interest in software and security) get this wrong kinda explains why these things keep being an issue.

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

#235

Post by rhdunn »

ImPostingOnHN wrote: post #73
ronsor wrote: post #3

Do note that since the removal of NPAPI plugins years ago, locally-installed software that intends to be used by one or more public websites has to run an HTTP server on localhost. It would be really annoying if this use case was made into an unreasonable hassle or killed entirely. (Alternatively, browser developers could've offered a real alternative, but it's a bit late for that now.)

> locally-installed software that intends to be used by one or more public websites has to run an HTTP server on localhost if that software runs with a pull approach, instead of a push one, the server becomes unnecessary bonus: then you won't have websites grossly probing local networks that aren't theirs (ew)

It's harder to run html and xml files with xslt by just opening them in a web browser (things like nunit test run output). To view these properly now -- to get the css, xslt, images, etc. to load -- you now typically have to run a web server at that file path.

Note: this is why the viewers for these tools will spin up a local web server.

With local LLMs and AI it is now common to have different servers for different tasks (LLM, TTS, ASR, etc.) running together where they need to communicate to be able to create services like local assistants. I don't want to have to jump through hoops of running these through SSL (including getting a verified self-signed cert.), etc. just to be able to run a local web service.

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

#236

Post by HnUser12 »

blacklion wrote: post #225
shantnutiwari wrote: post #214

Earlier quoted context omitted.

>In iOS you can share a subset of your contacts. the problem is, the app must respect that. WhatsApp, for all the hate it gets, does . "Privacy" focused Telegram doesnt-- it wouldnt work unless I shared ALL my contacts-- when I shared a few, it kept complaining I had to share ALL

Is it something specific to iOS Telegram client? On Android Telegram works with denied access to the contacts and maintains its own, completely separate, contact list (shared with desktop Telegram and other copies logged in to same account). I'm using Telegram longer than I'm using smartphone and it has completely separate contact list (as it should be). And WhatsApp cannot be used without access to contacts: it does…

Looks to me like it was a bug. Not giving access to any contacts broke the app completely but limited access works fine except for an annoying persistent in app notification.

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

#237

Post by aaronmdjones »

rerdavies wrote: post #191
aaronmdjones wrote: post #186

Earlier quoted context omitted.

fd00::/8 (within fc00::/7) is still reserved for this purpose (site-local IPv6 addressing). fc00::/8 (a network block for a registry of organisation-specific assignments for site-local use) is the idea that was abandoned. Roughly speaking, the following are analogs: 169.254/16 -> fe80::/64 (within fe80::/10) 10/8, 172.16/12, 192.168/16 -> a randomly-generated network (within fd00::/8) For example, a service I maintai…

So in my case, I guess I need to blame the unconfigurable cable router my ISP provided me with? Since there's no way to provide reservations for IPv6 addresses. :-/

Right. OpenWRT, for example, will automatically generate a random /48 within fd00::/8 to use as a ULA (unique local addressing) prefix for its LAN interfaces, and will advertise those prefixes to its clients. You can also manually configure a specific prefix instead.

e.g. Imagine the following OpenWRT setup:

ULA: fd9e:c023:bb5f::/48

(V)LAN 1: IPv6 assignment hint 1, suffix 1

(V)LAN 2: IPv6 assignment hint 2, suffix ffff

Clients on LAN 1 would be advertised the prefix fd9e:c023:bb5f:1::/64 and automatically configure addresses for themselves within it. The router itself would be reachable at fd9e:c023:bb5f:1::1.

Clients on LAN 2 would be advertised the prefix fd9e:c023:bb5f:2::/64 and automatically configure addresses for themselves within it. The router itself would be reachable at fd9e:c023:bb5f:2::ffff.

Clients on LAN 1 could communicate with clients on LAN 2 (firewall permitting) and vice versa by using these ULA addresses, without any IPv6 WAN connectivity or global-scope addresses.

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

#238

Post by kuschku »

blacklion wrote: post #233
kuschku wrote: post #101

Earlier quoted context omitted.

That's not what I'm talking about. A common example is this: 1. I visit ui.manufacturer.tld 2. I click "add device" and enter 192.168.0.230, repeating this for my other local devices. 3. The website ui.manufacturer.tld now shows me a dashboard with aggregate metrics from all my switches and routers, which it collects by fetch(...) ing data from all of them. The manufacturers site is just a static page. It stores the…

If it is truly static site/page, download it and open from local disk. And nudge vendor to release it as archive which can be downloaded and unpacked locally. It has a multitude of benefits comparing opening it from vendor site each time: 1) It works offline. 2) It works if vendor site is down. 3) It works if vendor restrict access to it due to acquisition, making it subscription-based, discontinuation of feature "be…

> If it is truly static site/page, download it and open from local disk. And nudge vendor to release it as archive which can be downloaded and unpacked locally.

Depending on the browser, file:/// is severely limited in what CORS requests are allowed.

And then there's products like Plex, where it's not a static site, but you still want a central dashboard that connects to your local Plex server directly via CORS.

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

#239

Post by kuschku »

account42 wrote: post #229
kuschku wrote: post #101

Earlier quoted context omitted.

That's not what I'm talking about. A common example is this: 1. I visit ui.manufacturer.tld 2. I click "add device" and enter 192.168.0.230, repeating this for my other local devices. 3. The website ui.manufacturer.tld now shows me a dashboard with aggregate metrics from all my switches and routers, which it collects by fetch(...) ing data from all of them. The manufacturers site is just a static page. It stores the…

That absolutely is a privacy nightmare.

How so? It's certainly better than sending all that traffic through the cloud.

While I certainly prefer stuff I can just self-host, compared to the modern cloud-only reality with WebUSB and stuff, this is a relatively clean solution.

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

#240

Post by blacklion »

kuschku wrote: post #238
blacklion wrote: post #233

Earlier quoted context omitted.

If it is truly static site/page, download it and open from local disk. And nudge vendor to release it as archive which can be downloaded and unpacked locally. It has a multitude of benefits comparing opening it from vendor site each time: 1) It works offline. 2) It works if vendor site is down. 3) It works if vendor restrict access to it due to acquisition, making it subscription-based, discontinuation of feature "be…

> If it is truly static site/page, download it and open from local disk. And nudge vendor to release it as archive which can be downloaded and unpacked locally. Depending on the browser, file:/// is severely limited in what CORS requests are allowed. And then there's products like Plex, where it's not a static site, but you still want a central dashboard that connects to your local Plex server directly via CORS.

Why local Plex which you need to install & run (it is already Server) cannot provide its own UI to browser, without 3rd party sites? It is absurd design, IMHO. I'll never allow this in my network. It looks security nightmare. Today it shows me dashboard (of what? Several my Plex servers?), tomorrow it is forced to report pirated movies to police. No, thanx.
Post reply on HN