Web fonts

January 08, 2009

r7592 - Add dynamic web font support to Chrome's port of Webkit.

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 .cur files are similar to .ico files and animated cursor files (.ani) are a multi-frame version of .cur.

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

Summary: ugh.)

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