Spec should explain why do we not upgrade when a request's initiator is `imageset`

[mozfreddyb]

This came up in #63: The spec makes an explicit carve-out for imageset and it's not immediately obvious why

CC @moztomer

[estark37]

I think the history here was that, back when active/passive ("blockable"/"optionally-blockable") mixed content was defined, the goal was to be as aggressive as possible with blocking mixed content. Thus the category of passive (optionally-blockable) mixed content was defined to be the types of mixed content that were really widely used and couldn't practically be blocked. Active mixed content would then be everything else. So at the time it was not feasible to block mixed img/video/audio, so those were defined as passive mixed content, and everything else was defined as active. I'm not sure if imageset already existed at that point or it came along later, but regardless, I think the intent was to treat as much as possible as active/blockable, and since mixed imageset wasn't common, it was put in the active/blockable bucket. Then when we did mixed content autoupgrading, we decided that it would be best to not try to upgrade anything that was already being blocked by browsers.

That's the history (at least my reconstruction of it), but I don't have strong opinions on whether we should change anything. We could also leave things the way they are and just add a note to the spec to explain why the carveout is there.

[annevk]

Right, that actually makes sense. Let's add a note to clarify and continue blocking there. No need to rock the boat.

[mozfreddyb]

Agreed, that makes sense. Let's just make sure there is a justification in spec.

[carlosjoan91]

I'll go ahead and send a PR adding a note that explains the background Emily mentioned