Re: [w3ctag/design-reviews] Raw Sockets API (#548)

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/548#issuecomment-697793427