Intent to Ship: Tighten secure context implementation in Workers.

[Mike West]

Contact emails

mk...@chromium.org

Spec

https://w3c.github.io/webappsec-secure-contexts/

Summary

This intent covers two minor bug fixes:

1.  SharedWorker connection is gated on contextual security. That is, secure contexts can't connect to shared workers created from non-secure contexts, and vice-versa. We actually shipped this behavior in 2015 along with secure contexts in general, but had to back it out due to breakage in Google Drive. Drive's long since fixed their dependency, Firefox is shipping the correct behavior, and the relevant metric shows~0.00001% usage.

2.  We shipped secure contexts with a "TODO(mkwst)" noting that we weren't correctly checking ancestry for Workers (e.g. a worker inside an HTTPS document that's framed by an HTTP document shouldn't be considered a secure context). Firefox is shipping the correct behavior, and it's way past time we fixed that TODO.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Demo link

1.  https://w3c-test.org/secure-contexts/shared-worker-insecure-first.https.html and https://w3c-test.org/secure-contexts/shared-worker-secure-first.https.html

2.  Last test of http://w3c-test.org/secure-contexts/basic-dedicated-worker.html.

Debuggability

`self.isSecureContext` allows developers to understand the contextual security of a given global object's execution context.

Risks

Interoperability and Compatibility

Firefox is shipping both of these behaviors, and has been for over a year. At TPAC, there were no objections from the various vendors in the room that this was the desired behavior.

Edge: Doesn't ship Shared Worker.

Firefox: Shipped

Safari: Doesn't ship Shared Worker.

Web developers: Drive fixed their dependency on the bug, I don't know of anyone else using it, and the metrics bear that out.

Ergonomics

No ergonomic concerns. Just a bug fix.

Activation

No activation concerns.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes. See the test suite at https://wpt.fyi/secure-contexts. Fixing these two bugs in Chrome will bring us into line with Firefox (with the exception of nested workers, which we don't support).

Entry on the feature dashboard

Reusing https://www.chromestatus.com/feature/6021277022158848; I don't think these bug fixes are interesting enough to justify separate features.

-mike

[Yoav Weiss]

Does #2 apply to Workers in general? (and specifically, does it apply to Service Workers?) Do we have a sense of usage for this?

--
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/CAKXHy%3Dc5RMAmd1d1UN_N1PpFerTexJdBpWF5gX33WkJo0xX2HQ%40mail.gmail.com.

[s.h.h...@gmail.com]

What about opener being not secure context? All browsers has a bug on this. Do you have plan to remove opener from secure context instead?

[Mike West]

On Mon 13. Nov 2017 at 19:17, Yoav Weiss <yo...@yoav.ws> wrote:

Does #2 apply to Workers in general? (and specifically, does it apply to Service Workers?)

#2 applies to dedicated workers most clearly (e.g. `https://very.secure/` nested in `http://non.secure/` will create a non-secure worker). It also applies to shared workers insofar as ancestors will count towards the security of the shared worker's context when #1 is fixed (and that scenario is already counted in the relevant metric). Service Workers can't be created from non-secure documents; since we're already setting the document's secure context flag correctly, I think this will be a no-op.

Do we have a sense of usage for this?

I don't. But, I'll blindly assert that it's a low-risk change. :)

We expose only very few `SecureContext` APIs to dedicated/shared workers (basically just crypto, StorageManager, and NavigationPreloadManager). `crypto.subtle.*` looks to be the most popular such APIs at ~0.4% of page views. Given that <10% of page views use workers, and ~60-70% of top-level page views are over HTTPS, the risk seems managable. Given that Firefox is shipping the same restrictions, I don't anticipate much strife.

 

-mike

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Mike West]

On Mon, Nov 13, 2017 at 11:37 AM, <s.h.h...@gmail.com> wrote:

What about opener being not secure context? All browsers has a bug on this. Do you have plan to remove opener from secure context instead?

After noting that Firefox was the only vendor that implemented that restriction, and that they couldn't implement it on everything because folks are depending on its absence in the wild, we agreed to drop it in https://github.com/w3c/webappsec-secure-contexts/commit/98f2c2634f7371bca6ffacbf73e984b22af521ab. Discussion in https://github.com/w3c/webappsec-secure-contexts/issues/42.

-mike

[Yoav Weiss]

LGTM

On Mon, Nov 13, 2017 at 8:57 PM Mike West <mk...@chromium.org> wrote:

On Mon 13. Nov 2017 at 19:17, Yoav Weiss <yo...@yoav.ws> wrote:

Does #2 apply to Workers in general? (and specifically, does it apply to Service Workers?)

#2 applies to dedicated workers most clearly (e.g. `https://very.secure/` nested in `http://non.secure/` will create a non-secure worker). It also applies to shared workers insofar as ancestors will count towards the security of the shared worker's context when #1 is fixed (and that scenario is already counted in the relevant metric). Service Workers can't be created from non-secure documents; since we're already setting the document's secure context flag correctly, I think this will be a no-op.

OK, great to see SW won't be affected.

 

Do we have a sense of usage for this?

I don't. But, I'll blindly assert that it's a low-risk change. :)

We expose only very few `SecureContext` APIs to dedicated/shared workers (basically just crypto, StorageManager, and NavigationPreloadManager). `crypto.subtle.*` looks to be the most popular such APIs at ~0.4% of page views. Given that <10% of page views use workers, and ~60-70% of top-level page views are over HTTPS, the risk seems managable. Given that Firefox is shipping the same restrictions, I don't anticipate much strife.

Makes sense. Might be good to add a counter along with landing this change so that we can keep track of breakage as it rolls out to beta (and revert temporarily if we see it's significantly higher than initially suspected). 

[Chris Harrelson]

LGTM2

--

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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEj4JdqLyGNwnNpoLsvVHhwvJSTYhxmOiNJeqQMDGUJqHA%40mail.gmail.com.

[Jochen Eisinger]

lgtm3

LGTM2

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/CACj%3DBEj4JdqLyGNwnNpoLsvVHhwvJSTYhxmOiNJeqQMDGUJqHA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-CqeOkVreOQQ_QZAvhvLNvsFrT01Cf%2BPDc-ngXz-%3D%3DeA%40mail.gmail.com.