W3C home > Mailing lists > Public > www-font@w3.org > April to June 2010

RE: What constitutes protection [was: About using CORS]

From: Jeffrey Veen <jeff@typekit.com>
Date: Tue, 4 May 2010 15:57:46 -0700
Message-ID: <x2o54829fb91005041557s1b332c7cwca091b5084296f04@mail.gmail.com>
To: www-font@w3.org
On Tue, May 4, 2010 at 2:19 PM, Levantovsky, Vladimir
<Vladimir.Levantovsky@monotypeimaging.com> wrote:

> It seems that same-origin restriction by default makes perfect sense for any resource,
> and while I lament that it wasn't implemented for other resources, I do not see any
> reason why it should not be in place for fonts and other resources going forward.

Hasn't HTTP Referrer Checking been the solution to this thus far? As
far back as I can remember, people have been using it to avoid
hot-linking of images and other assets. In fact, this is what we use
on Typekit to ensure that only authorized sites are accessing the
appropriate fonts. Also, FWIW, the same-origin issue hasn't affected
us one way or the other since we encode the fonts as Data URIs
directly in the stylesheet. FontSquirrel is doing the same thing for
self-hosted free fonts.

And just as another data point: Nearly all of our large-scale
customers use CDNs for static content and, if they weren't hosting
fonts with us, would move them to these platforms. Our research with
all the enterprise-class CDNs showed that there really is no
consistency in what control you get over things like setting headers.
Implementing CORS would be case-by-case for these customers. Referrer
checking, however, is pretty much universally supported on these


Jeffrey Veen
Co-founder, Typekit
Received on Wednesday, 5 May 2010 13:12:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:34 UTC