Current status?

[jasnell]

What is the current status of this proposal? Is there still an intent on moving it forward?

[phoglenix]

The project is partially implemented and still intended to go ahead, but is on hold awaiting a more-secure context than is currently available. Work is happening on that front but I don't have an ETA for you, sorry.

[jasnell]

Ok. The reason I ask is that I'm currently looking at designing and implementing an overhauled, modernized socket API in Node.js with an eye towards implementing that also in Workers and potentially Deno also. It would be ideal to collaborate on a combined spec but I do have some fairly significant design differences from what's captured in this spec currently. It would definitely be ideal if we could collaborate, especially if there is intent to ship support in browsers.

[phoglenix]

Reopening just so other people can see this instead of starting new issues.

We do still intend to get this shipped eventually, but I don't really expect it to happen in 2021. If you have other feedback on the API, please do file issues about it so we can track it when we come back to this .

[yume-chan]

Can I try it now in Chromium? With some command line arguments?

[phoglenix]

I believe you can test it using the --enable-blink-features=DirectSockets --enable-features=DirectSockets --restricted-api-origins=https://www.foo.com,https://www.bar.com command-line arguments on non-managed devices.

Update: Also set cross-origin HTTP headers as mentioned by yume-chan

[yume-chan]

I figured it out.

• For Chrome before 98: only need --enable-features=DirectSockets command line arguments
• For Chrome 98 and after: also need --restricted-api-origins=https://www.example.com (openTCPSocket is visible without this, but results in Permission Denied when invoked)

For all versions, the page must also have Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp response headers.

[blackyale]

@yume-chan Did it work for you? whenever I try this in canary version I get "You are using unsupported command line flag: --restricted-api-origins...".

[yume-chan]

Did it work for you?

Yes, just tested on version 99.0.4778.0 (Official Build) canary (x86_64).

[phoglenix]

restricted-api-origins was added in M99. Before M99 it shouldn't be needed

[blackyale]

Did it work for you?

Yes, just tested on version 99.0.4778.0 (Official Build) canary (x86_64).

Tried but I can't see the proper methods in 'navigator', am I missing something?
Version 99.0.4797.0 (Official Build) canary (32-bit)

[yume-chan]

I can't see the proper methods in 'navigator'

Did you add those two headers?

[blackyale]

I can't see the proper methods in 'navigator'

Did you add those two headers?

Ok just working after adding the headers.

[komagen084]

It seems that "openTCPSocket()" not added to Navigator yet.

I use "google chrome 100.0.4860.0 (Official Build) canary （64 bit） (cohort: Clang-64) ".
And, using the "--enable-blink-features=DirectSockets --enable-features=DirectSockets --restricted-api-origins=https://hoge"
But It says

Uncaught TypeError: navigator.openTCPSocket is not a function

How can I use "openTCPSocket()"?

[phoglenix]

See yume-chan's response above

[komagen084]

Thank you for your answer.
I understood !!
I didn't understand bellow:
First I have to access to the WEB server that response with 'Cross-Origin-Opener-Policy: same-origin' and 'Cross-Origin-Embedder-Policy: require-corp' response header, before I use navigator.openTCPsocket().

[jimmywarting]

think it seems very hard to try to enable and test out this new features in chrome. can't get openTCPSocket to show up...

[enverbisevac]

this api is very useful especially working with printer port 9100 if it would be possible to work on the local intranet without any restrictions and permissions it would be really great

[yume-chan]

The requirements have changed in mid-March (not sure exact version number). Now it needs:

