Direct Sockets API

[ewilligers]

Saluton TAG!

I'm requesting a TAG review of Direct Sockets API (renamed from Raw Sockets API).

The API's motivation is to support creating a web app that talks to servers and devices that have their own protocols incompatible with what’s available on the web. The web app will be able to talk to a legacy system over TCP or UDP, without requiring users to change or replace that system.

• Explainer: https://github.com/WICG/direct-sockets/blob/master/docs/explainer.md
• Security and Privacy self-review: https://github.com/WICG/direct-sockets/blob/master/docs/security-privacy-self-review.md
• GitHub repo: https://github.com/WICG/direct-sockets/
• Primary contacts:
  • Eric Willigers (ewilligers), Google Inc.
  • Matt Giuca (mgiuca), Google Inc.
  • Glen Robertson (glenrob), Google Inc.
  • Marcos Cáceres (marcoscaceres), Mozilla Corporation
• Organization/project driving the design: Google Inc.
• External status/issue trackers for this feature: https://chromestatus.com/feature/6398297361088512

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done: unknown
• Existing major pieces of multi-stakeholder review or discussion of this design: github reviews
• Major unresolved issues with or opposition to this design: This API is unavoidably controversial in providing network access.
• This work is being funded by: Google Inc.

We'd prefer the TAG provide feedback as:
🐛 open issues in our GitHub repo for each point of feedback

[marcoscaceres]

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

[lknik]

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

[plinss]

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.

[plinss]

@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/direct-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.

[robertsdotpm]

@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.