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

RESOLVED WORKSFORME

Status

()

Core
Security
RESOLVED WORKSFORME
5 years ago
5 years ago

People

(Reporter: Pierre Mazière, Unassigned)

Tracking

18 Branch
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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

Updated

5 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: General → Security
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.
Blocks: 822367
(Reporter)

Comment 2

5 years ago
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 ?
(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.
No longer blocks: 822367
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Depends on: 822367
Resolution: --- → WORKSFORME

Comment 4

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

Updated

5 years ago
Depends on: 803225
No longer depends on: 822367
You need to log in before you can comment on or make changes to this bug.