Cross-tab Transport Proxies

Last week, I found out about a variation of WebWorker called the SharedWorker. It's supported by Webkit browsers, but not Firefox, which is probably why I never noticed it - MDN doesn't document it, and I generally avoid tech without both moz and chrome.

This one's worth it. One of the crucial issues in Grim/Local is the security of the document. Using CSP, I stop applications from adding their own Javascript to the page. This is good, because then I can manage the document as a shared resource and enforce a zone of trust, but it's also bad, because HTML isn't expressive enough for rich, realtime server-side control. New HTML behaviors (widgets, SSEs, html-deltas) have to be added to get rich UIs, and that's a difficult process.

Shared Workers introduce the possibility of proxies which bridge between pages with different security profiles. Effectively, each page becomes a server to other pages. This means that sensitive applications can live inside of high-security tabs (high-secs) where only trusted JS is allowed, while less trusted applications can run in low-security tabs (low-secs) where they can add document javascript more freely.

The low-sec/high-sec relationship is one we already use with email. When you forget your password, you have a message delivered to the inbox tab, where you then authorize the action in the application tab. Currently, we use email to transport between these different trust zones. With cross-tab proxies, you can use Ajax to reach a high-sec.

Content Security Policies still play a key role. In the low-secs, you don't have XHR, but you can add scripts and styles from an application host. High-secs allow the XHR, but keep the document clean. The sandbox created for low-secs should funnel all of their interactions through other tabs, so that actions are still audited.

 

Grimwire still views document code as an extension to the browser/client, not as an extension to the application. Generally speaking, this is a guideline to make everything reusable and HTML-powered (using things like data-* directives, or, with components, custom elements). Relaxing the control over the document means that you can more freely extend the browser. It takes some of the pressure off the response content-types to represent all rich and realtime behaviors, and lowers the barrier to entry for Grim/Local.

I refactored Local to support SharedWorkers (and improved the web & worker APIs in the process) which puts its development at 0.4.0. I'm going to start on 0.2.0 of Grimwire to support this change to the architecture, and to support permissioning and the WebRTC transport. I'm probably going to ditch the JSON manifests of applications and try to simplify things a bit.