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 don't understand how MITM could happen here? I'd assume that the server process would create the UNIX socket and then somehow open the path to the socket in the browser (or print a URL which a user can paste). If another process already has a UNIX socket at that path then surely the server process would just error?
I think using a UNIX socket instead of a TCP server for local HTTP development would be extremely useful. It solves most of the problems associated with creating a local TCP server (which everyone already does) without introducing new problems.
When listening on localhost on an unprivileged TCP port any other process could open the port first and provide a similar UI. Opening the port may even trigger the original process to chose another free port and the malicious software could take the requests from the users browser on the usual port and forward them to the new port.
Unix domain sockets support peer authentication, which is way better than anything network sockets do, and the threat that you need HTTPS to protect against doesn't exist with them.
Yeah, that's why it's better than having a HTTP server listening on localhost. And why listening on localhost is often not a good idea.
But UNIX sockets are not available on all platforms, which defeats a bit the general idea of a browser. Windows got UNIX socket support a while ago, but I don't know how well it works.
Comments
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 don't understand how MITM could happen here? I'd assume that the server process would create the UNIX socket and then somehow open the path to the socket in the browser (or print a URL which a user can paste). If another process already has a UNIX socket at that path then surely the server process would just error?
I think using a UNIX socket instead of a TCP server for local HTTP development would be extremely useful. It solves most of the problems associated with creating a local TCP server (which everyone already does) without introducing new problems.
When listening on localhost on an unprivileged TCP port any other process could open the port first and provide a similar UI. Opening the port may even trigger the original process to chose another free port and the malicious software could take the requests from the users browser on the usual port and forward them to the new port.
UNIX sockets would of course solve this issue.
Unix domain sockets support peer authentication, which is way better than anything network sockets do, and the threat that you need HTTPS to protect against doesn't exist with them.
Yeah, that's why it's better than having a HTTP server listening on localhost. And why listening on localhost is often not a good idea.
But UNIX sockets are not available on all platforms, which defeats a bit the general idea of a browser. Windows got UNIX socket support a while ago, but I don't know how well it works.
What would be wrong with browsers only supporting UNIX domain sockets on platforms where they exist?