1269053 - Make data: URLs secure contexts

Status: NEW

(Core :: DOM: Security, defect, P3)

Description

[Jonathan Watt [:jwatt]]

Spinning this off from bug 1162772.

We should figure out whether we're going to allow data: URIs to create a Secure Context or not. Right now it looks like Chrome will not, and the Secure Contexts spec is inconsistent. See the discussion at:

https://github.com/w3c/webappsec-secure-contexts/issues/26

Comment 1

[Anne (:annevk)]

As per https://github.com/w3c/webappsec-secure-contexts/issues/69 we should probably do this even if it creates a weird state. Happy to get a second opinion though.

Comment 2

[Jonathan Kingston [:jkt] he/him]

Are you suggesting that the Mixed Content Blocker should block the loads of data: in a SecureContext or that the loaded context should instead be considered non secure context if the load happens?

Currently these loads don't seem to go through the MCB but also load in a secure context. Oddly a data: is considered !isSecureContext but the parent context it loads into is still considered isSecureContext.

Comment 3

[Anne (:annevk)]

A data: URL dedicated worker is currently a secure context, in comment 1 I thought that maybe it should not be, but I'm having second thoughts as it's really unclear how that works together with other new features that impact fetching.

However, if as you said elsewhere data: URL nested documents are insecure contexts, there's definitely something to change here, but not entirely clear what. I suggest we wait for the standards discussion to get broader input.

Comment 4

[Daniel Veditz [:dveditz]]

Seems like we should treat data: the way we would have treated it back in the days when we inherited origins, and the way srcdoc is treated (though that's limited to the <iframe> case). That is, if the data: url was created in a secure context then we got it securely, and if it was created in an insecure context then it's insecure.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Relatedly: if a secure context does an https: load that does a 3xx to data: (which would NOT inherit origins), what should happen? Some options:

1. data: gets secure context
2. data: does not get secure context but loads
3. data: is mixed-content-blocked.

Comment 6

[Anne (:annevk)]

Ideally there's no situation where a secure context can have an insecure context child. That rules out 2.

As long as you can navigate to a data: URL I don't think 3 is worth doing, but I might be missing a subtlety.

Anyway, not sure we should do much until Chrome gets back to us at least?

Comment 7

[Anne (:annevk)]

I got this resolved (see https://github.com/w3c/webappsec-secure-contexts/issues/69#issuecomment-585780599), data: URLs can be a secure context after all.

Tests: https://github.com/web-platform-tests/wpt/pull/21781 and soon https://github.com/web-platform-tests/wpt/pull/21146 (though see bug 1614988).

Change to Secure Contexts specification: https://github.com/w3c/webappsec-secure-contexts/pull/72.

We already do the right thing for dedicated workers, just not for frames.