This is absolutely not true. As I wrote to a different reply.
For about 5 years it is possible to call localhost from https page without any warning. Localhost is a secure context, exactly that you don't need to do this.
I cannot find the docs that says that, but... it is true. You can try that yourself.
There absolutely is, it's called native messaging hosts. It allows webextensions in your browser to talk to executables installed on your local machine. The locally-installed application simply needs to install their appropriate extension in your browser.
That isn't the fault of the native messaging host transport mechanism though. I'm just saying there are transport alternatives that are more secure than the Root CA installation nonsense the apps in your submission employ.
Neither are applications doing root CA installatin nonsense a fault of communication via a local web server. HTTPS isn’t required here, but they either have this hack in place for compatibility with decade old browsers – or they simply failed to revisit it.
Just don’t do it then. Either ship something electron based (or similar) with an embedded browser and IPC communication with the bundled „backend“, or communicate via a trusted server.
Listening on localhost is a security nightmare, also because it is accessible from other user accounts on the same machine. The server probably can do some privileged tasks (otherwise you wouldn’t need it) and could be hijacked by malware.
No, really. Let's stick to the example online banking: If you need to install software to use it, why don't you just deliver an Electron (like) application, and host the whole banking application inside of the application? You get the additional benefit, that you can configure the security inside your applications browser as you wish, pin certificates to make MITM even less likely. Electron let's you ship native code too, comes with an auto updater, etc.
And there are numerous alternatives to Electron if you don't like to ship a full Chrome browser. It get's a bit more complicated then, but its possible, take a look at Tauri for example.
To be honest, I had multiple projects, where a http://localhost solution was proposed, and we found a better solution without it. It is very rarely the best thing to do.
It is possible to secure that, sure. Another possibility is MITM. Because you usually don’t have HTTPS, there is no verification of the Server possible. If the server runs on an unprivileged port >1024, any other application on the same computer (even on another user account) could hijack that port.
If you use http://localhost, you need to authenticate both server and client. It can be done, but often it is not done properly. This authentication needs to be present on every request. And that’s tricky, because you would need to track every http-tcp-connection, and ask the server for authentication in the beginning of the connection. Once you open a TCP new connection, you would need to do that again. As far as I know, you can’t do that with JavaScript inside a browser.
Another preventable mistake is, that the server somehow gets accessible not only from localhost, but gets exposed to a public network interface somehow.
So all in all a lot of possible headaches, that can be prevented by choosing a different architecture.
