Hacker News new | ask | show | jobs
by Despegar 855 days ago
New Google Chrome feature blocks attacks from something websites shouldn't be able to access in the first place.
3 comments

Well have you looked at the example? Browsers should be able to a access anY IP on the LAN. If that url is not password protected and let you just change settings via URL its really not the browsers fault for supposedly "giving access". Well thinking about it, it should probably not be possible in an iframe but they would just trick you clicking a link instead. People to not secure their routers and have default passes that is the big issue here. So of course them mitigating that makes sense.

Simple never giving access would mean people can not open their router interfaces, self hosted stuff on SBCs ... so you make no sense.

> People to not secure their routers and have default passes that is the big issue here.

Is it really? ISPs in USA/Canada/France/etc give customers WiFi routers with random passwords for many years.

https://arstechnica.com/information-technology/2024/02/doj-t...

> That malware, which worked as a botnet for the Russian hacking group Fancy Bear, was removed in January 2024 under a secret court order as part of "Operation Dying Ember," according to the FBI's director. It affected routers running Ubiquiti's EdgeOS, but only those that had not changed their default administrative password

Those are not ISP given devices. While it's bad-bad, Ubiquiti is a SOHO vendor and post-purchase configuration is expected.
It's not random, it's the devices Mac address and some isp-specific value hashed together and truncated.

Don't tell anyone though since that's a pretty big security risk.

Do you have a link for the algorithm? Really interesting.
It's easy to be smart about it after the fact. Back then it was hard to tell WWW is gonna be the the standard protocol for most people to interact with the internet.
And it doesn't even block, it preflights the requests, and if the device exists and responds, it will only block if the device sets a special header? Which of course no existing devices will, so it's going to do very little good - nothing for existing IoT gear, and likely not much more for new devices, unless all those manufacturers rapidly embrace setting the new header. To me it seems like it'd be a far more obvious approach to just throw up a dialog that says "the current page wants to connect to things on your home network, does that seem reasonable to you, or should I continue to block that?"
> it will only block if the device sets a special header?

No. It will block by default. If the header is present, it will allow the request.

> just throw up a dialog that says "the current page wants to connect to things on your home network

In many (probably most) cases it is just a work site trying to connect to an internal service on your work VPN, and the warnings would get annoying very quickly.

Ah, that makes a little more sense, though it will break any legitimate uses we might have now - not sure if the Home Assistant web UI talks to local devices by IP (or maybe only via their .local?) That's probably still a good tradeoff, and I am sure if they left it all up to the user plenty of people would click 'ok' without understanding, but it'd be nice to have that as an option.