Closed Bug 604421 Opened 14 years ago Closed 12 years ago

Same domain policy for @font-face. really?!?

Categories

(Core :: Layout: Text and Fonts, defect)

Product:
Core
Component:
Layout: Text and Fonts
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: mikeal, Unassigned)

References

Details

Heya,

Chrome and Safari implement @font-face without a cross-domain restriction on it.

Why does Firefox require access control headers for cross-domain fonts? How is this any different than cross-domain images?

I don't see this outlined in the spec.

http://www.w3.org/TR/css3-fonts/#the-font-face-rule

-Mikeal
Whiteboard: DUPEME
(There's a whatwg thread about this, which I can't find.)
Component: General → Layout: Text
QA Contact: general → layout.fonts-and-text
It's outlined at http://dev.w3.org/csswg/css3-fonts/#same-origin-restriction , which is a more up-to-date version of the spec as I understand it.
Is the rationale for the restriction written up anywhere?

This really just describes how it can be (optionally) implemented.

Without a clear security threat I don't see why this is a good idea. It severely limits the amount of fonts that will be cached by the browser and I don't see how it's any more/less secure that using an image from another domain.
How does it limit font caching?  The serving host can provide the CORS header if it wants people to be able to use it from other domains, just as with XHR.

I would recommend addressing questions about the rationale to the CSSWG list, since very few of the group members are following this bug.
It adds another requirement for font hosts. If they don't implement it then it's not cached between domains.

Currently, the main CC licensed font archive doesn't implement these headers: http://openfontlibrary.org/files and their snippets don't work in Firefox but do work in Chrome and Safari http://openfontlibrary.org/files/fuex/279

This is the largest collection of openly licensed fonts that I know of and if they don't implement the Access Control headers for fonts I'm wondering who does?

-Mikeal
Indeed, the google font API works just fine-n-dandy.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Let's let John comment here, to make sure that we still want the restriction.  It may be that circumstances have changed, and I can't find any bug that talks about why *we* chose to have it.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
My recollection is somewhat vague, so take this with a grain of salt, but I believe the rationale for adding the restrictions was that they helped allay fears that font foundries had about the potential for font piracy, and buy-in from those font foundries was considered an important part of the new standard.
The primary reason is that font vendors want Web authors to limit use of fonts to their own sites, and Web authors can't easily and reliably do that unless we provide a same-origin restriction by default.

Note that IE9 has the same restriction as we do (so I'm told; I haven't tested).

I have contacted Dave Crossland asking him to add the Access-Control header so that fonts on openfontlibrary.org can be directly linked. They actually have a good documentation page about this:
http://openfontlibrary.org/wiki/Blocking_font_linking_from_other_websites
I don't know why they aren't already using the header...
Should we file on chrome to ask them to be consistent with us here too, if IE9 does as we believe?  They were late to the WOFF and @font-face revival party, might just have missed those discussions.
I dunno. Tab, see comment #10. Do you know if Chrome people have a position on this?
Go ahead and file on us.  I'm not sure if we have any particular reason to not do same-origin restrictions, except that I believe Apple contributed the @font-face code to Webkit originally.
jdaggett, can you take care of that? Thanks!
FWIW, openfontlibrary.org is serving Access-Control-Allow-Origin:* now.
The same-origin restriction is described in the CSS3 Fonts Editor's Draft but
the wording there doesn't require it.  The WOFF spec however explicitly requires
it for WOFF:

http://dev.w3.org/webfonts/WOFF/spec/#Introduction
At least a warning should appear in the console. IT TOOK ME HOURS TO FIND OUT WHY IT'S NOT WORKING!
roc, jdaggett, could one of you briefly outline how you do CORS on fonts here?  I filed a bug on us to do SOR, but Maciej is pushing back, and in IRC conversation objected on the basis that it's not obvious how to do CORS correctly here.
Sorry, more specifics.  Maciej is objecting because it's not obvious how to do CORS correctly here if you're only applying SOR to WOFF, but not other types of fonts.

