W3C home > Mailing lists > Public > www-font@w3.org > April to June 2010

Re: About using CORS

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 04 May 2010 13:57:29 +0900
To: "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>, "Sylvain Galineau" <sylvaing@microsoft.com>, www-font@w3.org
Message-ID: <op.vb5z13ew64w2qv@annevk-t60>
Adding www-font per the suggestion from John. Maybe the next reply should  
remove public-webfonts-wg? Is everyone on public-webfonts-wg on www-font?

On Tue, 04 May 2010 13:33:45 +0900, Sylvain Galineau  
<sylvaing@microsoft.com> wrote:
> From: Anne van Kesteren [mailto:annevk@opera.com]
>> That sounds like a general problem with HTTP compression. Again
>> something that does not just need to be solved for fonts, as far
>> as I can tell.
> That HTTP compression has a 'general problem' hardly sounds like an
> argument to depend on it for resources as large as fonts.

If we can solve that problem now we might avoid complexity for font  
formats. It seems like a good thing to consider the overall picture.

> The same thing could also be said about PNG, JPEG or any format that
> includes its own data compression scheme. Being far larger than most
> images, fonts arguably deserve a compressed encoding as much as
> other binary data formats.

My understanding is that WOFF does not specify a font compression  
mechanism optimized for fonts, but rather re-uses ZLIB for font data  
tables. My understanding is also that compression was not really the  
motivation for WOFF. That is, we could not be doing WOFF if it was just  
for compression.

> But as this was not the main motivation for WOFF compression and has
> no relation to CORS, we should keep this for a future discussion.

I hope you don't mind I replied anyway.

>> I don't really see it. If the browser has such a severe bug it would
>> need to be fixed immediately. Maybe you can make the scenario more  
>> concrete?
> A font file crafted to exploit a security flaw in an operating system's  
> font manager is one. (And this has already happened).

How does this relate to cross-origin usage though? What is the attack  
scenario? Say someone puts up a malicious font on a server. Why would I  
link to it? Why would anyone else? He would have to use some kind of  
attack vector on a site I frequent to reference the font to enlarge the  
attack space. Am I missing something?

I certainly understand fonts are somewhat new when it comes to the Web and  
have been used in a rather sandboxed way so far. Much like a lot of other  
formats. This is why we have security teams, font fuzzers, and other means  
of finding and addressing security issues.

If there is a vulnerability a font file however, it is a problem.  
Regardless of whether there is a same-origin restriction. This is why I  
called FUD. I will try to be more nuanced.

>> I don't think fonts warrant a change.
> A change to *what* ? Firefox 3.6 uses CORS to access fonts across  
> domains. How does that implementation conflict with the spec ?

Whether it conflicts with the CORS specification is besides the point. It  
conflicts with how the same-origin policy is designed. I tried to explain  
that here:  

Anne van Kesteren
Received on Tuesday, 4 May 2010 04:58:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:34 UTC