W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

The unmentionable (was: "A way forward")

From: Chris Fynn <cfynn@gmx.net>
Date: Wed, 29 Jul 2009 06:15:30 +0600
Message-ID: <4A6F94A2.1040400@gmx.net>
To: www-font@w3.org
CC: Thomas Lord <lord@emf.net>
Thomas

If what you say about same-origin checking and CORS is true, presumably 
this would also apply to .webfont, ZOT or any other proposal if it 
included same-origin checking. Similarly I guess anything else that was 
in a proposal to "protect font IP" with no other clear benefit to users 
would not fly with the architectural board you refer to?

I think we need to be clear about this, as I get the feeling there may 
still be some who primarily see all these web font proposals as offering 
some form of IP protection - even if it is only a low "garden fence".

regards

- CF


Thomas Lord wrote:

> On Tue, 2009-07-28 at 15:51 -0500, info@ascenderfonts.com wrote:
> 
>> I will also repeat that we hope browsers that implement EOT Lite in
>> the future will require a same-origin check. We appreciate that
>> FireFox has done this with its initial support for font linking, and
>> hope that it will do the same with EOT Lite. Same-origin checking
>> protects font IP and also provides benefits to our customers (Ascender
>> and the browser developers customers) who want to protect their
>> bandwidth and also possibly their brand by limiting hotlinking or
>> deeplinking to their site's resources.
> 
> Please permit me to caution you just a bit, even 
> though I encourage the tack Ascender is taking lately.
> 
> Same-origin checking and CORS are much bigger and much
> beyond this discussion of fonts.  Those things are part
> of a larger software architecture for the web.
> They precede this discussion.  They have their own
> purpose and rationale outside of this discussion.
> This discussion about fonts has to (to be fully 
> successful) respect that.
> 
> In that larger web architecture, the primary purpose of
> same-origin restrictions is to protect users on the
> client side, e.g. from maliciously linked Javascript
> code.
> 
> The primary purpose of CORS is to relax same-origin
> restrictions in controlled ways, allowing one origin 
> to designate which other origins are trusted and for 
> those other origins to concur or disagree.
> 
> There is a secondary purpose of protecting server
> bandwidth but that secondary level of protection is
> strictly stochastic.  Clients can easily work around
> it without even being "non-conforming".
> 
> IN NO WAY are same origin or CORS restrictions meant
> to "protect IP".  They are *not* an access control
> mechanism.  They are *not* for the purpose of limiting
> hotlinking or deeplinking and they do not suffice for
> that purpose.  (This is not to say that the font vendors'
> strategy here is bogus -- we're just talking about
> how same-origin/CORS fits in to the web architecture.
> What you are doing is fine - how you are talking about 
> it is problematic, imo.)
> 
> It so happens that a CORS restriction makes "hotlinking"
> to a resource harder.  It so happens that, from the 
> perspective of a font vendor, that added degree of difficulty
> serves as some "IP protection".   In the W3C context,
> though, I think you have to formally recognize that those
> benefits to font vendors are a lucky accident and not a
> part of the design of CORS or same-origin restrictions.
> 
> Why does this matter?
> 
> Well, let's imagine a draft for a web font Recommendation.
> Let's suppose that the draft imposes same-origin or CORS
> restrictions.
> 
> An (or "The") architectural board would, in principle,
> want to see the "rationale" for that restriction.  By
> default, linking is not restricted.  Unrestricted linking
> is pretty much the point of the web.  A restriction
> like same-origin or CORS needs a justification - the rationale.
> 
> Helping to protect server bandwidth of servers offering
> fonts is a rationale, albeit a very weak one, for such a 
> restriction on fonts.  That fits with the architectural
> plan for same-origin/CORS restrictions.   It's a weak rationale
> because the same bandwidth protection could be obtained without
> demanding same-origin or CORS behavior by UAs but a non-0
> rationale because there is no harm in having UAs participate
> and it arguably keeps life simpler for everyone.
> 
> Helping to protect users from malicious fonts (yes, 
> I believe that there is really such a risk) is another
> rationale for same-origin / CORS restriction on font-linking.
> 
> Protecting IP?  Will not (or at the very least should
> not and will not except over loud objections) fly.  Not
> what those features are for, not what they do.... in a
> deep way, it's just The Wrong Thing to justify same-origin/CORS
> for font linking by talking about IP protection.
> 
> It's a little bit quasi-paradoxical this way:
> 
> Is it ok, sensible even, for font vendors to want 
> same-origin/CORS for font linking because it makes
> "hotlinking" harder, and therefore makes less of a 
> wild-land for unauthorized use of fonts?  Absolutely.
> It's a fine motivation for taking a position in favor
> of same-origin/CORS restrictions.
> 
> Is it ok to use protection against unlicensed use
> a rationale for same-origin/CORS?  Opinions will 
> surely vary but I suspect that dominant opinions will
> be "no, that is not ok. That is not a Rationale."
> 
> It will help your case, in the future, if you find ways
> to rationalize same-origin/CORS for font linking that
> DO NOT MENTION any concept like "IP protection".
> 
> My sense is that we're at about the time where informal
> discussion leaves off and formalization takes off.
> Now is a good time to start being very clear about the
> difference between the motivation of individual parties
> and the rationale of the ultimate Recommendation.
> 
> (Standards processes are a lot like tense court
> proceedings.  This kind of hair-splitting does matter. :-)
> 
> Regards,
> -t
Received on Wednesday, 29 July 2009 00:16:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 11 June 2011 00:14:03 GMT