> Most users don't know what's running on localhost or on their local network, so they won't understand the risk.
Yes, which is why they also won't understand when the browser asks if you'd like to allow the site to visit http://localhost:3146 vs http://localhost:8089. A sensible permission message ("allow this site to access resources on your local network") is better than technical mumbo jumbo which will make them just click "yes" in confusion.
Either way they'll click "yes" as long as the attacker site properly primes them for it.
For instance, on the phishing site they clicked on from an email, they'll first be prompted like:
"Chase need to verify your Local Network identity to keep your account details safe. Please ensure that you click "Yes" on the following screen to confirm your identity and access account."
Yes, that's meaningless gibberish but most people would say:
• "Not sure what that means..."
• "I DO want to access my account, though."
This is true, but you can only protect people from themselves so far. At some point you gotta let them do what they want to do. I don't want to live in a world where Google decides what we are and aren't allowed to do.
In an ideal world, the browser could act as an mDNS client, discovering local services, so that it could then show the pretty name of the relevant service in the security prompt.
In the world we live in, of course, almost nothing on your average LAN has an associated mDNS service advertisement.
They don’t? Every time I install an OS I turn that stuff off, because I don’t fully understand it. Or is avahi et al another thing?
While that message has less jargon, most users still won't understand what "resources on your local network" means. They'll blindly accept it.
On a phone at least, it should be "do you want to allow website A to connect to app B."
(It's harder to do for the rest of the local network, though.)