How to play with the API?

[robertsdotpm]

Hello, I'm very enthusiastic about this API and was wondering what is the current approach for getting it to run?

I did try read some discussion here: https://groups.google.com/a/chromium.org/g/blink-reviews/search?q=direct%20sockets but I can honestly say I don't understand the code or C++ well enough to follow what's being said.

Also, conservatively, when would the team expect to have something they could ship in the main Chromium? Even as a conditionally disabled feature? Very interested in this work, thank you.

[GrapeGreen]

Hi! This API is partially available in Chrome M100 under certain conditions.

• Installed PWA-s with a whitelisted origin (see chrome://flags -> Restricted API Origins)
• "isolated_storage": true declared in manifest.json
• Http policy headers present:

  Cross-Origin-Opener-Policy: same-origin
  Cross-Origin-Embedder-Policy: require-corp

• Non-managed Chrome OS (or possibly Mac/Windows, cannot guarantee though)

You may try to play with the glitch example (source). Feel free to ask me for additional details!

[robertsdotpm]

@GrapeGreen hello, I very much appreciate your information and will be following up on this. I also currently have Chromium source downloading and I'm going to see if I can understand any of that, too. Thank you.

[robertsdotpm]

Hello friends, I managed to get the experimental socket API to display. I want to say to the engineers working on this: this is cool as hell. Let me share some of the steps I took in the chance it may help others:

1. Download Google Chrome Beta.
2. Start it from the command-line with: google-chrome-beta --enable-blink-features=DirectSockets --enable-features=DirectSockets --restricted-api-origins=https://localhost:8443
3. Enter 'chrome://flags' into the web bar and hit enter. Search for restricted API origins. Ensure it has https://localhost:8443 in there.
4. Grab my attached zip code.zip; extract somewhere; in sub-folder run python3 server.py -- you may need to run python3 -m pip install sanic to get it to work.
5. Navigate to https://localhost:8443 in your browser. Export the SSL certificate to your downloads (click https, view cert, details) and then import it into chrome browser by going to ... -> settings -> security -> manage certificates -> authorities -> [import] and click all the check boxes.
6. In the top right-hand corner of the web bar you will see a weird-looking download button. Click it then click install. Close everything now and repeat step 2, navigate to https://localhost:8443 again.

If everything worked right you can now right click on the page -> inspect -> console: type navigator.openTCPSocket. If you see openTCPSocket() { [native code] } everything worked. The API docs are here: https://github.com/WICG/direct-sockets/blob/main/docs/explainer.md

(note: I broke the NTP app so the buttons don't do anything. But you can just add your own scripts to test.html and the server will display it.)

Feedback so far:

I know engineers are building out this API as we speak but I can only hope its easier to use in the future! Believe me, I understand the potential for abuse here is high -- if we had this wide open it would basically open up every network to attack. But I do think there are many good ways to limit attacks that won't cripple the API for future developers.

I will explore building some software with this and when I feel more confident -- take a look at the chrome code. I'm very enthusiastic about what you're all doing and wish you all a productive day.

[robertsdotpm]

Another quick comment: the example listed at https://direct-sockets-ntp.glitch.me/ actually has a small bug in it.

In the file 'client.js' the code follows:

...
udpSocket = await
        navigator.openUDPSocket({
          emoteAddress: host,
          remotePort: parseInt(port)
        }).catch(err => {
          displayErrorMsg(`openUDPSocket failed: ${err}`);
        });
        ...

There's a single letter missing for remoteAddress. It's not much but it's enough to break the program!

[robertsdotpm]

I wanted to see if the API was available in Chromium. Maybe thinking it wasn't was a stupid thought of mine. The process to get this working for Chromium is as follows:

1. Download developer version of chromium from: https://download-chromium.appspot.com/
2. Start it with: ./chrome --enable-blink-features=DirectSockets --enable-features=DirectSockets --restricted-api-origins=https://localhost:8443
3. Open chrome://flags and search for the restricted API -- enable it.
4. Go to the server page from my zip -- start server and install the app.
5. Restart chrome and check the restricted API is enabled -- now visit the app from 4 in the browser -- it will start the page as a 'progressive web app.'

Note: the socket functions are not under navigator in Chromium! But typing TCPSocket into inspect -> console will yield a bound function. I don't know if it's prototype is the same as Chromes.

[GrapeGreen]

Thanks for pointing me at the typo in the example -- fixed it!

Yes, the behaviour is the same in both Chrome and Chromium. The API looks more like WebSocketStream in the recent developer versions (see the newer example).

Also, you don't need to specify --enable-blink-features=... or --enable-features=... -- these will be deduced from --restricted-api-origins=... and applied accordingly.

[robertsdotpm]

@GrapeGreen thanks again for your help. Btw, I didn't notice that the glitch example website already sent the correct response headers. That's why I had made a small python server to serve it in my instructions. Does glitch.com let you set custom response headers?

[GrapeGreen]

The response headers in the example are handled by the nodejs express server (see server.js implementation).

[pixeltris]

Sorry if this isn't the best place to write this. Just tagging @cmuratori to notify him of this based on a blog post here where he seemed to miss this spec.

[xtralogic]

@GrapeGreen Getting the following error when trying to load WebAssembly in webapp under #isolated-app-origins:

Uncaught (in promise) CompileError: WebAssembly.instantiateStreaming(): Refused to compile or instantiate WebAssembly module because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "default-src 'self'"

It looks like since version 103 Chrome started applying a restrictive CSP to PWAs running under #isolated-app-origins, which is required for the direct sockets now. This CSP does not seem to have a wasm-eval directive, which is needed to instantiate WebAssembly modules.

Is it possible to add wasm-eval to the CSP so that Webassembly can be loaded?

[xtralogic]

Hello @GrapeGreen! It looks like the problem with WebAssembly I've described in my previous post was resolved.

Now we are hitting another problem. After the PWA using direct sockets is installed and restarted. It essentially stops working, instead it is showing the following error message: "direct-sockets-ntp.glitch.me is blocked. This page has been blocked by Chrome. ERR_BLOCKED_BY_CLIENT". This is easily reproducible with the sample app at https://direct-sockets-ntp.glitch.me/ on Chrome Beta 106.0.5249.55 on Windows. I don't see any relevant events in the Chrome debug log.

[olalonde]

I followed the instructions those instructions on https://direct-sockets-ntp.glitch.me:

Instructions:

Chrome build >= 106.0.5221.0
chrome://flags > Isolated App Origins > https://direct-sockets-ntp.glitch.me/ (restart after applying)
Installed PWA (restart after installing)

But I'm seeing this error when I click on "Call Direct Sockets API" button:

Did you really launch Chrome with the required flags? Check that --isolated-app-origins=https://direct-sockets-ntp.glitch.me is present!

Tested on Chrome Version 110.0.5481.100 (Official Build) (arm64)

[xtralogic]

Observing the same problem with Chrome 110.0.5481.104 (Official Build) (64-bit). The test app at https://direct-sockets-ntp.glitch.me, as well as our own app using direct sockets, do not work anymore. Last time we saw it working was on Chrome 108, I believe.

[yume-chan]

Last time I checked, on Chrome 109, the "Enable Isolated Web Apps" flag must also be turned on. It enables an extremely restricted CSP policy (no inline script and style), so basically any real App won't work.

[tomayac]

For a demo app, check out the the Telnet Client demo. It also has detailed instructions in its README.

[jimmywarting]

It feels like the access to play around with Direct socket have become increasingly more complicated to get access to and play around with... first it required some simple response headers. enabling specific browser flags. demand for https and now having to sign and deliver the hole app with web bundles and signing it with a key to deliver "Isolated Web Apps". PWA was so much more easier...