555077 - same-origin @font-face checks (prevention of cross-site loads) uses origin of document, not of stylesheet

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[j. 'mach' wust]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2

There is this site (my.opera.com) that uses another domain for its CSS (files.myopera.com). The CSS file (http://files.myopera.com/j-mach-wust/user.css) uses @font-face for embedding fonts. Firefox will not embed that font if it is stored in the very same domain as the CSS file (see the second line of the demonstration URL that says "Other font"). Nonetheless, Firefox will embed the font if it is included as base64 within the CSS (see the third line that says "Base64 (as per peter.reisio's suggestion)").

I believe it is wrong that Firefox will not embed an @font-face font stored in the same domain as the CSS. (Alternatively, if there is a good reason not to embed a font from another domain, then it should not be possible to sneek in a font from another domain by including it in a CSS.)

Reproducible: Always

Steps to Reproduce:
1. Look at the demonstration URL.
Actual Results:  
On the second line (after "Other font:"), the font is not embedded, but on the third line it is (after "Base64 (as per peter.reisio's suggestion):").

Expected Results:  
The same font should be embedded, no matter whether it is embedded from a separate font file (as in the second line), or included within the CSS file on base64 (as on the third line). This is what browsers such as Opera or Safari do, and even Internet Explorer. (Alternatively, if there is a good reason not to embed a font from another domain, then neither should be embedded since both are from another domain.)

I have read that Firefox from 3.5 does not embed fonts (etc.) from other domains unless HTTP access control is properly specified. No HTTP access control has been specified in the demonstration URL.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Hmm.  Sounds like we're using the document's principal, not the stylesheet's, for the security check.  roc, is that on purpose?

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

If we used the stylesheet's principal, then someone could use a font cross-domain by linking to a stylesheet on that domain, right? That seems like something we don't want.

Comment 3

[j. 'mach' wust]

Does this mean the current ability for cross-site font embedding without special HTTP access control (by including the font via base64 in a cross-site CSS as in the third line of the URL) is an unintended behaviour and will be discontinued?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

No, I think that behaviour is correct and should keep working. Cross-site CSS access can't be stopped, a lot of sites depend on it ... just make sure you serve with a text/css MIME type!

Comment 5

[Boris Zbarsky [:bzbarsky]]

I'm a little surprised our font load cross-site checks considers data: URIs to be same-origin, actually...  I guess we do that "by hand"; should we check that the site and stylesheet are same-origin in that case?

Comment 6

[newton]

Here is a test case:
http://www.openclonk.org/test/

I think it is self-explanatory. Nevertheless: Both font.css load a local font. If the referenced CSS happens to be on the same subdomain as the HTML (first CSS), the font is loaded correctly. If the CSS, however, is on a different subdomain/domain, the CSS itself is loaded (of course) but the font that has been defined locally is not.
All browsers* except Firefox/Mozilla allow the loading of a font that is referenced by a remote CSS and display the TestCase correctly.

*tested with: Opera, IE, Chrome, Safari

I have the same problem as the original poster: I have the font files, CSS and referenced images on the www subdomain and want to use those on all other subdomains.
Following the logic of Robert O'Callahan as far as I understood him would mean that images that are referenced in remote CSS files should also not be loaded to be consistent with the disallowance of local font files that are referenced in remote CSS files. As with images, I think this would be absolutely unwanted behaviour.

One additional note: If the remote CSS (on 'boom' subdomain) references a font on the 'www' subdomain and the HTML which uses the CSS on 'boom' is on 'www', the font is loaded.

Code from the index.html:

<html>
<head>
<link rel="stylesheet" href="http://www.openclonk.org/test/font.css" type="text/css" />
<!-- note: this file is the same except that the font-family is EndeavourSub -->
<link rel="stylesheet" href="http://boom.openclonk.org/test/font.css" type="text/css" />    
<style>
     .this { font-family: Endeavour; }
     .other { font-family: EndeavourSub; }
</style>
<title>TestCase</title>
</head>
<body>
<div class="other">Font referenced from a remote CSS</div>
<div class="this">Font referenced from a local CSS</div>
</body>
</html>

Comment 7

[newton]

In case the issue will not be resolved for Mozilla, this is for whoever stumbles upon this issue later:

As written in this mozilla blog entry http://hacks.mozilla.org/2009/06/beautiful-fonts-with-font-face/ under "Cross-Site Font Usage", you can upload a htaccess file to add an additional header to explicitly allow a font to be loaded from another site.

<FilesMatch "\.(ttf|otf)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>

I understand the concern behind disallowing resource files to be loaded from other domains. However, in my opinion the attempt to solve this issue on the client-side by making the browser respect that header information is in vain because it depends on that all browsers respect this information. (Which they do not.)
If font files are that worthy of protection, it shouldn't be left to the browser to either only load the header information and read that he is not allowed to load it or load it completely from the start. It's ultimatively the same issue as deeplinking images. It's up to the server-side to allow or disallow the download of files.

Comment 8

[Josh Triplett]

Following up on this a while later: it seems that Firefox has become the only browser that enforces these restrictions, with all other browsers that support @font-face simply loading fonts the same way they do images, video, and any other media.  Perhaps this decision needs revisiting.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

My understanding was that IE9 and IE10 also enforce same-origin. Can you confirm that they don't?

Comment 10

[Josh Triplett]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #9)
> My understanding was that IE9 and IE10 also enforce same-origin. Can you
> confirm that they don't?

I don't know the answer to that for sure.  Some searching suggests that they enforce the embedding restrictions in the font files themselves (requiring the "Installable" bit), but I don't see anything indicating one way or another that they enforce same-origin restrictions.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Then why did you say "it seems that Firefox has become the only browser that enforces these restrictions" if you don't know about IE?

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: testcase

This testcase contains a cross-origin font reference.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Both IE9 and Firefox refuse to load the font. But Chrome (21 dev) doesn't seem to be able to load the testcase at all; I'm not sure what's up with that.

Last I heard from IE developers, IE was committed to enforcing the same-origin policy. This testcase suggests that's the case in IE9, and I don't have any data to the contrary.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Here's the right test: compare
http://people.mozilla.com/~roc/font-origin-test.html to
http://people.mozilla.org/~roc/font-origin-test.html
Same file, but the font-reference in the first page is same-origin, while the font-reference in the second page is cross-origin.

Comment 15

[Josh Triplett]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #11)
> Then why did you say "it seems that Firefox has become the only browser that
> enforces these restrictions" if you don't know about IE?

Because at the time I made that comment, I knew Chrome and Opera didn't, I knew Firefox did, and I don't tend to think of IE when evaluating standards-compliance issues.  On top of that, I'd seen recent references singling out Firefox and not mentioning any other browsers.

Comment 16

[Boris Zbarsky [:bzbarsky]]

> and I don't tend to think of IE when evaluating standards-compliance issues.

That's a bad mistake where IE9 and IE10 are concerned.

Comment 17

[Boris Zbarsky [:bzbarsky]]

And I'm not sure why you felt the need to spam multiple bugs about this....

Comment 18

[Josh Triplett]

(In reply to Boris Zbarsky (:bz) from comment #17)
> *** This bug has been marked as a duplicate of bug 604421 ***

These represent different bugs.  Bug 555077 discusses the issue that the same-origin check prevents loading a font from the same domain as the CSS file.  Bug 604421 discusses the general issue of whether @font-face should enforce a same-origin check at all.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Ah, then someone should have updated the bug summary.

In that case, wontfix per comment 2 and I'm not sure why comment 8 and following happened in this bug at all....

Comment 20

[Josh Triplett]

(In reply to Boris Zbarsky (:bz) from comment #19)
> I'm not sure why comment 8 and following happened in this bug at all....

Simply because I hadn't found bug 604421 yet; this looked like the right bug at first.  Sorry for the noise.