Service workers, dedicated workers, and the environment settings object

The term environment below is something with its own global object: a
dedicated worker, a browsing context's Window object, a shared worker,
and a service worker.

An environment has an environment settings object (defined by HTML). I
expect us to store the CSP policy on the environment settings object.

A dedicated worker has a simple message channel with an environment.
Its API does not support association with multiple environments by
design. A dedicated worker also has its own CSP policy and a unique

Since you cannot message to a dedicated worker from anything but the
environment that created it, from a service worker's perspective it
would make sense to not treat it as a "client", but instead expose the
environment settings object of the environment the dedicated worker
was created in. (A service worker exposes these "clients" as one end
of a message channel plus appropriate metadata, depending on the
environment of the "client".)

CSP policy, Referer, and Mixed Content depend on an environment's
environment settings object. From a Fetch perspective, we therefore
want a dedicated worker's environment settings object.

Given these constraints, here are some options:

1a) We treat a dedicated worker as a "client" anyway, but you cannot
communicate with it. Perhaps we expose a property so you can get hold
of the "client" that owns the dedicated worker so you can message with
that instead.

1b) Like a, but we figure out a way to let service workers communicate
with a dedicated worker.

2) We change dedicated workers so they have knowledge of the
environment that created them. We store that on the environment
settings object. Fetch then deals with giving everyone the environment
settings object they want.

Unless we do 1b, it seems we cannot get away with exposing the creator
of a dedicated worker. Both 1a) and 2) seem reasonable at that point.



Received on Friday, 24 October 2014 11:10:24 UTC