bz tells me that you guys just SOR everything piping through @font-face, so that answers that question.  Never mind, I guess?  I need to do more digging to find out what the objection is on Maciej's side over SOR'ing everything.
Just to follow up here, Anne from Opera has proposed implementing a
'From-Origin' header, a HTTP response header that would allow sites to
explicitly restrict the loading of resources to pages originating on the
same site:

  http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0710.html

Anne's idea is that 'From-Origin' would allow authors to restrict certain
resources to same site only, but that the default in the absence of these
headers would be the same as images, script, they would be unrestricted.

There's a larger discussion here of what "new" resource types should
default to, whether they should simply default to the same unrestricted
linking allowed for images and script or whether they should be restricted
by default with the ability to relax via CORS, as is done with fonts
in Firefox.

Both roc and Anne have written blog posts discussing this:

  http://weblogs.mozillazine.org/roc/archives/2011/02/distinguishing.html
  http://annevankesteren.nl/2011/02/web-platform-consistency

Given that there's no "bug" in our current implementation and there's been
no real agreement at a standards level to alter this behavior, I think we
should mark this bug as INVALID.  If a change is made in the appropriate
specs that requires a change, we can log new bugs at that point.
At this point, Firefox's behavior differs significantly from other browsers, and web authors consider it a deficiency in Firefox.  See http://collectiveidea.com/blog/archives/2012/07/05/the-font-face-firefox-fiasco/ for a recent example, which also points out the inability to set up CORS on standard hosting sites.

That other browsers have intentionally not implemented this seems like a good reason to re-evaluate whether Firefox's implementation of this optional part of the specification actually benefits users and web authors.
Status: REOPENED → NEW
According to http://dev.w3.org/csswg/css3-fonts/#same-origin-restriction, it's not an "optional part of the specification"; it's a required part of CSS3 Fonts. Maybe you should be asking the other browser vendors about their plans for CSS3 Fonts conformance.

