Give user entered data: URI documents the HTTPS state 'modern'

[jwatt]

Currently:

https://fetch.spec.whatwg.org/#basic-fetch

leaves data: URI documents with the HTTPS state 'none' if their request's client is null. That means that people testing things by pasting data: URI's directly into a browser's location bar will be getting a document that is not treated as a secure context and therefore is unable to use various new APIs.

We should consider giving user entered data: URI documents the HTTPS state 'modern'.

CC: @mikewest

[mikewest]

In Gecko, 'data:' would need to inherit the state of the document that initiated the navigation. It would be strange to treat user-entered top-level data navigations differently from page-initiated top-level navigations, right?

In Chrome, we divorce 'data:' from most capabilities, and I don't think there's much interest in going the other direction on that.

[jwatt]

It would be strange to treat user-entered top-level data navigations differently from page-initiated top-level navigations, right?

It seems to make sense to me for HTTPS state. If the user enter's a data: URI that they have written and understand then it is delivered from a trusted source. If a page initiates it, then whether it is trusted or not depends on whether the initiating page is trusted.

FWIW I think there is a valid concern that users could be tricked into loading a data: either by copy and paste or by navigating to it from another application. If there is consensus that this is an issue we should act to protect users from I'd suggest UA's should block user-entered data: URIs by default with a preference to enable them. The only valid consumers are likely UA and Web developers.

In Chrome, we divorce 'data:' from most capabilities

Why is that? Are there intrinsic security issues or is that due to the issues blink has propagating origins that you've mentioned before?

[annevk]

See also w3c/webappsec-secure-contexts#26.

[annevk]

Per the resolution of the other issue it seems that the status quo is preferred.