Firefox3.1/Web Workers Security Review

Overview

Web workers allow content javascript to take advantage of multicore CPUs and offload expensive processing tasks to background threads.

Current working spec: whatwg

Major tracking bug: bug 450448

Workers execute in a tightly controlled sandbox.
- No access to Components or other global JS components.
- Only basic JS (Math, Date, etc.), timeouts, XHR, and importScripts.
No pref dependencies yet, maybe will provide one to customize the number of OS threads allowed.
Script loading is subject to the same restrictions as on the main thread (content policies, same origin restrictions, etc.).
XHR uses the same code as the main thread.

Users control the execution of background workers by navigating away from or back to the hosting page.

Users cannot currently modify the behavior of workers except by normal mechanisms to modify JS execution, content policies, etc.
No build configuration options.
Need to tune the number of OS threads allowed per app instance.
No hidden maintenance requirements.

Gears - they're very involved with the spec work so hopefully gears API will converge.

Need to clear JS regexp statics from the context when global objects are swapped.
Crashtest infinite recursion
Assertions in the stub security manager

worker thread sandbox uses a custom security manager, not CAPS
when a page navigates what happens to worker threads?
- they are suspended in the bfcache, messages get queued
- if no cache, or evicted, they are destroyed with the page
JS contexts are single-threaded, worker threads share them. Current max 3 actual threads.
chrome (extensions) can use worker threads
haven't implemented location yet
don't plan to implement localStorage or openDatabase for now.
not implementing shared workers