Re: The unmentionable (was: "A way forward")

On Wed, 2009-07-29 at 06:15 +0600, Chris Fynn wrote:
> 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.

Correct.

> 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 would hope (and expect) not for at least these reasons:

1) That would create legal liabilities for implementers.
2) Such protection would be specific to just some legal jurisdictions.
3) Programs can't accurately compute a user's legal rights in any
   jurisdiction.


> 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".

Sometimes, by "garden fence", people mean a font file
format which is distinct from TT/OT format.  That's
an example of "protection" which does not involve 
a technological restriction on the font. 

In the past, people sometimes meant things like
"root string enforcement" when they said "garden fence".
That would be a technological restriction and would
likely run into problems.

-t



> 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 18:05:48 UTC