I agree fully with him. I don’t care what part of your job gets harder, or what software breaks if you can’t make it work without unnecessarily invading my privacy. You could tell me it’s going to shut down the internet for 6 months and I still wouldn’t care.
You’ll have to come up with a really strong defense for why this shouldn’t happen in order to convince most users.
It just means I run a persistent client on your device that is permanently connected to the mothership, instead of only when you have your browser open.
I’m so glad most people don’t truly consider software devs to be real engineers, because this is a perfect example of why that word deserves so much more respect than this field gives it.
I'm sure it will require some work, but this is the price of security. The idea that any website I visit can start pinging/exploiting some random unsecured testing web server I have running on localhost:8080 is a massive security risk.
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.
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 getting better for your specific use case.
> 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.
Not to be snarky, but that's a good example of "perfect being the enemy of good". You are totally right that there are corner cases, sure. But that doesn't stop us from tackling the low hanging fruit first. Which is, as you say, localhost and LAN (if present).
It should not even be able to communicate with the local network at all, it’s a goddamn web page. It should be restricted to just communicate with the server that hosts it and that’s it.
The whole browser is a massive security leak. What genius thought it was a good idea for the web page I visit in the morning to get the weather forecast to be able to run arbitrary code and to communicate with arbitrary hosts on my local network?
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.
