NaCL plug-in with sockets in a browser

[yaro.l...@gmail.com]

Is there any way to embed a NaCL plugin that uses TCP/UDP sockets into a web page and show it in a browser window? So far I'm able to run it either as a Chrome app or in a browser started with allow-nacl-socket-api parameter. Is there a solution? I would appreciate any ideas.

[Victor Khimenko]

On Fri, Jul 24, 2015 at 2:05 AM, <yaro.l...@gmail.com> wrote:

Is there any way to embed a NaCL plugin that uses TCP/UDP sockets into a web page and show it in a browser window?

Are you planning to write a spam-bot or something? Just half-jocking (see below).

 

So far I'm able to run it either as a Chrome app or in a browser started with allow-nacl-socket-api parameter. Is there a solution? I would appreciate any ideas.

Well, before you'll think about solutions think about the question above: if Chrome had a way to do that then what could have stopped malware authors from abusing that capability to create spam-bots, network scanners and so on?

If you have an idea how to distinguish your benign activity from malware then perhaps we could help. For example if you want to contact a web site which knows about from program and is under you control then you could use URL Loader and CORS instead of TCP/UDP sockets. But as stated problem looks undistinguishable from the "how would I write a spam-bot using NaCl" problem which is not something we plan to ever allow.

[yaro.l...@gmail.com]

Thanks for your comments! To make it clear. We need to receive video using RTSP protocol. Moreover, in addition to the protocol, we can restrict domains that will be accessed using this protocol, for example the RTSP URL should be hosted within the same domain as the page with the plug-in. I believe it's a pretty strict limitation. Do you agree?

[Victor Khimenko]

On Fri, Jul 24, 2015 at 7:26 PM, <yaro.l...@gmail.com> wrote:

Thanks for your comments! To make it clear. We need to receive video using RTSP protocol. Moreover, in addition to the protocol, we can restrict domains that will be accessed using this protocol, for example the RTSP URL should be hosted within the same domain as the page with the plug-in. I believe it's a pretty strict limitation. Do you agree?

I agree that pretty strict limitation, but it's also pretty high-level limitation: it's not clear how to implement it at the level of raw socket API.

The best way to support something like this is to make networking stack in Chrome RTSP-capable and provide service like URL Loader for RTSP. You could try that and push your suggestions via WhatWG but don't hold your breath: I'm pretty sure there will be a pushback.

More realistic short-term solution is create an RTSP-proxy as Chrome extension (with NaCl module) and publish it in Chrome Web store. It could be a relatively simple extension with RTSP support and some API which could be used by websites to show RTSP videos.

[yaro.l...@gmail.com]

The ideas with RTSP-proxy sounds interesting. My concern is that we'll get all the same limitations with sockets in a Chrome extension, won't we? Still something needs to connect with a raw TCP socket to a RTSP server.

[Victor Khimenko]

On Fri, Jul 24, 2015 at 10:13 PM, <yaro.l...@gmail.com> wrote:

The ideas with RTSP-proxy sounds interesting. My concern is that we'll get all the same limitations with sockets in a Chrome extension, won't we? Still something needs to connect with a raw TCP socket to a RTSP server.

Indeed. That "something" could be Chrome App or native app. Extensions couldn't access network:

  https://code.google.com/p/chromium/issues/detail?id=152875

[yaro.l...@gmail.com]

Thanks! I think that we'll go with the proxy approach. The question now is how to make the user experience smooth... Is it possible to "minimize" the proxy Chrome app to an icon?

[Yaroslav Lisitsyn]

Does anyone have an idea how can I establish secure websocket (WSS) connection between a Chrome app and a browser? This is required when browser is on HTTPS page and needs communication to a Chrome app at the same time. It works fine with HTTP and WS, but HTTPS requires WSS.