Opaque origin for data: URL Dedicated and Shared Workers

concepts

1. Origin Isolation Demo

   Live comparison of worker origin before and after Chrome 150. Creates a data: URL worker, reports self.origin, tests whether a BroadcastChannel message reaches the page, notes worker localStorage exposure, and probes IndexedDB access — showing the transition from inherited origin to "null" (opaque).

2. Migration Patterns

   Side-by-side before/after code for the three most common patterns that break: cross-worker messaging via BroadcastChannel, shared storage access, and inline scripts. Each pattern has a live runner that compares the data: URL behavior with its Blob URL migration.

3. data: URL Worker Test

   Spins up a real worker from a data: URL and probes self.origin live. Tests whether BroadcastChannel, localStorage, and IndexedDB are accessible — all blocked for the opaque null origin Chrome 150 assigns.

4. Communication Tester

   Runs six targeted tests against a live data: URL worker: postMessage, BroadcastChannel, self.origin probe, localStorage, transferable ArrayBuffer, and a Blob URL worker for comparison. Each test shows a pass/fail badge and the observed value — making it easy to see exactly which APIs break under the null-origin rule.

5. Blob URL Converter

   Paste any worker script into the converter and get back the Blob URL pattern that makes it Chrome 150–compatible. Detects BroadcastChannel, localStorage, and indexedDB usage and warns when migration is required. Live test button creates the Blob URL worker and sends a real message so you can verify the output.

6. Security Audit Tool

   Creates a real data: URL worker and probes the four security boundaries: self.origin, BroadcastChannel, localStorage, and IndexedDB. In Chrome 150, all return null origin or throw SecurityError — demonstrating that the old attack surface is closed. Also shows the pre-150 attack pattern that made data: URL workers dangerous.

   Live worker Security audit Origin isolation

why it shipped

Workers created from data: URLs — like new Worker('data:text/javascript,...') — should logically be isolated: a self-contained blob of code with no inherent relationship to any server origin. The HTML specification says these workers must get an opaque (null) origin. But Chrome had historically made them inherit the page's origin, letting them join BroadcastChannel queues, read from localStorage, and query IndexedDB as if they were part of the page. Firefox and Safari never had this gap. Chrome 150 fixes it, completing the interoperability story. Sites that relied on the old behaviour — for example, a data: URL worker that posts to a named BroadcastChannel shared with the main thread — will need to replace the worker URL with a Blob URL constructed from the same source code. The functionality is identical; only the URL scheme changes.

references

• ChromeStatus entry
• HTML spec — Creating workers
• MDN — Worker constructor
• Chrome 150 release notes