Re: css3-fonts: should not dictate usage policy with respect to origin

Florian Rivoal wrote:

> It seems to me the current proposal has two goals. The first one is limit
> accidental/misguided/unauthorized use of fonts hosted on one domain by
> another one. I believe that this first reason is the one that has been
> mentioned as explaining font creators' enthusiasm for web fonts.

> While this may not please font authors, I believe that in this context, it
> makes sense to consider this optional. As far as copy protection systems
> go, this is fairly ineffective, since it doesn't prevent you from fetching
> the font directly yourself by other means than the @font-face rule.

Some background:

If you read back through the W3C Fonts and WebFonts WG list archive 
discussions regarding same origin, you'll see that copy protection is 
not the goal. Rather, what has been sought by both font makers and also 
most of the UA makers involved in the WG has been an easy and reliable 
mechanism for authors to comply with typical commercial webfont license 
terms in which fonts are a) licensed for use on particular domains and 
b) require authors to take reasonable steps to prevent hotlinking from 
other domains. The reason for seeking such a mechanism was to encourage 
a diverse webfonts environment by making it easy for font makers and web 
authors to meet each others expectations. In the lengthy discussion of 
this, the consensus at the time of the chartering of the WG was that 
while server side referrer mechanisms exist these are not reliable and 
are not easy for authors (indeed, in many cases authors would not have 
the necessary server access). Hence, we looked for another method, and 
settled on SOR, with CORS to relax restrictions. Anne was unhappy with 
this, as he thought it was using SOR/CORS for a purpose other than that 
for which it was originally designed. As the WOFF spec advanced, the 
issue came up a number of other times, although never in the context of 
a formal objection, and Anne eventually proposed the alternative, 
generic From-Origin header. There seems general consensus that this 
proposal is a really good idea. But it needs to be made real.

> Another goal is to prevent information leakage that could be caused by
> including fonts from an intranet into a internet webpage, and then somehow
> pushing the font or information about it out of the intranet. This
> probably provides stronger justification for having a mandatory mechanism,
> since it is not only about acquiring the font, but also exposing it to the
> script environment. But this problem is not at all unique to fonts, so a
> solution that is resource type agnostic (and therefore not specified in a
> font related specification) would be best.

Agreed. I don't think anyone thinks that a generic model is not better 
than a font specific one.

> AnneVK's proposal seems to take care of the second goal better than a font
> specific rule, as it can be used on any kind of resource. With regards to
> the first goal, it has the same level of expressiveness as the current
> proposal. The main difference is that this is opt-in, while the current
> proposal is opt-out. But I don't think that this is a significant issues,
> since web servers can easily be configured to send "From-Origin: same" by
> default for the relevant file types, turning the default behavior to
> opt-out again.

 From a font vendor perspective, I'm not sure that it makes a major 
difference whether the mechanism is opt-in or opt-out. Again, what is 
important is that there be an easy and reliable mechanism that will 
constitute reasonable steps by the author to comply with the license. 
Indeed, I can imagine licenses specifically stating that the From-Origin 
header should be set to 'same', *if* this were a reliable mechanism. But 
in order for it to be a reliable mechanism, I'd say that UAs should not 
be able to consider it optional.

JH

Received on Monday, 20 June 2011 06:38:46 UTC