840938 - Base64 embedded fonts should not be considered as mixed content when browsing over HTTPS

Status: RESOLVED WORKSFORME

(Core :: Security, defect)

Description

[Pierre Mazière]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130201065344

Steps to reproduce:

related to bug 840594, but this report is more about security policy than a technical bug.

It does not seems right to me to consider base64 encoded fonts embedded within the data uri of a CSS @font-face rule to be a "mixed content" when the page is browsed over HTTPS, and therefore blocked where security.mixed_content.block_active_content is set to true. Fonts being "active content" because they are handed off to OS libraries, is fine to me, but in the case of embedding font as base64 encoded data uri, they should not be considered as "mixed content".

These embedded fonts are not downloaded from another domain, not even downloaded from another file on the same domain: they have been embedded on purpose by the author of the page. Therefore if there is a security concern, it's more about a potentially compromised server that would host hostile content rather than a "mixed content" issue.

But I'm not a security expert: I just wanted to raise a point that prevents web page authors to use base64 encoded fonts in their CSS because of what seems to me a co-lateral damage of security.mixed_content.block_active_content=true. To the least, this option name does not reflect what it actually does. 

I'll let the security experts decide if this report is valid or not

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Pierre, please try this in Firefox Nightly. The handling of data: URLs was broken in previous releases, which is why the security.mixed_content.block_active_content preference was defaulted to false. We fixed that issue in bug 822367 or one of the related ones.

Comment 2

[Pierre Mazière]

With firefox nightly and security.mix_content.block_active_content set to true, the test case of bug 840594 is rendered as expected. Thanks for your explanation.

So this fix is not expected before release 21 right ?

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Pierre Mazière from comment #2)
> With firefox nightly and security.mix_content.block_active_content set to
> true, the test case of bug 840594 is rendered as expected. Thanks for your
> explanation.
> 
> So this fix is not expected before release 21 right ?

Right. Firefox 21 is the first release we're really going to try to "support" security.mix_content.block_active_content=true. There have been many, many improvements, thanks to :tanvi.

Comment 4

[Tanvi Vyas[:tanvi]]

This was fixed in bug https://bugzilla.mozilla.org/show_bug.cgi?id=803225 which I believe landed in FF 19.