[webkit-dev] Same Origin Restriction on WOFF fonts across WebKit

[Maciej Stachowiak]

On Jan 28, 2011, at 4:10 PM, Tab Atkins Jr. wrote:

> On Fri, Jan 28, 2011 at 4:07 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>> On Jan 28, 2011, at 3:44 PM, Adam Barth wrote:
>>> On Fri, Jan 28, 2011 at 3:11 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>>> On Jan 28, 2011, at 3:06 PM, Tab Atkins Jr. wrote:
>>>>> The WOFF font specification requires that browsers apply Same Origin
>>>>> Restrictions (SOR) to WOFF fonts.  So far, Firefox and IE9 follow this
>>>>> requirement, while we and Opera don't.
>>>>> 
>>>>> As far as I know, our lack of SOR is basically an accident; we
>>>>> implemented support for WOFF before this requirement was added, and
>>>>> just haven't gotten around to adding it in yet.
>>>>> 
>>>>> Chrome people seem amenable to applying SOR to WOFF fonts in Chrome.
>>>>> Is it okay to add this across all our webkit ports?
>>>> 
>>>> It's not an accident. It has been our intent to willfully ignore this requirement.
>>> 
>>> What's the long-term plan here?  Are we hoping the other folks will
>>> come around to this point of view eventually?  From a game-theory
>>> point-of-view, it seems likely that the most permissive behavior is
>>> likely to become wide-spread over time.
>> 
>> A number of us at Apple who have followed downloadable fonts are not keen on adding pseudo-DRM code to WebKit. That's not the way the Web has worked historically, and there doesn't seem to be a good reason to special-case fonts. It's true that other people have come to the opposite conclusion, but there doesn't seem to be much reason to take their point of view.
>> 
>> We also think it's bad to have this requirement in the spec. But we are willing to ignore the spec if it's not changed, as with other specs that we think are a bad idea. I don't think we are too concerned with whether other implementors come around to this idea, since it's unlikely to hurt our compatibility. We think of it as having an extra feature.
>> 
>> Bottom line: if there's a strong desire to do this for Chrome, please at least make it switchable so we don't have to enable it for Safari.
> 
> When the webfont discussion started, two years ago on the CSSWG
> mailing list, Safari appeared to be in favor of SOR
> <http://lists.w3.org/Archives/Public/www-style/2008Oct/0185.html>.
> I'm curious to know the reasoning behind the reversal, so I can tell
> if my own support for SOR is wrong-headed.

I think what I said above roughly summarizes at least my own current thinking.

In the earlier discussion you cite, the context was EOT vs. vanilla OTF; WOFF itself hadn't been proposed. At the time, it seemed like a reasonable compromise to adopt same-origin if it would get everyone else to go with OTF and not push EOT on the Web. Microsoft at the time claimed they would never support normal OpenType/TrueType fonts, and it seemed useful to break the logjam.

Since then, the situation has changed. Web services have popped up which work around the licensing issues on regular fonts. IE9 is also gaining support for OpenType and TrueType in addition to WOFF. So the reasons for WOFF's creation seem weaker than they ever were. If TrueType fonts with no SOR restriction don't cause the sky to fall, then neither will WOFF fonts with no SOR restriction. We're choosing to support WOFF in Apple's WebKit because it is trivial to do so, but we no longer see same-origin restrictions as useful or necessary. In fact, in some ways it would be better if WOFF itself would go away, since it has no real benefit over other font formats. But it may have too much momentum for that at this point.

In addition to this, notwithstanding my 2008-era ill-considered statement, using CORS to relax same-origin restrictions on resource embedding doesn't seem like a good fit. CORS is designed to work around cases where you can't even send the request, and CORS requests are normally sent with no credentials. But we can't reasonably make every font request a proper CORS request, including sending OPTIONS preflight requests to get permission to send credentials. And we don't know the format until after we know the response content type. Looking at CORS headers in a response that is not to a CORS request would break the CORS model and add needless complexity to a security-sensitive technology. It simply  muddies the waters to use a cross-site communication technology for DRM purposes instead.

Regards,
Maciej