Yes, please! It would be so much better for local apps that have a management UI at a certain port: for one, you need to find such a free port. That's right, 8000, 8008, 8080, 8888, some of those might be taken already ;).

In addition you can rely on Unix access control with the socket. Much better than granting access to all local users, such as is the case by default with e.g. Syncthing.

OpenSSH can also forward these sockets, so remote use can be safer that way and the port configuration issue is relevant here as well.

I've also hoped that NFS and its ilk would be able to transfer Unix domain sockets, but I haven't heard of a system that could do that. Then one could, in principle, just ssh /var/servers/gw over NFS!

edit: actually read the proposal and it mentions most of my points, including Syncthing :).

curl can do this: https://curl.se/libcurl/c/CURLOPT_UNIX_SOCKET_PATH.html

It's pretty useful in test suites where you don't want to open a public TCP port (even on localhost), for obvious security reasons but also because it's hard to pick an unused port without conflicting with other tests running at the same time. Example test using this: https://gitlab.com/nbdkit/nbdkit/-/blob/master/tests/test-cu...

This sounds great - and I wish UNIX namespaces were adopted more widespread for things like "local configurtion web UI".

As a workaround, (I believe, though only through a cursory web search and haven't tested) you can use network namespaces and socat to proxy traffic from Unix sockets to a private IP:port range only visible to your user - taking that part of containerization without necessarily having to execute things inside containers.

The actually interesting discussion is here: https://github.com/whatwg/url/issues/577 with the more constructive and detailed proposition starting from here: https://github.com/whatwg/url/issues/577#issuecomment-118534...

I like the idea of specifying the socket in place of the port number in the URL.

> Getting this to actually work would be a bit difficult, for very little benefit.

I wonder why an actually secure local connection to a web UI is considered to be of very little benefit. This sounds crazy to me, for all these years.

CUPS listening on a localhost port and asking you to authenticate with your username and actual password has long bothered me. (I know it’s a privileged port, I just don’t like the idea of ever typing my local password into any browser, ever.)

I haven’t seen this proposal yet in this thread: instead of convincing browser vendors to support connecting to Unix domain sockets, contrive a tiny adapter which listens on a localhost port and expects http with basic auth (and either generates a random username and password or accepts them by environment variables), prints out a url with the password like

  Hi! To connect to your service at /tmp/whatever-service.unix, tell your browser to go to
  
    http://fwahjiddbjko:derhhkiytdfbkifdx@localhost:45678/

and then the adapter accepts connections, checks the auth, and then proxies the connection to the unix socket.

You could do this with nginx really easily but you’d have to keep track of a config file for each service.

See https://stackoverflow.com/questions/17701420/bypassing-http-... for a similar idea (but that is about stripping auth, not adding it)

I use nginx for that. I would like to see more software that provides the option to listen to unix sockets. Most still won't work with unix sockets. Some prometheus exporters at least support systemd socket units.

But, Docker doesn't even, and I'm on Windows, whoever needed access control, waah waah. </s>

Unix domain sockets are great. I find it completely amazing that they are not used more widely.

Since when was it OK to open a TCP listener when you don't want to receive connections over the network? Did everyone forget about that during their Kuberenetes fling, am I too old, or what?

This would lead to a massive confused deputy vulnerability for unix domain sockets as already exists for localhost + port.

For a great example of this, see how Guile's live REPL was localhost + port... cool, only local users could access it, right? Except browsers could access localhost + port, and it turned out this was a path to being able to do arbitrary code execution in the browser https://lists.gnu.org/archive/html/guile-user/2016-10/msg000...

Switching to unix domain sockets was the recommended path, and that's only because browsers don't support them.

If you want to support unix domain sockets, you could, but it would have to be via object capability security discipline, and the poster explicitly talks about an ACL "protecting" things... it wouldn't.

Luckily this is 3 years old and hopefully will never make progress.

The WHATWG discussion (linked from OP thread) is also interesting:

https://github.com/whatwg/url/issues/577

I'm not convinced that this is a good idea for a general purpose browser.

For web based desktop applications this might be a good solution. But there it is usually done with custom IPC. I think Electron can do it with custom protocols.

Listening on localhost is usually not a great solution. It's impossible to do HTTPS right this way (without HTTPS there is a danger of a MITM attack from an unprivileged process). Also authentication is an issue then, without authentication there is a possibility of an privilege escalation.

> I would argue that the main reason it seems niche is because of the lack of browser support.

This can't be said enough times. Browser vendors should never, ever say "we're not supporting feature X because it's not popular enough, and other browsers don't support it" when lack of browser support is what's keeping it from getting popular. We'd literally never get any new features if they always used that logic.

No update in 3 years, not sure it will be implemented in foreseeable future

Trackers will be able to gain root access by fetching the user’s local Docker API socket, and by doing so provide better personalized ads. This is really good, sign me in!

I assume there are some clever gdb hacks out there to swap any http fd with another.

why do i have to be exposed to these people who don't have the slightest clue about how the computer works? i want out. i don't want to use an ecosystem that includes these people to be part of what runs on my computer. why would i want arbitrary web pages to be able to connect to all my daemons that expected that outsiders can't connect to them including stuff like X and god knows what else. it's bad enough that browsers can already connect to localhost which has already single handedly enabled hundreds of thousands of vulnerabilities in the form of "attacker's page (even with js disabled) accesses your local daemon from some 10th level nested iframe ad crap"

i want out of this community. all these little people who have zero contextual understanding always requesting and implementing these features at all costs as long as the idea exists. this is a un*x problem at the core: if a feature conceptually exists, we must implement it at all costs. and another un*x problem here is having a global namespace (tcp port numbers) that things are just exposed to everything (either localhost or the network) by default when they could have easily just used an opaqaue handle that the machine operator can copy and paste into whatever application he wants to use it (no some openauth type shit that failed to be secure for 15 years is not what i have in mind)

I personally would like to see it but I think there would need to be a solution for Windows too, since that is nearly 70% of desktop OS use vs. 20% for MacOS and 3% for Linux.[0] Otherwise it would be a lot of work for the benefit.

[0]: https://gs.statcounter.com/os-market-share/desktop/worldwide...