1. --restricted-api-origins=https://www.example.com flag
2. Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp response headers
3. Create a Web App Manifest, add "isolated_storage": true in it (https://github.com/robbiemc/pwa-isolated-storage/blob/main/explainer.md)
4. Let users install your page as an app
5. Let users restart your web app

Then navigator.openTCPSocket will come back.

[jimmywarting]

4. Let users install your page as an app
5. Let users restart your web app

forcing the user to have to install the app in order to use the service feels a tiny bit reluctant

I don't like installing PWA apps as an desktop application... all it really is, is a web site. So it feels a tiny bit pointless to have to install something when you can just bookmark it and surf to it via a simple web address... this installed PWA apps don't really give you a hole lot of benefits over what a traditional website with a bit of service worker are able to provide to you.
Asking a user to install it as and desktop app is not as frictionless.

How many PWA apps have you installed as a desktop app? me = 0
if you have created a desktop app, how many of your users have actually installed it as a desktop application vs just using the service as a simple website?

[robertsdotpm]

Just giving feedback -- I'm not an expert on browsers like you all. But I second that having to install an app kind of kills this proposal. If it's not as frictionless as the web then it won't be competitive and I believe this API could really improve the web.

There are naysayers that are saying it could be too harmful. But you can say the same thing about XSS already. A basic XSS vulnerability in a banking website can already be used to transfer funds. There are obviously impacts of having socket access, but I believe they can be mitigated.

Some suggestions:

• You could block access to TCP 80 and 443 since the browser already has AJAX.
• A HTTP header could be provided by a server to white list hosts (hopefully with good subnet masks / wildcards / patterns.) This would limit XSS to only DDoSing resources you control. I think this is a better approach than having APIs available to the client by default with no restriction. The server would choose what resources it needs and it wouldn't need a prompt from the user.
• For P2P use-cases wild card subnet should be supported. We could make this less damaging by having a black list of IPs like government and military addresses as well as allowing networks to officially black list themselves from connections (I think this is pretty reasonable.)
• Iframes -- maybe just disable the API here, too much potential for abuse.
• Eval -- maybe just disable this when the HTTP header is sent. Helps prevent advertisers doing XSS
• DNS in white list means controlling the DNS lets you control the white list. Maybe not desirable.
• There should be an option to bind the socket beforehand to an arbitrary port. There are usages for this in P2P networking -- such as TCP hole punching which is an esoteric NAT traversal technique.

Resource control:

Mozilla wrote here = mozilla/standards-positions#431.

Mozilla raised a good point about local resources. Since local addresses are relative to the network you're on specifying them in a white list could give incorrect access to your own local network resources.

I think this would be a good place to prompt for a permission dialogue. In the past, you would only allow access to such resources if they were running as 'trusted' application installed / downloaded to the host.

Discussion:

Do we consider access to local network resources to be such an insurmountable risk that we disable this completely for first release of the API? Is a dialogue box 'good enough.' Keep in mind there are many, many use-cases for local resource access. It's particularly bad because the browser is behind the NAT with full network viability -- but this is also a huge advantage for developers.

The explainer suggests having an IP entered manually in a field. This is a good idea, albeit not very user-friendly. Could allow port to be editable. Could also have a list of banners to check for. Entering IPs and such should not be required for remote connections.

Peer-to-peer:

I think P2P presents one of the most innovative and exciting uses of this API and should be a supported focus. But doing this would require extending the API to add a listen method.

• Being able to control the listen queue number here would be very useful.
• There could be a traffic priority for servers that let you set how bandwidth is used. E.g. use all available bandwidth, use LEDBAT for idle bandwidth, use N%, use absolute value.
• I think you should be able to accept whoever you like.
• I don't think we should worry about botnets. You can already use existing web technology to make a browser-based botnet. Web pages also don't have persistence (unless you're 1337.)
• We should eventually support multi-cast, too, with event listeners. Multi-cast is very important in P2P networking and service discovery use-cases.

Other thoughts:

I personally don't think we should worry about throttling the traffic of the sockets. But you could build a traffic policy into the HTTP header if you liked. There are ways to do networking that use 'idle bandwidth' or are more 'respectful' of resources (e.g. LEDBAT.) As for repeat connections -- this does seem sketchy but plenty of legitimate network tools would be making many network connections. I think it should be up to the developer to control this and we shouldn't assume bad faith on the part of the website.

In the end there is no cure for simple web attacks and social engineering. A social engineer can still make a website and do a lot more damage than flooding some traffic over the Internet. Besides -- you can already do these attacks anyway with iframes and ajax, right? So I don't really see what sense it would make limiting connection count or neutering this fledgling API.

[yume-chan]

block access to TCP 80 and 443

443 is already blocked.

limit XSS to only DDoSing resources you control

DDoS is not possible because opening sockets requires transient activation and connect frequency is already limited.

P2P use-cases

P2P is not possible because Direct Sockets doesn't provide socket server, only client.

Direct Sockets are designed for connecting to legacy system which can't be converted to Web services. P2P is already possible with WebRTC, for example there is https://github.com/webtorrent/webtorrent. WebRTC also provides hole-punching out-of-box.

Iframes

Direct Sockets in IFrames are controlled by Permissions-Policy header and are blocked by default.

DNS

Domain names resolve to local IP addresses are already blocked to mitigate DNS rebind attack.

But I second that having to install an app kind of kills this proposal.

I don't know if anyone from Chrome team is looking at this issue. So https://bugs.chromium.org/p/chromium/issues/detail?id=1206150 might be a better place to post your thoughts.

[olalonde]

Ping. Any status update? Will this spec go forward?

[phoglenix]

This work is still paused. The "more-secure context than is currently available" it was waiting on is under active development (https://chromestatus.com/feature/5146307550248960). We will probably reconsider the priority of this work once that is done.

[robertsdotpm]

I'm still watching this with great interest and do think it could radically change the web as a delivery platform.

[tomayac]

People interested in playing with the API now can see #46 (comment).