In Kazakhstan we have e-government website. This website allows users to use crypto-tokens to access government services (every citizen can get a digital certificate representing his identity).
This website used to run Java applet. This applet was signed and it could access restricted APIs to access USB device. So website talked to applet and applet talked to USB device to sign data.
After major web browsers disabled Java applets, they implemented another approach. Now user must install a software which runs a web server on 127.0.0.1. This webserver listens on a specific port and uses web socket to communicate.
So government website now uses JavaScript to connect to 127.0.0.1:12345 using websocket. And then it uses that connection to interact with USB device.
So an ability for external website to connect to 127.0.0.1 actually is essential for this use-case.
My guess is that there are plenty of other websites which use local web server to interact with locally installed software. I know at least one another such a website: Blizzard website. It runs web server in its game launcher and website can communicate with it.
PS also they have to install custom trusted certificate because browser requires wss from https and there's no easy way to get a legitimate certificate for that kind of use.
Since these use cases already require having software installed on your machine, it seems fine and safer to use a browser extension with native messaging for this:
That bypasses the entire certificate question and lets the website know it's communicating with exactly this app and not something happening to listen on the port (and vice versa, too).
... Or, depending on what you're doing, just use a real desktop app, perhaps with an embedded browser.
Yep, that might work. But that would require significantly more work to support all browsers and platforms. Currently it's just a Java application and it works independently of OS or browser.
Yes, if this is programmed badly (missing security or a security hole).
The browser connecting to the government website accesses two servers: the original one and the second local one you install yourself on your system. The local server runs natively and therefore can access the USB device. Like all servers it should be programmed such that misuse by hackers is prevented.
When JavaScript establishes websocket connection, it sends its origin URL (I don't remember exactly where, probably that's in Referer header). So local webserver can deny connections from unwanted websites.
There's no need to roll your own hardware integration for crypto tokens. Browsers have been able to do PKCS#11 client certificates from smart cards for a long time, in case WebAuthN / U2F are too modern for you.
This website used to run Java applet. This applet was signed and it could access restricted APIs to access USB device. So website talked to applet and applet talked to USB device to sign data.
After major web browsers disabled Java applets, they implemented another approach. Now user must install a software which runs a web server on 127.0.0.1. This webserver listens on a specific port and uses web socket to communicate.
So government website now uses JavaScript to connect to 127.0.0.1:12345 using websocket. And then it uses that connection to interact with USB device.
So an ability for external website to connect to 127.0.0.1 actually is essential for this use-case.
My guess is that there are plenty of other websites which use local web server to interact with locally installed software. I know at least one another such a website: Blizzard website. It runs web server in its game launcher and website can communicate with it.
PS also they have to install custom trusted certificate because browser requires wss from https and there's no easy way to get a legitimate certificate for that kind of use.