Repository navigation
Permission & Workers #18
Description
Assuming we are adding permission (as described by the doc) to gate download/access to language models, what are the default behaviors for shared/dedicated/service workers when they try to use the Translation API?
- Does the API require user gesture to trigger permission prompt?
- Should dedicated workers directly inherit the access from the document?
- Can a shared/dedicated/service worker request for such permission by themself?
Activity
domenic commentedon Sep 11, 2024
This is a great question.
I would prefer not to require user activation, but we should check the precedent of other APIs to see if that's reasonable.
My recollection for workers is that dedicated workers inherit permissions directly from their parent (and, e.g., can cause a prompt in their parent's window). But in most cases shared/service workers cannot do any prompting, and either various permission-requiring APIs do not work there, or they only work if the user has previously granted permission to a window/dedicated worker.
This gets a bit more complicated in specs and in Firefox where it's possible to nest dedicated workers under shared/service workers.
Let me do more research and try to come up with clearer answers.
domenic commentedon Mar 7, 2025
I am beginning to believe we should remove workers, at least for v1.
We want to restrict access from cross-origin iframes by default. The right mechanism for that is permissions policy. Permissions policy works on documents and does not have any mechanism for propagating to workers right now. So our options are:
(You might think there's an option to only do PP checks in documents and omit them in workers. That defeats the point as then a cross-origin iframe can just create a worker to circumvent our restrictions.)
I think the choice is between 1 and 2, and I think going with 1 for now is most reasonable.
Add permissions policies and remove worker support
Add permissions policies and remove worker support
Add permissions policies and remove worker support
Add permissions policies and remove worker support
Add permissions policies and remove worker support
Add permissions policies and remove worker support
KenjiBaheux commentedon Apr 3, 2026
Reading through the challenges around propagating Permissions-Policy to workers (and the resulting choice to pull worker support for now in some drafts), I was wondering if we could explore an alternative architecture to bridge this gap.
The Motivation: The "Navigation Tax" on MPAs
Before jumping to solutions, my motivation for exploring a solution is that I fear a major architectural tension for Multi-Page Applications (MPAs). AI tasks tend to be uniquely heavy, expensive, and long-running. In an MPA, every link click is a "hard reset" that destroys the current document context, and everything that goes with it, AI tasks included...
If we don't provide a way to maintain an active task across a same-site navigation, MPA developers are forced into a corner: either waste compute by restarting tasks on every page load and hoping it finishes in time, or force a shift to Single-Page Application (SPA) architectures just to make AI UX more viable. Finding a platform-level solution to keep these tasks alive safely seems critical for web-wide adoption of AI.
A Potential Path: A "Deferred Accountability" Model via Service Workers
Since Service Workers are explicitly designed to persist and bridge the gap across same-origin navigation events, they seem like the most natural candidate to anchor long-running native tasks. Here is a rough mental sketch of how it could work:
Native Task Management: With built-in AI, the browser executes the heavy lifting (the inference) natively, rather than the execution happening directly in the worker's thread.
Handoff: The browser wakes up the SW via an event when tokens are ready, or simply to pulse-check if the task should keep running during a navigation gap / absence of, or unclear situation with, active clients.
Late-Bound Claiming: To prevent unmonitored background tasks from chewing up system resources without a UI controller, the newly loaded document must explicitly "claim" the ongoing stream, if not the whole service worker?
The Accountability Anchor: This explicit "claim" by a page provides the browser with a specific Document target. We can enforce the Permissions-Policy check at the moment of the claim, before delivering the output or allowing the generation to proceed. This satisfies the security constraint of needing a document to blame/validate, without prematurely killing the task after a link click.
I'm sure there are plenty of hairy edge cases here (like bounding the allowed output length before a claim occurs, or handling policy deltas between pages), and this might oversimplify the complexity of worker-to-document handshakes.
But I'm curious if this direction—deferring permission checks to document-bound consumption / claims—feels like a path worth exploring further?
I’m very open to hearing where this approach might fall short or violate existing platform security invariants.
michaelwasserman commentedon May 26, 2026
Reopening to track any prospective ways to support workers or similar.
Possibly blocked on w3c/webappsec-permissions-policy#207 as noted in https://w3c.github.io/webappsec-permissions-policy/#features and https://html.spec.whatwg.org/multipage/workers.html#worker-processing-model