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

> From: public-webfonts-wg-request@w3.org [mailto:public-webfonts-wg-
> request@w3.org] On Behalf Of Anne van Kesteren


> Not at all. From-Origin would complement CORS. It allows one to
> indicate a resource can not be used by the requesting party without 
> having to inspect the Referer / Origin headers in the request. It does 
> not affect request policies at all.

Sorry. I still fail to see why this can't be done with the existing mechanism, 
as done by Firefox today. I'm sure it can be done this way too. I just
don't see the necessity of adding yet another code path. 

Now if CORS is going to add this anyway and it is better suited for this
purpose, then let's talk about it when there is a concrete proposal.

> Using CORS for font requests is not at all interoperable today. 

I didn't say it was. But one major browser vendor supports it. It is
a standard and the subset of it that is most relevant here is already 
supported by several browsers as part of their cross-domain XHR support.
 
> What is the roadmap for authors who coded against WebKit or Presto and
> rely on cross-origin fonts without CORS?

First, until Presto and WebKit support WOFF with no SOR, there is no roadmap
to be concerned about.

Second, we know for certain these fonts are raw. If they are served by a font 
subscription service, the latter will handle the change on the server side. 
(In TypeKit's case, the font data is encoded in CSS using data URIs so they 
wouldn't be affected).

For free fonts, authors are, by definition, free to place the resource wherever
they wish. 

And if Presto and/or WebKit have no security concerns - unlike, say, Chromium -
they could also keep raw fonts wide open for backward compatibility and restrict
WOFF for interop.

Received on Tuesday, 4 May 2010 06:15:13 UTC