What's the scope of mixed content tainting?

[jakearchibald]

At the moment mixed content warnings are scoped to the document, but should it be wider than this?

Once I've loaded a mixed <img> I could communicate its size to other pages on the origin via BroadcastChannel. I could store this data and access it on future page loads.

In https://github.com/slightlyoff/ServiceWorker/issues/813#issuecomment-236143808 @annevk suggests an origin should become mix-tainted and all future documents should carry the mix warning. The only way to reverse this would be to clear origin storage.

[jakearchibald]

Tainting a whole origin like this sounds too severe to me FWIW.

[annevk]

My rationale is that an application's state is tainted by mixed content through various channels: load/error, 2xx/error, image width, image height, and media duration. We don't know how those channels affect the user and therefore we should warn the user about them for the duration they remain in effect. Which matches the duration of storage.

(This can get more severe if the user overrrides the default mixed content blocking (why we provide that option is unclear to me, is that still sanctioned by the standard?).)

[delapuente]

From a formal perspective, I agree with @annevk on that condition. By distinguishing the cause of the tainting we could help UX folks to deliver more valuable warnings.

[jonathanKingston]

Does the loading content type follow through to workers in browser implementations? For example are we able to tell if they are mixed display/active loaded from a worker? I personally think we should treat workers as if Upgrade-Insecure-Requests is set for any request going through them.

Would there be any concerns of doing this? It seems simpler than tainting all of an origin or tabs with workers attached. It also seems better than allowing these requests over insecure also.

The only concern I can see is if these requests can block loading as upgrading an unsupported HTTPS page would cause a timeout.

[annevk]

@jonathanKingston an HTTPS worker cannot fetch "mixed content". It also does not seem to be related to the concern listed in OP.

[jonathanKingston]

After speaking on irc we clarified that slightlyoff/ServiceWorker#813 won't ever happen and this issue is just scoped to leaking of info to the worker.

[annevk]

No, it's about leakage of insecurely obtained data anywhere, including workers, storage, cookies, etc. That's why any mixed content violation should technically last until all eTLD+1 data is removed.

[annevk]

I guess even then it could have ended up server side and affect your account more permanently...

[mikewest]

I think at this point, the goal is to kill mixed content entirely via the autoupgrade-or-block approach @estark37, et al, have suggested in MIX2. That seems like the right path forward.