Intent to implement and ship: isSecureContext attribute on workers

[Boris Zbarsky]

Summary: This gives workers an isSecureContext property on the global,
like we already have for windows.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1269052

Spec:
https://w3c.github.io/webappsec-secure-contexts/#monkey-patching-global-object
and https://w3c.github.io/webappsec-secure-contexts/#settings-object step 2.

Estimated or target release: Firefox 52.

Preference: None for now, but see below.

Devtools bug: None needed, I believe.

Support in other browsers: None so far. I thought Chrome had this
implemented but it doesn't seem to.

Tests: Included in the patch.

Concerns: No one else implements this so far, and it does add one
interesting requirement: it requires that shared workers not be shared
between secure and insecure contexts. Whichever one creates the shared
worker first wins; the other creation attempt throws. It _may_ be
better to have an error event here instead of an exception (akin to what
we do for origin mismatches on the worker url). It may also turn out
that not creating the shared worker in this situation creates a compat
issue... So far I haven't been able to figure out a sane way to test
whether Chrome does the shared worker thing (which it might do even
though it doesn't implement the DOM API).

-Boris

[Ben Kelly]

On Sep 23, 2016 9:15 PM, "Boris Zbarsky"

> Concerns: No one else implements this so far, and it does add one
interesting requirement: it requires that shared workers not be shared
between secure and insecure contexts. Whichever one creates the shared
worker first wins; the other creation attempt throws. It _may_ be better
to have an error event here instead of an exception (akin to what we do for
origin mismatches on the worker url). It may also turn out that not
creating the shared worker in this situation creates a compat issue... So
far I haven't been able to figure out a sane way to test whether Chrome
does the shared worker thing (which it might do even though it doesn't
implement the DOM API).

Some spec discussion for this is here btw:

https://github.com/w3c/webappsec/issues/406

To be honest I don't love the order dependent nature of this. If I had my
druthers I'd rather just restrict `new SharedWorker()` to secure contexts
completely. If you can't use the API from insecure contexts the problem
goes away.

Given some people think SharedWorker can be removed completely, it might
not even be a compat problem. (Safari removed SharedWorker and no one
noticed...)

By the same argument, though, I should probably just not worry about this
API corner case.

So looks good to me.

Ben