Intent to Prototype: Raw Sockets API

[Eric Willigers]

Contact emails

ericwi...@chromium.org

mgi...@chromium.org

gle...@chromium.org

Explainer

https://github.com/WICG/raw-sockets/blob/master/docs/explainer.md

Specification

https://github.com/WICG/raw-sockets/blob/master/docs/explainer.md

Design docs

https://docs.google.com/document/d/1Xa5nFkIWxkL3hZHvDYWPhT8sZvNeFpCUKNuqIwZHxnE/edit?usp=sharing

TAG review

https://github.com/w3ctag/design-reviews/issues/548

Summary

This is an API allowing web apps to establish direct TCP and UDP communications with network devices and systems.

Motivation

Many network devices use their own protocols over TCP or UDP, instead of using HTTPS or a WebSockets-compatible server. Like WebUSB, WebMIDI and WebBluetooth, this API allows web apps to communicate with local devices and information systems.

Risks

Interoperability and Compatibility

Other browsers may choose not to implement this API.

Gecko: 

No signal (https://github.com/mozilla/standards-positions/issues/431)

Marcos noted that this allows web apps to update firmware, and that Mozilla has not shipped similarly powerful APIs. (https://github.com/WICG/raw-sockets/pull/2)

WebKit: No signal

Web developers: Positive (https://discourse.wicg.io/t/filling-the-remaining-gap-between-websocket-webrtc-and-webtranspor/4366) Numerous potential use cases have been suggested.

Security

Various security risks and mitigations are noted in https://github.com/WICG/raw-sockets/blob/master/docs/explainer.md#security-considerations This is a powerful API. Users will have the opportunity to give web apps access to local hardware, and information systems behind organization firewalls. Mitigations are designed to ensure this cannot happen accidentally, and only with comparable friction to installing a native app.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No This feature is expected to initially ship on Chrome OS, to limit the initial audience. The implementation will not be platform-specific, except that the necessary consent dialog would need to be re-implemented for mobile platforms.

Is this feature fully tested by web-platform-tests?

No The tests have not yet been written. Some will be automated, others will be manual.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6398297361088512

This intent message was generated by Chrome Platform Status.

[Adam Rice]

Raw sockets are a specific term of art: https://stackoverflow.com/questions/24590818/what-is-the-difference-between-ipproto-ip-and-ipproto-raw. If you use this term to mean something else it is likely to lead to confusion.

Unless you plan to expose IPPROTO_RAW to JavaScript, I suggest you choose a different name, such as "native sockets".

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c403a3ae-113b-478a-9c23-2815f4680c51n%40chromium.org.

[Philipp Hancke]

how do you plan to avoid the security concerns described in / addressed by https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20#section-4.4 and https://tools.ietf.org/html/rfc7675 ?

Not allowing a website to become a reverse proxy to the internal network is pretty crucial, that was one of the reasons flash had to add policy files on the remote host, https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/XMLSocket.html still has some mention of that.

It would be ironic to piggyback on that mechanism :-)

Congestion control is also an issue, see https://bugs.chromium.org/p/chromium/issues/detail?id=280726 and the comment in

  https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/pc/webrtc_sdp.cc;l=3026;drc=9f022fa9c0074c4ad601ffb085ef0fc9ceb09674;bpv=1;bpt=1

(Harald, you forgot that as a reason to burn rtp datachannels in the intent to deprecate!)

[Eric Willigers]

The main proposed mitigations against the API being used for Denial of Service attacks are

• the user agent would show some UI, explaining that a web app (origin) is requesting permission, and allowing the user to enter the destination hostname.
• rate limiting on connection attempts

Requiring policy files on the remote host would eliminate many intended use cases, for example connecting to industrial electronic devices.

I hadn't considered bandwidth throttling. 

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/ARtkaw4e9T4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiL89V%3D%3D%3DVP_CXuNxa47WtKg_DGtr24JP7F6xnBcQmQ3Rg%40mail.gmail.com.

[Harald Alvestrand]

DoS attacks are just one area of concern.

Unauthorized inside-the-firewall connections to your HVAC, your freezer, your dishwasher and your router are a much greater concern.

Since this is indistinguishable in the code from "connecting to industrial electronic devices", I don't see how you can allow one and not the other.

Note: Most devices (pretty much all devices in the home) don't have hostnames in the DNS sense. Sometimes they have mDNS names.

(I've also filed a bug on the spec; not my only concern.)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyiQQM%3DGCuD4JJy-b%3DW%2BccBf80oS7dHSbsB%2BpeQcxVxMJVDZQ%40mail.gmail.com.

[Eric Willigers]

On Thursday, August 20, 2020 at 3:04:40 PM UTC+10, Adam Rice wrote:

Raw sockets are a specific term of art: https://stackoverflow.com/questions/24590818/what-is-the-difference-between-ipproto-ip-and-ipproto-raw. If you use this term to mean something else it is likely to lead to confusion.

Unless you plan to expose IPPROTO_RAW to JavaScript, I suggest you choose a different name, such as "native sockets".

Thanks. I have raised https://github.com/WICG/raw-sockets/issues/10

 

[Victor Vasiliev]

Have you considered using extensions to solve this problem?  I haven't found any discussion of it in the explainer.

The specific approach I had in mind is where an extension could define a custom handler for a scheme, say, "ssh", and by handling a URL of form "ssh://example.org:22/path", the extension would be granted raw TCP/UDP socket access to example.org:22.  I believe this idea was discussed before in the context of removing the native FTP implementation from Chrome, but don't quote me on that.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/66f58502-cc99-4149-936f-837a50bb8bfao%40chromium.org.

[Harald Alvestrand]

Don't extensions have raw UDP/TCP access already?

https://developer.chrome.com/apps/manifest/sockets

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAZdMaedJ2N3CPst5L20vTLUqL%2BmaYYkJjHQPovAU5RRpAEojQ%40mail.gmail.com.

[Guokai Han]

Don't extensions have raw UDP/TCP access already?

I don't discuss main topic, just reply the above question. Chrome apps support socket, but Chrome extensions don't support socket. And Chrome apps will end support in June 2022.

[Willy Nolan]

Awesome. 

I am very glad that this is finally moving towards browsers. UDP Sockets existed before browsers did, it is time to bring this functionality home. Nicely done.

[Eric Willigers]

On Wednesday, August 26, 2020 at 5:45:34 AM UTC+10 Victor Vasiliev wrote:

Have you considered using extensions to solve this problem?  I haven't found any discussion of it in the explainer.

Experience for users

Extensions cannot match the same user experience as Chrome Apps and native apps due to much more limited UI, unless a hybrid web/extension app is made (web app with cooperating extension). Hybrid web/extension apps would be more difficult for users to install, launch, and interact with than PWAs (essentially two separate apps).

Experience for authors

Socket-using code will often be one part of a larger app. With sockets available as a web API, authors can design their apps using a single technology, similar to how they previously could with Chrome Apps. As there is a single install path for users, authors don't need to worry about users having only half of the app installed and up to date like they would for hybrid web/extension apps.

Security

Extensions can have access to powerful APIs so preventing users from having to install them has security benefits. Adding sockets to the existing powers of extensions would make extensions more dangerous.  We will have a mechanism (like Safe Browsing) to block use of the API by known harmful/abusive web apps.

Overall Motivations

We believe the web platform to be a first class application platform, a realistic alternative for native apps. It aligns with the Fugu goals to close gaps in functionality for apps built on web technologies.

 

[Brad Lassey]

Can to add  this to the alternatives section?

-Brad

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/41b9de62-74df-455a-b0c7-c85a7916622an%40chromium.org.