Re: A way forward

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 Tuesday, 28 July 2009 22:33:13 UTC