browser development, bigger problem, workarounds

Hi :-)

I've actually started looking into the whole surrounding topic about a year before the current discussion came up. Simply because I realized, that developers usually assume opening TCP ports on locahost (127.0.0.1/8, ::1/128) and in local networks (192.168.0.0, 169.254.0.0/16, fe80::/64 and all the others) is OK without any security or just some obfuscation. For localhost that would theoretically be even true, if there wouldn't be for web sites which we now a days open not just in browsers, but in all kinds of applications. Just think of a chat app which accesses HTTP addresses from messages to generate previews. And JavaScript code, as well as embedded resource HTTP URLs (e.g. images) can open TCP connections to arbitrary IP addresses.

So to all developers + system admins (including myself 2 years ago):
localhost and your local network is absolutely NOT safe!

.

At least the Chrome developers seem to think about this for some time.
2021-08-26: https://developer.chrome.com/blog/private-network-access-...
2025-06-09: https://developer.chrome.com/blog/local-network-access?hl=en
The second link includes a screen shot of the dialogue you'll get when you enable this setting in the upcoming Chrome-138.
chrome://flags/#local-network-access-check
Some more Chromium bits about this: https://issues.chromium.org/issues/40083783

Firefox seems to have a whole list of tickets about this since decades! And now it seems they might actually start to work on it. So don't say anyone warned about this before ;-)
central ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1481298

Some of my additional notes.
What the standard says:
https://wicg.github.io/private-network-access/
https://github.com/mozilla/standards-positions/issues/143
Try out things yourself:
http://samy.pl/webscan/
https://github.com/samyk/webscan

.

But even beside actual web browsers we have all kinds of different applications running dynamically loaded, arbitrary JavaScript code from the Internet all the time and allowing it to make arbitrary HTTP connection. Do email clients run JavaScript code embedded in mails? At least email load embedded HTTP resources in mails, which might access local network resources. Just think of Thunderbird, MS-Outlook, Apple Mail and the huge list of service provider specific Android+iOS mail clients out there, supporting HTML+HTTP content.
But there's a huge bunch of other software out there, allowing HTML and maybe even JavaScript code just downloaded from the Internet to make local HTTP connections. Think of the web view in the Steam client. Or Electron based messaging apps.

Bye the way, I found this nice overview of the currently discussed problems: https://localmess.github.io/

So since knowing that, I keep much more of an eye on closing all unneeded (localhost) TCP ports on my system. I even closed the CUPS port 631, even I find the CUPS web UI quite helpful. Instead I try to use UNIX sockets instead where possible. You can even forward UNIX sockets via ssh and for example VNC software usually also supports them.
Related: https://github.com/distcc/distcc/discussions/517
Unfortunately OpenSSH in particular, usually praised for it's security, unfortunately does -X forwarding via TCP instead of using UNIX sockets. I've put a workaround here, on how to forward X11 via UNIX socket instead.
https://bugzilla.mindrot.org/show_bug.cgi?id=3695

.

As a workaround, I currently run my desktop Firefox using this command:

setsid --fork systemd-run --user --scope --slice=no_localhost_net firefox; sudo bash -c "for dst in 127.0.0.1/8 0.0.0.0/32; do /usr/sbin/iptables -A OUTPUT -p tcp --destination \$dst -m cgroup --path 'user.slice/user-${UID}.slice/user@${UID}.service/no_localhost_net.slice' -j REJECT; done"; sudo bash -c "for dst in ::1/128 ::/128; do /usr/sbin/ip6tables -A OUTPUT -p tcp --destination \$dst -m cgroup --path "user.slice/user-${UID}.slice/user@${UID}.service/no_localhost_net.slice" -j REJECT; done";

Next step will probably be, to reverse this and allow localhost + local network access only to white listed applications.

So in the end web browsers can't probably fix this for good. Instead operating systems must consider listening on localhost a privileged operation. And programs having this privilege must fulfil the full security responsibilities which come with that. If you don't want that, use UNIX sockets or any other non-network IPC mechanism.

... I'll just walk over to my balcony and do some gardening.