This is the Chromium side of code written by the WebKit team to let
web authors pass along a
TTF file in their page and have the browser
display it. My web developer friends tell me this is really important
to some people; I don't especially care too much either way about it,
as the intersection of (web developer who wants dynamic fonts) and
(web developer who makes pages I care about) is rather small.
However, what I do care about is security, and the security aspects of this are concerning. Part of the whole deal with Chromium was that we can run a significant fraction of the scary code inside the sandbox. A good example is image decoders, which have historically been the source of a lot of bugs and remain so recently, when the iPhone jailbreak used a TIFF decoding vulnerability.
But some decoding is beyond our control. Windows supports animated
cursors (which can be used responsibly, like for a "loading"
animation). Web pages can provide custom cursors -- one you've likely
experienced is on Google maps, where the little hand grabs the map
when you click to drag it. My vague understanding is that
files are similar to
.ico files and animated cursor files (
are a multi-frame version of
It would seem to be a simple format but the code was (reasonably, I'd argue) not written expecting users to load hostile cursor files. But once web pages could start loading cursors, there were not one but two ANI exploits, both serious, and even capable of working around the many levels of protection in Vista.
The nasty lesson of animated cursors for Chromium is that the exploit flies past the sandbox -- we pass the data from the network straight* to Windows and it's all over.
So, web fonts: pretty similar. Font rendering is also handled by
Windows, not us -- you pass the file to
and hope for the best (again see *). It seems from the API that maybe
it's only loaded per-process so maybe my worry is overblown (as the
process would be the sandboxed one), but on the other hand it's hard
to say what that does internally. And also maybe the truetype decoder
is more resilient than the cursor decoder -- font embedding has
existed in Windows for a while. But on the other hand, TrueType is a
big format, complete with an embedded bytecode interpreter and new
code, and I am not optimistic.
I am surely a luddite, but in all it seems like unnecessary risk for a marginal feature. So all I will say there was disagreement within the team and in the end the feature's here and if an exploit comes out I will point back at this post and say "I told you so". At least it will affect a bunch of browsers simultaneously.
(How about Linux?
- + Font loading happens completely within the renderer process;
- - I'd expect FreeType to be less hardened than the Windows decoder;
- - We don't have a sandbox.
* You could imagine trying to sanitise the file before handing it on to the OS. For cursors it seems plausible to me; for truetype files it doesn't.