Per the WOFF spec at <http://www.w3.org/TR/WOFF/>, UAs supporting WOFF must apply same-origin restrictions to the file. Currently, we allow WOFF to be served from any origin. Firefox 4 and IE9 will ship with SOR on WOFF fonts. CORS should be usable to defeat the restriction when necessary, such as with font-serving services. Google's font api currently sends CORS headers allowing usage on any origin. (This is also filed as <http://code.google.com/p/chromium/issues/detail?id=71423>.)
Per mailing list discussion, I think we should not do this. Mailing list discussion here: https://lists.webkit.org/pipermail/webkit-dev/2011-January/015790.html
Right. Per IRC conversation, the major problem seems to be a spec one. If you only apply SOR to WOFF fonts and not others, then you can't tell ahead of time that you need to make a CORS request. There are then some architectural issues surrounding exactly how you're supposed to handle CORS if you have to request the resource first. Firefox (and presumably IE9) don't have this issue, as they just apply SOR to everything piped through @font-face. This would also be an acceptable solution, but in IRC discussion you seemed resistant to this as well (I didn't press on that issue as I didn't have time). I don't see anything particularly wrong with this. Could you elaborate on your objections in this vein?
I just got confirmation that IE9 is indeed applying SOR to all @font-face resources, using Simple Requests <http://www.w3.org/TR/cors/#resource-requests>. They even do it for EOT - they expect some minor breakage, but nearly all cross-origin font loads on the web so far are from font libraries, which are either already serving CORS headers, or only serve EOT to IE<9. If both Firefox and IE consider the public-web breakage to be minimal enough to do SOR on all font requests, I don't see any reason we should disagree, given that they both have larger marketshare and thus more reason to break.
(In reply to comment #2) > Right. Per IRC conversation, the major problem seems to be a spec one. If you only apply SOR to WOFF fonts and not others, then you can't tell ahead of time that you need to make a CORS request. There are then some architectural issues surrounding exactly how you're supposed to handle CORS if you have to request the resource first. > > Firefox (and presumably IE9) don't have this issue, as they just apply SOR to everything piped through @font-face. This would also be an acceptable solution, but in IRC discussion you seemed resistant to this as well (I didn't press on that issue as I didn't have time). I don't see anything particularly wrong with this. Could you elaborate on your objections in this vein? It would be a regression in our existing @font-face support for TrueType, OpenType and SVG fonts.
"A regression" isn't sufficient. If it's an insignificant regression, then we don't have to worry about it. As I said, IE9 and FF are already doing this, as they don't consider the potential breakage large enough to worry about. Do you have evidence of significant breakage that would be caused by applying SOR to all fonts? If it's public breakage, Moz and MS would surely be interested in hearing about it as well. If it's private breakage, we can hopefully fix it.
What is the benefit to users of doing this?
Here are some thoughts on this topic from annevk: http://annevankesteren.nl/2011/02/web-platform-consistency
WOFF isn't special. Marking as a duplicate of https://bugs.webkit.org/show_bug.cgi?id=86817 *** This bug has been marked as a duplicate of bug 86817 ***