Intent to Prototype: Raw Sockets API

1806 views
Skip to first unread message

Eric Willigers

unread,
Aug 20, 2020, 12:25:32 AM8/20/20
to blink-dev
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

unread,
Aug 20, 2020, 1:04:40 AM8/20/20
to Eric Willigers, blink-dev
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

unread,
Aug 20, 2020, 1:48:11 AM8/20/20
to blink-dev
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
(Harald, you forgot that as a reason to burn rtp datachannels in the intent to deprecate!)

Eric Willigers

unread,
Aug 20, 2020, 2:07:45 AM8/20/20
to Philipp Hancke, blink-dev
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

unread,
Aug 20, 2020, 3:08:11 AM8/20/20
to Eric Willigers, Philipp Hancke, blink-dev
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.)

Eric Willigers

unread,
Aug 20, 2020, 11:01:20 PM8/20/20
to blink-dev, ericwi...@chromium.org


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

Victor Vasiliev

unread,
Aug 25, 2020, 3:45:34 PM8/25/20
to Eric Willigers, blink-dev
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.

Harald Alvestrand

unread,
Aug 25, 2020, 5:10:26 PM8/25/20
to Victor Vasiliev, Eric Willigers, blink-dev

Guokai Han

unread,
Aug 25, 2020, 6:23:32 PM8/25/20
to blink-dev, Harald Alvestrand, Eric Willigers, blink-dev, Victor Vasiliev
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

unread,
Aug 26, 2020, 7:48:53 PM8/26/20
to blink-dev, han.g...@gmail.com, Harald Alvestrand, Eric Willigers, blink-dev, Victor Vasiliev
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

unread,
Sep 18, 2020, 3:25:11 AM9/18/20
to blink-dev, Victor Vasiliev, blink-dev, 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

unread,
Sep 18, 2020, 7:53:56 AM9/18/20
to Eric Willigers, blink-dev, Victor Vasiliev
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.
Reply all
Reply to author
Forward
0 new messages