Re: New work on fonts at W3C

On 25 Jun 2009, at 17:55, Aryeh Gregor wrote:

> On Thu, Jun 25, 2009 at 12:43 PM, Levantovsky,
> Vladimir<Vladimir.Levantovsky@monotypeimaging.com> wrote:
>> There are other ways to block font linking from other sites that do  
>> not
>> require root strings or CORS
>> (http://openfontlibrary.org/wiki/Blocking_drive-by_access).
>
> Referer-based methods are unreliable, and can block users of your own
> site as well as letting through users of other sites.  Some software
> will strip referer headers, or even change them.

So browsers that send incorrect headers would fail to work with linked  
fonts in this scenario? That seems like something browser vendors  
might be willing to fix.

>  (For instance, IIRC,
> no browser sends Referer headers from an HTTPS site to an HTTP site.)

If you have a secure site, you shouldn't be displaying your text with  
insecure fonts anyway. An enterprising attacker who can intercept and  
modify the HTTP traffic could replace your font with one where  
characters are remapped so as to radically change the apparent content  
of your site. (Trivial example: suppose it's a commerce or banking  
site of some kind, and an attacker replaces the font you're using to  
display prices or transactions, etc., with one where the digit  
codepoints are shuffled. Chaos ensues, and your business is swamped  
with calls from angry customers.)

So if you want to use downloadable fonts within an HTTPS page, serve  
the fonts over HTTPS as well.

> Depending on referer checking isn't a good idea.

Of course it's not completely foolproof or secure, but that's not the  
requirement. It may still be a useful tool.

My personal feeling is that a default same-origin restriction, with  
the ability to use CORS to enable wider use, is probably a more  
realistic way forward. Server-based restrictions based on referer  
headers have the disadvantage that they *require* configuration at the  
server; the default result if someone simply puts a font on a server  
and links to it from their page is that the font is world-accessible.  
I suspect many vendors may be uncomfortable with this, though of  
course I cannot speak for them, I'm only guessing. The same-origin  
restriction plus CORS, on the other hand, defaults to making the font  
usable by the site that is hosting it, and requires explicit  
configuration to make it more widely available. This greatly reduces  
the chances that naïvely-managed sites will inadvertently get used as  
"font libraries for the world" - a site that wants to take on this  
role should explicitly choose to do so.

JK

Received on Thursday, 25 June 2009 17:45:30 UTC