Direct Sockets API in Chrome 131

Interesting — the Firefox team’s response was very negative, but didn’t (in my reading) address use of the API as being part of an otherwise essentially trusted app (as opposed to being an API available to any website).

In reading their comments, I also felt the API was a bad idea. Especially when technology like Electron or Tauri exist, which can do those TCP or UDP connections. But IWA serves to displace Electron, I guess

I also think direct sockets can be helpful. (Note: I did not read the article because it does not work on my computer.)

Another use would be for extensions (rather than web pages) to implement other protocols (which is related to item 2 in your list, but different).

However, I think that many of these things shouldn't need to use a web browser at all. A web browser is a complicated software and using other software would be better if you are able to do so.

This includes ping, traceroute, etc, which can already be handled by other programs (and can be used even if you do not have a web browser installed); but these things may be useful on Chromebook, perhaps; or if you have Chrome 131 but cannot use other software for some reason.

For example, a service could be available by some other protocols (e.g. IRC), but also provide a web interface; this can then be one of the implementations of the protocol, so that if the web interface is compatible with your computer but the other provided implementations are not compatible (e.g. because you do not have a suitable operating system, or because you don't want to install extra software but you already have Chrome, etc), then it provides an additional interoperability, without needing too much additional complexity.

Handling security is necessary, although there are ways to make it securely: Ask the user first to allow it, and allow the user to configure proxies and restrictions on the use (e.g. if it can only access specific addresses or cannot access specific addresses, or to allow or disallow specific port numbers, etc). (If a SOCKS proxy with localhost can be configured, then the user can use separate software to handle this; the web browser will just need to ensure that it is possible to be configured to not block anything, in case the user is configuring it like this in order to implement their own blocking rules.)

A server's web pages should ideally include documentation as well, which allows you to find documentation and use other software (or write your own), if you do not have a compatible web browser or if you do not wish to use the web interface.

So, I think that it is helpful, although there are some considerations. (The one about documentation is not really one that the authors of web browsers could easily enforce, and is the kind of problem that many web pages already have anyways, and this can't help.)

I think a lot of people don't realize it's possible to use UDP in browsers today with WebRTC DataChannel. I have a demo of multiplayer Quake III using peer-to-peer UDP here: https://thelongestyard.link/

Direct sockets will have their uses for compatibility with existing applications, but it's possible to do almost any kind of networking you want on the web if you control both sides of the connection.