- From: Jeffrey Veen <jeff@typekit.com>
- Date: Tue, 4 May 2010 15:57:46 -0700
- 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 networks. -j -- Jeffrey Veen Co-founder, Typekit
Received on Wednesday, 5 May 2010 13:12:07 UTC