Chrome (and apparently Microsoft Edge) are likely to add new restrictions on allowing things to talk to private network addresses (in a surprisingly broad sense). The reference for this is Feature: Restrict "private network requests" for subresources from public websites to secure contexts (via), which describes the first steps. The first steps Chrome is making is that such "private network requests" may only be made from a public context that is secure, ie from a HTTPS website instead of a HTTP one.

(As far as I can tell, a HTTP website on a private network is currently going to be able to send you to another private network, although maybe not to localhost.)

However, Chrome's initial steps are not the contemplated full version. The full specification is Private Network Access, and it goes much further than Chrome does. Although I'm not fully up on my web specification reading, section 3.1, Integration with Fetch seems to say that even explicit user navigation (by clicking on a link) would be covered by this and could be blocked under some circumstances if it was going from a public context to a more private one.

A browser change like this is a potential problem for us because of our network setup. We have a 'split horizon' DNS setup, where the same DNS name resolves to different IP addresses depending on whether you're inside or outside our network perimeter, and we also have a number of public websites that actually live in private IP address space but that are NAT'd to public IPs by our external firewall. These public websites are linked to by other places and may come up on Internet search results, but if you're inside our network perimeter and you look up their name, you get a private IP address and you have to use this IP address to talk to them. To the Private Network Access specification, a person following a link to the website (or a public website loading some resource from them) looks just like the kind of thing that should be blocked.

(I wrote about this a few years ago when I maintained that browsers couldn't feasibly stop web pages from talking to private networks. Browsers seem more willing to break things these days. Our setup also causes us problems with DNS over HTTPS, but it would be very challenging to change for reasons beyond the scope of this entry.)

While the specification has some suggestions, I'm not sure that it would allow our specific situation even if we could get all of the people with web servers that are possibly affected by this to make changes to them. I'm also not entirely convinced that the changes necessary would be completely secure; we might have to leave things more open than they really should be. If nothing else, this appears to be another Chrome decision that's going to force people to read a bunch of things, understand them, and change their webservers.

(But perhaps the risk of CSRF attacks against insecure devices on private networks or localhost is severe enough to justify such a change. I see only one side of this whole issue, not both of them.)