(I thought I'd read somewhere that IE9 also implements the same-origin restriction, but have not tested this personally.)
(In reply to Jonathan Kew (:jfkthame) from comment #23)
> According to http://dev.w3.org/csswg/css3-fonts/#same-origin-restriction,
> it's not an "optional part of the specification"; it's a required part of
> CSS3 Fonts.

I stand corrected; thank you.  Also, ugh.

> Maybe you should be asking the other browser vendors about their
> plans for CSS3 Fonts conformance.

I'd rather ask Mozilla about their plans for rejecting that part of CSS3 Fonts and doing what other browsers do.

It wouldn't be the first time that Mozilla chose sanity over a misguided standard.

> (I thought I'd read somewhere that IE9 also implements the same-origin
> restriction, but have not tested this personally.)

As far as I can tell, IE9 implements an entirely different policy: it requires that the font file itself have its embedding permission bits set to "Installable".
(In reply to Josh Triplett from comment #24)
> I'd rather ask Mozilla about their plans for rejecting that part of CSS3
> Fonts and doing what other browsers do.
> 
> It wouldn't be the first time that Mozilla chose sanity over a misguided
> standard.

This was resolved last fall at the W3C TPAC meeting.  The same-origin restriction is a normative requirement.

> > (I thought I'd read somewhere that IE9 also implements the same-origin
> > restriction, but have not tested this personally.)
> 
> As far as I can tell, IE9 implements an entirely different policy: it
> requires that the font file itself have its embedding permission bits set to
> "Installable".

IE9/IE10 also implements the same-origin restriction.  When loading plain ttf files they also sniff the embedding bits and allow the load if the "installable" bit is set.  This is not part of CSS3 Fonts nor will Mozilla implement this restriction.

If you want to argue the case against the same-origin restriction you should start a discussion on www-style.  There have been lots of discussions about this there and the resolution was to adopt the same-origin restriction.
Status: NEW → RESOLVED
Closed: 14 years ago → 12 years ago
Resolution: --- → INVALID
I understand the process for getting the standard changed.  I had hoped to start out by getting some consensus from Mozilla's side that the relevant bit of the standard had more than a little brain damage.  Where would be the appropriate place to start *that* discussion?

Mozilla has never had a policy of adhering to standards at all costs, above the goal of building a sane browser that serves its users well.  Thus, I would hope that some discussion could occur on Mozilla's side without getting immediately cut off by "the standard says we must, go away".
(In reply to Josh Triplett from comment #26)
> I understand the process for getting the standard changed.  I had hoped to
> start out by getting some consensus from Mozilla's side that the relevant
> bit of the standard had more than a little brain damage.  Where would be the
> appropriate place to start *that* discussion?

On one of the Mozilla mailing lists (e.g. dev-platform), *not* in bugzilla.  Bugzilla is for dealing with implementation issues/details, not deciding policy direction.

> Mozilla has never had a policy of adhering to standards at all costs, above
> the goal of building a sane browser that serves its users well.  Thus, I
> would hope that some discussion could occur on Mozilla's side without
> getting immediately cut off by "the standard says we must, go away".

I think you need to read some of the background discussions on www-style from a few years back.  The proposal to use the same-origin restriction was made by Mozilla and was included when @font-face was first implemented.

Please move further discussion to a mailing list.  Thanks!
(In reply to John Daggett (:jtd) from comment #27)
> (In reply to Josh Triplett from comment #26)
> > I understand the process for getting the standard changed.  I had hoped to
> > start out by getting some consensus from Mozilla's side that the relevant
> > bit of the standard had more than a little brain damage.  Where would be the
> > appropriate place to start *that* discussion?
> 
> On one of the Mozilla mailing lists (e.g. dev-platform), *not* in bugzilla. 
> Bugzilla is for dealing with implementation issues/details, not deciding
> policy direction.

I realize that; that's why I asked for the appropriate location. :)

> > Mozilla has never had a policy of adhering to standards at all costs, above
> > the goal of building a sane browser that serves its users well.  Thus, I
> > would hope that some discussion could occur on Mozilla's side without
> > getting immediately cut off by "the standard says we must, go away".
> 
> I think you need to read some of the background discussions on www-style
> from a few years back.  The proposal to use the same-origin restriction was
> made by Mozilla and was included when @font-face was first implemented.

Ugh, that's disappointing; I assumed that would have have come from a font foundry, not a browser vendor.  I'll try to dig up the rationale from Mozilla (unless you happen to have a pointer to it handy?).

> Please move further discussion to a mailing list.  Thanks!

Will do, and thanks for the pointers.
I understand the point of the same origin policy for fonts on the internet. However, its implementation in browser has an awkward consequence for browsing of an offline content.

I am making a presentation CD in html, that will be viewed offline. I use legally downloaded open fonts and css @font-face property for presentation. However, as the fonts are (together with css style) in a directory next to the directory with html content, they are at a "different domain" for the browser and not shown.

Just to make it clear, directory structure is like:
/css
  /fonts
/html
  * html documents in a tree of subdirectories *

What is the correct way to use the @font-face respecting the same origin policy in this use case? The CORS (header Access-Control-Allow-Origin) cannot be employed as the files are served by file:/// protocol, not by HTTP.

I figured out just two work-arounds:

1. To embed base64-encoded fonts into CSS. (This can cause problems with length of the URL.)
2. Place a copy of the fonts next to each html document in the subdirectory tree (or at least to all leafs of the tree) and link that copy to the html instead of linking the "master" font. (In this case, however, browser may not recognize it is a copy of the same font and process and cache it again and again resulting in worse performance.)

Neither of them looks like a real solution, they are just workarounds. Any idea about the "idiomatic solution" for this use case intended by standards?

In my opinion browsers should be for *browsing of a content* (possibly with different restrictions on the internet and offline) and not just for *browsing the internet*.
Any consideration for allowing same root domain.com?


Common practice to stick files in a sub.domain.com.
-Multiple sub1.domain.com sub2.domain.com that are CDN backed to allow for simultaneous loading.
-To eliminate extra data transfers by implementing cookies only on www.domain.com such that sub.domain.com is cookieless.
It was proposed, as I recall, but vetoed by some of the other UA vendors, who don't think that adding more uses of eTLD is reasonable.
Yes, Chrome is generally opposed to anything "root domain"-based, because in order to tell what a root domain is, you have to have a list of all the TLDs, and this changes over time.

(You need a list because some TLDs are a single token, like .com, while others are two tokens, like .co.uk.  If a new two-token TLD is added, then until all the browsers update their TLD lists, every single domain on that TLD will be considered to be in the same "root domain".)

Firefox is the only browser so far that considers it reasonable to use a TLD list. :/
> Firefox is the only browser so far that considers it reasonable to use a TLD list. :/

Oh, c'mon.  Everyone uses it for cookies, because web compat requires that.

For what it's worth, I view Chrome's behavior here (of vetoing the eTLD option but then not implementing the spec's requirement of a CORS check) as disingenuous at best and likely to lead to us having to do eTLD instead of strict CORS here at worst.

So if you're opposed to eTLD use here, get Chrome to follow the spec.
I strongly agree, fwiw.  Now that we're using Blink, I'll push for it again.  IIRC, it seemed to be mostly negative feedback from Apple engineers that prevented me from successfully getting WebKit to follow the spec last time I tried.
That's great news!
I started a discussion about honoring SOR in @font-face for Blink: https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/blink-dev/TT9D5-Zfnzw

If you have any data or other input to assuage compat concerns, it would be great to respond.
Thanks for that.  I don't think I have anything that you didn't already bring up.
Whiteboard: DUPEME
In case someone ends up here from a search on the topic, I would like to share the latest status for Chrome/Blink as a follow up to Tab's reply.

Chrome M36 shows a warning in the console for the non-compliant web font request.
Chrome M37 will honor SOR and reject non-compliant web font requests (crbug.com/286681)

The access-control-allow-origin header should be used in order to relax the same-origin restriction.
"Platform: x86 Mac OS X"

I just ran into this problem on Windows 7x64 with FF40.0.3 (no Apple hardware). Is there anything I can do on the client-side to get rid if this annoying behavior that other browsers do not have?
According to the comments above, Firefox's behavior follows the CSS Fonts spec; and this is also implemented by IE (see comment 25), and more recently by Chrome (see comment 39). If you're having problems, it is most likely caused by incorrectly-configured sites.

If you're seeing examples that work in (up-to-date versions of) other browsers, and fail in Firefox, and you believe this is because of a bug in Firefox, then please *file a new bug* with full details of the problem (including the specific site that's affected).
(In reply to John Daggett (:jtd) from comment #27)
> I think you need to read some of the background discussions on www-style
> from a few years back.  The proposal to use the same-origin restriction was
> made by Mozilla and was included when @font-face was first implemented.

Can you give us a link where this discussions on www-style can be found? So users can read the reasons why this got proposed as a standard. Especially since your post and comment #8 and comment #9 sounds that Mozilla has favored and proposed a DRM mechanism that would technically not be needed which got then more or less a standard.
Flags: needinfo?(jd.bugzilla)
The same-origin policy applies to pretty much all new resource types on the web.  There's only a handful of legacy resource types (images, scripts, css, and ugh, audio/video (barely missed the boat on those)) that let cross-origin pages hotlink without restriction.

This is now a standard security practice for the web.
What Tab said...! ;)
Flags: needinfo?(jd.bugzilla)
On answering based on this answer (I'm still missing the link but this is maybe not so important anymore): Applying the same-origin policy does always imply DRM as it prevents to fetch data that could be publicly available. This is fine as long as there is a security reason behind (like preventing a malicious page doing cross-domain XHR to do evil things with our authentication). But it does sound here as this would not always be the case with new resource types. Well, I have to evaluate this in the future at some point.
You need to log in before you can comment on or make changes to this bug.