Firefox3.1/Web Workers Security Review: Difference between revisions
Jump to navigation
Jump to search
Bent.mozilla (talk | contribs) |
Bent.mozilla (talk | contribs) |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 14: | Line 14: | ||
* No pref dependencies yet, maybe will provide one to customize the number of OS threads allowed. | * 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.). | * 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 | * XHR uses the same code as the main thread. | ||
== Exported APIs == | == Exported APIs == | ||
| Line 48: | Line 48: | ||
== Review comments == | == Review comments == | ||
* 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 | |||
Latest revision as of 20:09, 30 September 2008
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
Security and Privacy
- 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.
Exported APIs
Current IDL: nsIDOMThreads.idl
Module interactions
- Necko
- DOM
- Content
- XPCOM
- XPConnect
Data
- JS is the only data parsed here.
Reliability
- Users control the execution of background workers by navigating away from or back to the hosting page.
Configuration
- 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.
Relationships to other projects
- Gears - they're very involved with the spec work so hopefully gears API will converge.
Review comments
- 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