RE: About using CORS

> From: Anne van Kesteren [mailto:annevk@opera.com]
> Sent: Monday, May 03, 2010 6:30 PM

> 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.

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.

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 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). 

While they have been supported for a while in some browsers (since IE4 in our case)
downloadable fonts have not been widely used in practice for a number of reasons.
With browser vendors now agreeing on a cross-browser format and implementing support,
higher bandwidth, built-in compression as well as high author interest, this is
going to change very soon. And that means font decoding and rendering code that thus 
far spent 99.9% of its time processing clean files that came preinstalled on your hard
drive will now spend an increasing share handling files downloaded from all over the 
Internet. Unlike image decoders, which have been exercised, probed, exploited and 
hardened for over a decade, and which can easily be implemented across platforms by 
a browser vendor, font engines are implemented by the underlying OS i.e. browsers have 
a hard dependency they have very limited control on. 

Second, fonts are more complex than images. Not only do they describe glyph shapes,
they include runtime opcodes as well e.g. hinting instructions. 

Thus a conservative working assumption is that in the near term, fonts may be more
prone to vulnerabilities than a plain old PNG. 

And if any font resource can be linked to from anywhere, font-based exploits are trivial
to abuse. Same-origin enforcement does not eliminate the risk. But it mitigates it by reducing 
it scope to those exploits where the attacker has a high level of control over the origin.
At which point fonts are only one of the things the attacker can do to you. 

SOP also happens to coincide by default with font license terms as they are practiced today.
Which, if one aims to expand author choice from a world limited to free fonts and proprietary 
font obfuscation services such as TypeKit, is a benefit.

> > And ?
> 
> 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 ? 

Received on Tuesday, 4 May 2010 04:34:26 UTC