Re: Fonts WG Charter feedback

On Thu, Jul 2, 2009 at 6:00 PM, Thomas Lord<lord@emf.net> wrote:
> On Thu, 2009-07-02 at 17:41 -0500, Tab Atkins Jr. wrote:
>> Basically, every restrictive format involves (and generally, is
>> dominated by) one or more of the following three approaches:
>
>> 1. Purposely breaking interop with desktop OSes (EOT, any obfuscation
>> proposal, most compression proposals).
>
>
> That is reason enough for W3C TAG to object to any
> such proposal, in my opinion.

As this is a Webfonts proposal, though, I'm not seeing a compelling
reason to make desktop interop a priority.  While I like it purely
from an authoring side (I would like to easily go from
desktop->server), I don't think it's necessary to make it easy to go
from server->desktop.

>> 2. Making it clear that the font isn't intended for 'normal' desktop
>> use (renaming proposals, subsetting proposals).
>
> Those are just a specific technical way of accomplishing your point (1).

Indeed, but they're different enough in technical details that I think
they should be separated.

>> 3. Restricting what domains the font can be used on (rootstring
>> proposals, same-origin proposals).
>
>
> Rootstring and same-origin proposals should not be
> lumped together - they are profoundly different.

I disagree - both are fundamentally similar.  Rootstrings encode the
allowed domains explicitly, same-origin restrictions encode them
implicitly.

> A rootstring proposal attempts to insist that you
> may not perform certain computations that can trivially
> be done with a font that you have received.

Yup.

> A same-origin (CORS-style) restriction allows someone
> to decline to give you a copy of the font under certain
> circumstances.

Incorrect, at least if same-origin and CORS is implemented in the same
way it is currently used for XHR and such.  An XHR request is
processed and returned to the browser *no matter what* - the
same-origin restriction is enforced *by the browser* by restricting
access to the response's body after it receives it.

In font terms, you can request a font from any domain, and the server
will give it to you, but then the browser will refuse to use it if the
page isn't on the same origin as the font server.  CORS headers (sent
*with* the font, as part of the response) can instruct the browser to
loosen this rule.

This is a necessity for security reasons - if same-origin was
implemented on the server, the client would have to send its origin to
the server.  This produces identical privacy breaches as the Referer
header does.  The way same-origin actually works, though, the server
needs to produce identity information (this doesn't actually require
any effort on the server's part, as the client already knows the
server's origin since it contacted the server), and the client's
origin is known by the browser, which is not a security breach.

>> None of these three are intended to limit the site author who buys a
>> font in any way; they're intended to prevent/discourage viewers and
>> authors of other sites from downloading and reusing a linked font
>> themselves.
>
> This in spite of that fact that such a restriction
> is completely inappropriate for libre fonts.

Indeed!  This is why I and others are fighting so hard to make sure
that a format which doesn't impose undue restrictions on libre fonts
is supported, even if a restrictive format is *also* supported.

>> (Even the raw TTF/OTF approach uses option 3, as the Webfonts spec
>> does or did say that fonts used with @font-face should have
>> same-origin restrictions.)
>
> Same-origin restrictions help the operators of
> servers sort out what requests to satisfy on their
> own servers.   Don't confuse them with rootstring proposals
> which attempt to restrict how YOU use a font file
> on YOUR computer.

As explained above, this is incorrect.  The same-origin mechanic
involves the server responding to every request, and the browser then
determining what information to reveal to the page or script.

~TJ

Received on Thursday, 2 July 2009 23:16:12 UTC