W3C home > Mailing lists > Public > public-webfonts-wg@w3.org > February 2011

Re: Thoughts on font linking and embedding

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 16 Feb 2011 13:04:26 -0800
Cc: "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
Message-id: <9D696367-3F3D-4CDA-9286-C0615A796D64@apple.com>
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>

On Feb 16, 2011, at 12:26 PM, Levantovsky, Vladimir wrote:

> Hello Maciej,
> 
> Thank you very much for your thoughtful and detailed response, and welcome to the WebFonts WG.
> 
> See comments inline.
> 
> On Wednesday, February 16, 2011 2:28 PM Maciej Stachowiak wrote:
>> 
>> == (3) Hotlinking prevention is useful, but not a very strong license
>> enforcement mechanism ==
>> 
>> Besides protecting the hosting site's bandwidth, same-origin embedding
>> restrictions are proposed as a lightweight aid to following font
>> licenses that limit use to a single site. It is reasonable that font
>> vendors may want this, but I think we need to keep this threat in
>> perspective. Most sites wanting to make unauthorized use of a font will
>> simply download it and host it from their own site. Same-origin
>> restrictions will do nothing to prevent that. Hotlinking seems like a
>> less likely scenario for license violation.
>> 
> 
> I agree with you that hotlinking prevention is useful for all resource types, but there are some special considerations that I believe are warranted for fonts. First and foremost, there are specific security concerns - fonts provide very fruitful grounds for malware, and allowing font hotlinking (or embedding, as you explained in your excellent Web platform overview) would, undoubtfully, create security risks. We already know how powerful font exploits can be:
> http://news.cnet.com/8301-31021_3-20012511-260.html

Same-origin restrictions are not a defense against code execution exploits of this type. The attacker can host the font on their own server, or, if trying to inject into someone else's content, serve it with the CORS header. So this is not a relevant consideration.

Regards,
Maciej
Received on Wednesday, 16 February 2011 21:58:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 16 February 2011 21:58:05 GMT