As an example of legitimate use, Ubiquiti routers have a web app at ubiquiti.com that opens connections to manage your local routers. It's all authenticated with cookies. It seems like a good design.
Some larger companies use public IP addresses for everyone's desktop, but they're still behind a firewall. So these are "local" in the sense of behind their firewall, despite being "publicly" routable addresses.
An attacker can create a domain name pointing to any IP, including 127.0.0.1 and 192.168.1.1. So browsers won't gain any security by looking at the domain name.
I really struggle to see why "legitimate use" that's a minority of all use cases should forbid a consensus from cordoning off a major attack surface with an affordance for that legitimate usage.
Also, legitimate services on the local network have tools like CORS and CSPs as well as standard anti-XSS and anti-CSRF techniques to use to defend themselves.
Based on history I know which group I would expect to implement first.
Certain subnets are always private [1], and thus may safely treated as “local”. But, of course, non-private addresses could also be local, but that’s less common in a non-enterprise setting.
A script from the internet should not be allowed to interface with a script from local network (localhost, local intranet e.t.c)
The browser should have strict sandboxes. This is like when you load a site over https, browsers scream at you if you load a http resource saying it's insecure.
You can have multiple IPs for a domain name, so if I set "hack.tlb.org" to include both a server I control and 192.168.1.1, I can repeatedly do fetches from "hack.tlb.org" until one of them gets your router instead of my server. And they're in the "same origin" for CORS purposes.
You log into app.plex.com, which will connect to yourserver.account.plex.local or something like that, which resolves to an IP on your LAN. Your server will then feed the web page app with data, without going via your WAN link.
So does that mean any tab I have open on my computer can try and talk to my local development mysql server and my local development web server? That's crazy. Wasn't there also an article in the past year about how a bunch of IOT devices run unsecure on LAN because they assume they are secure?
Similarly, there are legitimate reasons why I might want to access a service with an invalid SSL cert. They're rare and should be discouraged for general users.
This isn't about 'garbage software'; it's about the expectation that a local LAN is not exposed to the Internet and therefore does not need the same security controls that an Internet-facing network does.
Browsers making requests on the LAN breaks this expectation.
Before someone says "but I don't expect that", well, why do you even have a firewall? With the notable exception of Google/BeyondCorp, practically every LAN in the world expects to trust its members. Having untrusted code in browsers able to send requests on the LAN violates that expectation.
b) Excepting LAN to be always secure, or okay to keep unsecured is a terrible assumption that has been proven wrong numerous times, it is time to trash that assumption once and for all.
In general though, this isn't be a problem on proper IPv6 LANs and instead of buggy and cumbersome workarounds being built into browsers we should just switch.
This prevents LAN enumeration from random websites. This is not a big deal for most home networks, but I shudder to think of the damage one could do in a standard corporate network.
It doesn't help with routers with well-known config URLs.
Yes, I realize that this will break a bunch of stuff.
(Edit: OK, DNS rebinding mostly breaks this proposal. Let me think about this harder.)
That isn't even the issue. It's that there is nothing inherently wrong or unusual with mixing local and internet requests.
Look at IFPS -- it runs a webserver on localhost which you can request content from by using content hashes. There is nothing wrong with a website on the internet which anticipates that you to have IFPS installed and uses it to request page elements. It can even use javascript to detect that you have it and use a different (e.g. slower or more expensive) source for the content if you don't, or show a message explaining how to install it.
Or you have a company with some internal servers where some of them have public addresses (or public IPv6 addresses) while some don't, but they arbitrarily access resources on the others because they're all managed by the same people.
This isn't a browser problem. Browsers are supposed to work this way.
You need to fix the things that are broken instead of breaking the things that are working.
I assume you've already setup the relevant browser settings and extensions to enforce a user-defined CSP that blocks all further requests? If so, then great, your browser won't make any requests when you visit sites. And my browser will (apart from what I've blocked with other more selective extensions). We're both happy.