Allow core APIs to be bound directly into isolated freedom modules

[bemasc]

Starting in Firefox 37, WebSockets are available directly inside Web Workers. (Chrome has long allowed this.) XHR and RTCPeerConnection may also be available. Chrome allows Web Workers in extensions to access the whole range of extension APIs.

Rather than forcing all API access to go through the core environment, with significant performance consequences, it would be nice if modules with appropriate permission could obtain direct access to their approved APIs, on platforms where this is possible.

Based on benchmarks so far, this would dramatically improve the performance of uProxy, and make increased modularization substantially more appealing. I believe it would also provide better performance and security/isolation than the proposed channels model (#48). I expect the immediate performance improvement for uProxy would be significantly greater than enabling direct inter-module messaging (#254), because uProxy performs a great deal of core<->module communication and very little module<->module communication.

[willscott]

Makes sense. This seems doable - the providers will exist in the workers, so it's mainly a matter of switching wiring, and making sure we're squared away on maintaining references to the globals that are masked out before user code is loaded.

[bemasc]

Chrome allows Web Workers in extensions to access the whole range of extension APIs.

I appear to have been mistaken about this. Not sure how I got confused.

[willscott]

My current understanding is that we can make progress on the rtcPeerConnection, but that neither browser can directly access priviledged sockets from workers.

[bemasc]

That is also my understanding.

[bemasc]

Food for thought:
Until recently, uProxy would call core.rtcdatachannel.getBufferedAmount() after every call to send(), to see if the buffer had drained enough to keep sending. If there wasn't, we would call core.tcpsocket.pause(), and poll getBufferedAmount() until it decreased, then call resume(). However, the delay associated with waiting for getBufferedAmount() to respond turned out to be so long that a fast source server could emit many megabytes of TCP message events before we managed to pause it. To solve this, we now call core.tcpsocket.pause() after every 16 KiB of received TCP data, call getBufferedAmount(), and then call core.tcpsocket.resume() if the bufferedAmount has decreased.

If our code knew that getBufferedAmount didn't have to wait for the freedom event queue, then instead of calling pause() pre-emptively, we would call getBufferedAmount() and make a decision based on the immediate return ... especially if we could check it synchronously!

It looks to me like Chrome, Firefox, and Node all allow exposing WebRTC, WebSockets, and XHR into the context that is used for freedom modules. Could we just add an option to expose these APIs directly, un-intermediated (except maybe for adapter.js), into appropriately permissioned modules?

[willscott]

By expose directly, i think we still would do better to go through the
freedom interface for them.

Node certainly doesn't export the same API for any of these that chrome and
firefox do (it uses request instead of xhr, for instance, and doesn't have
a native WebRTC).

On Thu, May 14, 2015 at 6:06 PM, Benjamin M. Schwartz <
[email protected]> wrote:

Food for thought:
Until recently, uProxy would call core.rtcdatachannel.getBufferedAmount()
after every call to send(), to see if the buffer had drained enough to keep
sending. If there wasn't, we would call core.tcpsocket.pause(), and poll
getBufferedAmount() until it decreased, then call resume(). However, the
delay associated with waiting for getBufferedAmount() to respond turned out
to be so long that a fast source server could emit many megabytes of TCP
message events before we managed to pause it. To solve this, we now call
core.tcpsocket.pause() after every 16 KiB of received TCP data, call
getBufferedAmount(), and then call core.tcpsocket.resume() if the
bufferedAmount has decreased.

If our code knew that getBufferedAmount didn't have to wait for the
freedom event queue, then instead of calling pause() pre-emptively, we
would call getBufferedAmount() and make a decision based on the immediate
return ... especially if we could check it synchronously!

It looks to me like Chrome, Firefox, and Node all allow exposing WebRTC,
WebSockets, and XHR into the context that is used for freedom modules.
Could we just add an option to expose these APIs directly, un-intermediated
(except maybe for adapter.js), into appropriately permissioned modules?

—
Reply to this email directly or view it on GitHub
#255 (comment).

[bemasc]

node-webrtc appears to export exactly the standard W3C RTCPeerConnection API. There are emulation packages for the others that claim tight spec compliance.

I see two important advantages to un-intermediated access:

1. Third-party libraries can be reused unmodified, because we would be providing exactly the standard W3C APIs.
2. Synchronous operations are possible, which makes certain design patterns significantly more efficient.

I also see some smaller advantages: less code to maintain in Freedom, more natural APIs, less to learn for new Freedom users.

[willscott]

My only concern - maybe a bit leas for webrtc, is that this would limit the
ability to restrict communication by a 3rd party module at a host level.
On May 15, 2015 5:47 PM, "Benjamin M. Schwartz" [email protected]
wrote:

node-webrtc appears to export exactly the standard W3C RTCPeerConnection
API. There are emulation packages for the others that claim tight spec
compliance.

I see two important advantages to un-intermediated access:

1. Third-party libraries can be reused unmodified, because we would be
   providing exactly the standard W3C APIs.
2. Synchronous operations are possible, which makes certain design
   patterns significantly more efficient.

I also see some smaller advantages: less code to maintain in Freedom, more
natural APIs, less to learn for new Freedom users.

—
Reply to this email directly or view it on GitHub
#255 (comment).

[bemasc]

I agree that this kind of restriction would be nice, but I don't think it impacts the design in this case.

If we can apply these restrictions without imposing the RPC-to-core structure, then I think we are free to stick with the W3C's APIs across the board.

If we cannot, then we must maintain both options, and only offer restricted modules via the Promisified core.* APIs. As a first step, I think we would want to do this anyway for backwards compatibility.

[willscott]

This seem to also be relevant for debugging in node so that a top-level module can be inspected in the originally launched process.