(just clarifying that I'm not an editor, just an independent interested party)

This one looks as if having rather exciting security/privacy properties.

Reviewed at our "Cork" virtual F2F, by myself, @hadleybeeman, @atanassov and @ylafon.

We have strong concerns about this API and all the associated risks to users.

While we accept the use cases, it's unclear that the proposed mitigations would be sufficient by any reasonable measure. It's extremely difficult to explain to an average user what the associated risks are in a way they can understand without requiring them to have a strong foundation in low-level internet networking and all the associated attack vectors.

The user needs for protection from abuse have to be put before the author needs for having these capabilities in the browser.

A better approach would be to expose higher-level APIs encompassing the real user needs, e.g. in order to make a web mail client that can talk directly to an IMAP server, rather than exposing a raw socket, we could have IMAP/SMTP APIs that provide the appropriate domain-specific user protections. Similarly we could have an IRC API, expose remote desktop as a media stream, etc.

We expect these APIs would still require user permissions, but since the capabilities are much more narrow, the appropriate explanation can be given to the user, e.g. "allow this web page to access your email? / send email on your behalf? / connect to the desktop of this computer?"

We also understand that a low-level socket API would enable these higher-level APIs to be polyfilled, but that could be achieved by gating the low-level APIs behind a "Dangerous-Do-Not-Use-Developer-Only" switch that could be buried 5 levels deep in UA menus rather than exposed directly to any user by a permission prompt.

@hober and I took another look at this today in our F2F and it seems we're still waiting on updates, here or in WICG/raw-sockets#1. We're going to close this; please let us know when you're ready for us to take another look and we'll reopen it.

@plinss

Disagree. "This web page is requesting access to your internal network. If you don't trust this web page you may decline. [accept] [decline]." Seems fine to me. Social engineering will always be a part of cyber attacks so I think that falls outside of our scope. It's also not feasible to have protocol-level APIs for every possible protocol in the browser (past and future.) That greatly increases attack surface more than adding a solid socket design, IMO.