Currently we treat fonts as passive mixed content. They should be treated as active content, following the rule "do what every other major browser is doing." Note that we're getting to the point where active/passive distinctions no longer reflects what the content is actually capable of doing. Better terminology would be "blocked" and "not blocked." By web fonts can run arbitrary bytecode for hinting, so it really is active content per the old definition.
I think that the old definition of active content is what can run JS code in the context of the current page, thus enabling XSS for an active attacker who can can replace non-encrypted content. I'm not sure how to make sense of this proposed change. Is it really about protecting against arbitrary code execution attacks on https pages?
(In reply to comment #1) > I think that the old definition of active content is what can run JS code in > the context of the current page, thus enabling XSS for an active attacker > who can can replace non-encrypted content. > > I'm not sure how to make sense of this proposed change. Is it really about > protecting against arbitrary code execution attacks on https pages? No, it's just about blocking all mixed content we can block without breaking the web, due to the intrinsic security issues of loading any mixed content (e.g. sending your cookies in the clear when loading the resource). What Microsoft/Google/Mozilla are doing is blocking everything they think they can get away with blocking without pissing off users (to be blunt); right now that's most everything besides images, videos, and form targets. Safari is the only major browser that doesn't block any mixed content right now, and WebKit the only engine that treats fonts as "passive" rather than "active." I'd rather match what the other players are doing. The WIP standard proposal for this is http://w3c.github.io/webappsec/specs/mixedcontent/ -- it tries to avoid the passive/active terminology since nowadays we say passive/active to talk about content that is not blocked or blocked, rather than whether the content can script the page. My only security worry specific to fonts would be the bytecode, but we recently disabled that on the GTK+ port, and the attacker would just feed you the malicious bad font over an HTTP connection instead, so it doesn't matter one bit. I guess with a bad font you could deface the HTTPS page, but that'd be way harder to do than with images/videos. ....Anyway, what we do with fonts is not very important compared to my other patches in bug #140625; I'd be interested to hear your thoughts on some of those....
This is fixed by bug #142378 (thanks!). However we should add a test. I've filed bug #142413 for that.
My concern here is with the naming. If there is nothing behind the "active" name any more, why are we still using it? Or if there is something, what is it?
We should probably stop using that terminology. See bug #142469 for an example of all the confusion it has caused, where we wound up with images counted as "active" (which doesn't make sense by any definition). Would love to hear your thoughts on that bug too!