v147 · Workers · Security
Worker Feature Probe
Probes whether Document Policy constraints propagate from the main document into a Dedicated Worker. Chrome 147 enforces the same policy in workers as on the main thread — run the checks below to see which APIs are available or blocked in your browser.
Document Policy is enforced via the
Document-Policy HTTP response header on the main document. This page cannot set its own header, but the probe below checks which policy-gated capabilities are available in this browsing context and a Dedicated Worker.
Capability probe
Click to run feature checks on both the main thread and a Dedicated Worker.
Main thread
Dedicated Worker
Policy propagation rules (Chrome 147+)
| Policy feature | Main document | Dedicated worker | Shared worker |
|---|---|---|---|
js-profiling | controlled by header | inherits from creator | not inherited (Chrome 147+) |
force-load-at-top | controlled by header | inherits from creator | N/A |
oversized-images | controlled by header | inherits from creator | N/A |
sync-xhr | controlled by header | inherits from creator | inherits from creator |
| Permissions Policy features | header + allow attr | inherits from creator | inherits from creator |
Before Chrome 147, workers were a policy blind spot — a document with a restrictive policy could create a worker that bypassed it. Chrome 147 closes this gap by enforcing the same constraints in Dedicated Workers.
what the policy header looks like
Document-Policy: js-profiling
# enables JS Self-Profiling API in this document AND its dedicated workers
Document-Policy: js-profiling=?0
# disables JS Self-Profiling API in this document AND its dedicated workers
# Worker inherits automatically — no separate worker policy header needed
references
implementation reference
Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