Dedicated workers loaded from a secure (HTTPS) origin yet instantiated by insecure (non-HTTPS) contexts are no longer considered secure.
This results in the following web developer facing changes inside such worker contexts:
- `self.isSecureContext` is now `false`
- `self.caches` and `self.storageFoundation` are no longer available
This aligns Blink behavior with the specification and Gecko.
Interoperability and Compatibility
Interoperability risk is negative? Gecko is already shipping this behavior. WebKit is not, because it also deviates from the specification. In general, this increases the interoperability of the web platform.
Compatibility risk is the main issue here. Usage data from the beta channel shows ~0.08% of page visits potentially affected by this change, which is surprisingly high: https://chromestatus.com/metrics/feature/timeline/popularity/4103
Those pages instantiate a worker that is incorrectly classified as secure. This means those workers have access to APIs (`self.caches` and `self.storageFoundation` being the only ones on `WorkerGlobalScope`) that they should not have access to.
Note that this overestimates the compatibility risk, since not all such workers actually rely on those APIs. In particular, since Gecko implements the spec correctly, such workers would already not work in that engine.Gecko
: No signalWeb developers
: No signalsOther signals
This change is security-positive.