SRI: Should the about: scheme be whitelisted?

[fmarier]

In #280, @mozfreddyb asks: "should we really mandate that the about: scheme has always good integrity? It may be current practice, but I don't think we should rely on about things being from-disk content until eternity."

[devd]

I agree. we shouldn't mandate.

[mikewest]

I added this originally to deal with <iframe>, which spawns about:blank before loading whatever exists in src. Since you've dropped <iframe>, you probably don't need to care about about:.

I'd suggest something like step 5/6 from https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-origin-trustworthy to future-proof this, allowing UAs to whitelist things like chrome-extension:// resources.

[devd]

hmm .. I think that doesn't need to be whitelisted. If you specify a SRI value, then chrome-extension:// loads should also check hash. In the future, we might talk about this in the context of "require-for-all" directive where we might say "dont inherit the require directive for iframes in chrome-extension://" etc.

[annevk]

@mikewest does <iframe> or new top-level-borwsing context loading about:blank go through Fetch? Perhaps we should have a special code path for that...

[annevk]

(I think we can be fairly sure that the definition of about:blank won't change by the way, so maybe we should just not whitelist other values?)

[devd]

hmm @annevk I didn't understand your last comment. can you clarify?

[fmarier]

I think @annevk is suggesting that we whitelist about:blank only. Not the whole about: scheme.

[mozfreddyb]

Ack, I think whitelisting about:blank only sounds good to me.

[devd]

fine by me; although, to confirm my understanding, I would be curious: why would we need this in SRIv1? I can see value of this for iframes, which implicitly have an about:blank navigation.

[mozfreddyb]

right… Let's just go with #390 then.

[devd]

Yeah, I agree