Existing web platform facilities for network communication include WebSocket and WebRTC. Each mandates a specific protocol, ensures TLS, and respects the Same Origin Policy. The proposed WebTransport is similar in these respects.
Unfortunately, these APIs are impractical when the developer has no control over the endpoint. In general, you can’t create a web app that talks to servers and devices that have their own protocols incompatible with what’s available on the web, e.g. SSH, RDP or printer protocols. Another example is that you can’t create a web app that needs to talk to a legacy system. Requiring users to change or replace said system would be hard as it could be deployed on-premise by countless parties. Similarly, devices often have their own protocols, last for decades, and are expensive to replace.
Native platforms universally provide APIs to access local network devices and information systems over TCP or UDP. For example, Windows applications can use WinSock, and Android applications can use android.net. Applications depending on these facilities cannot be ported to the web platform without a rewrite of the servers they connect to (which may range from easy to impossible). Nevertheless, there are risks in adding such a powerful capability to the web platform, for users and their organizations, which need to be carefully considered.
A general API like a prior proposal from 2015 (TCP and UDP Socket API) would allow listening for incoming connections, but this may not be necessary to satisfy the main use cases, so a more restrictive API may be more feasible. The only way to know for sure would be to identify the key use cases that need to be solved.
So, we would like to first explore the use cases. Once interest is proven and the use cases are understood, a threat model will have to be defined in order to clearly identify and tackle the ensuing security and privacy challenges.
Do folks have use cases that relate to this gap? Is there interest in exploring an API proposal?