Suggestion: condition this on a web permission + CSP + CORS + explicit permissions request to provide a strong layer of security

[dead-claudia]

I was reading through #1 and https://github.com/w3ctag/design-reviews/issues/548, and I feel that the security concerns could be mostly addressed by doing the following in concert:

• Require the connection to be established from a secure browsing context.
  • This reduces the likelihood of arbitrary script injection.
• Add a CSP directive to limit what scripts can connect to, and disallow all without this header present.
  • This allows site operators to prevent XSS holes from being exploited to target arbitrary servers with random connections.
• Add a permission to limit what browsing contexts can create such connections, and disallow all without the permission explicitly declared (at least for cross-origin contexts).
  • This allows site operators to prevent loaded iframes and the like from targeting arbitrary servers with random connections.
• Require explicit user permission (similar to geolocation) to allow opening the sockets allowed per the CSP directive and permissions policy.
  • The permissions would be able to provide the list of what could open the connection and the CSP directive would be able to provide the list of where it could connect, and these two lists could be provided to the user so they could make a more informed decision on the matter, without necessarily having to know all sorts of low-level networking internals. (If anything, it'd scare non-technical users a little, especially if the domains don't look like they're from the site in question.)
  • For * and *:port, the prompt could ask if the user would like to give the site permission to search their network and connect to local devices on their network (using port whatever if such a port is given) instead, possibly with an additional snippet noting the obvious privacy ramifications. This would appear to the user to be a lot more dangerous than simply "can this website connect to anything on the internet", and so it'd be a little harder to simply socially engineer around.
  • The permissions prompt here would resolve my concerns in https://github.com/WICG/direct-sockets/issues/19#issuecomment-1072095981 as it wouldn't be fully automated. (With an explicit permissions prompt, you'd have to have control over the machine to automate it, and by that point, it'd be easier and more cost-effective to just do it directly in C or whatever.)

I won't say it would address the social engineering concerns from the design review in full (virtually anything can be socially engineered around at least in theory - just ask your average scam boss or physical pentester), but I do feel this would at least be a step in the right direction.

[robertsdotpm]

Will just say that it should also be worth considering the convenience of using this API. Often centralization occurs on websites because its more convenient than downloading a bunch of software and editing config files. If the user has to setup permission policies and approve a bunch of dialogs - that just adds even more of a barrier to using the APIs.

I personally think these new networking APIs have the potential to transform the web - but only if they are as convenient as the web itself. Any friction makes that less effective.

[dead-claudia]

Little late, but:

Will just say that it should also be worth considering the convenience of using this API. Often centralization occurs on websites because its more convenient than downloading a bunch of software and editing config files. If the user has to setup permission policies and approve a bunch of dialogs - that just adds even more of a barrier to using the APIs.

The only user-level friction I'm suggesting to have enabled by default is having a permissions prompt. This already has precedent with geolocation and push notifications, so they aren't unfamiliar with it.

And for developers, many other sensitive APIs are already restricted to secure contexts, like service workers and web crypto.

Everything else just integrates with the existing opt-in security measures.

And there are some very notable and relevant precedents for both requiring user opt-in and secure context: Web Bluetooth, which requires user opt-in for discovery, and protocol handler registration, which requires users to individually accept each registration request.

---

This reply is also a bit of a bump for this particular concern in general.