Permission & Workers

[mingyc]

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?

[domenic]

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]

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:

1. No worker support
2. Support only in dedicated workers who have a clear ancestor document. (I.e., no shared worker ancestors.)
3. Try to figure out some way of finding the appropriate document even inside shared and service workers. E.g. WebHID seems to try to do this for service workers, but I'm not sure it works, because I don't know what "associated service worker client" means. (A service worker generally controls N clients, M < N of which will be window clients.)
4. Some compromise thing like only allow creating translator objects inside documents, but let people clone or transfer them to workers. This would be an awkward programming model for developers so I'd want to wait until we hear demand for it...
5. Wait until someone specs out permissions policy for workers in general. You could imagine a model where each service/shared worker becomes a root which can be configured with its own header, and dedicated workers inherit from and combine with their parents.

(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.