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 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.
This change is security-positive.
N/A.
DevTrial on desktop | 99 |
DevTrial on android | 99 |
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9e47NxnXqARVH15WXNbFKXcjjDXur%2BfzzbKO-czO6xC9Q%40mail.gmail.com.