Re: The unmentionable

On Tue, Jul 28, 2009 at 8:44 PM, Richard Fink<rfink@readableweb.com> wrote:
> Tuesday, July 28, 2009 Dirk Pranke <dpranke@chromium.org>:
>
> Dirk Pranke wrote:
>
>>Apart from the first paragraph, I am curious what you believe "what
>>kinds of protections [the browser makers] would be willing to accept"
>>to be.
>
> John Hudson replied, in part:
>
>> The kind that the current draft versions of .webfont and ZOT provide.
>> There's been enough positive engagement with .webfont from
>> John D and Håkon to make it reasonable to conclude
>> willingness to accept the minimal protection in that format,
>> and the ZOT proposal came from within Mozilla.
>
> Dirk,
>
> With the understanding, as you state, that you're not speaking for
> Chrome, Chromium, or Google in any way, does the "minimal protection"
> that John writes about seem in line with what you imagine the feelings of
> those involved with other non-IE browsers would be?

Heh. Well, if I was to describe what my understanding of the
protections that .webfont and ZOT provide and correlate that against
the list of requirements in the note John referenced, it seems to me
that the main concrete protection that either format provides is that
the new formats cannot be dropped into a desktop fonts folder. Neither
format requires root strings (which is seemingly dead now,
thankfully), and neither format seems to require actual enforcement of
license restrictions beyond same-origin and/or CORS. I would have to
go back and reread the proposals to see if either format recommended
or required the browser to make the licensing information available to
the user (which is another potential requirement).

As to what other browsers might feel, my understanding of them
generally (restating what i said in the note) is that:

(a) They want to allow raw TTF fonts to be served (assuming they are
legally licensed to do so). Neither proposal precludes this, although
similarly, neither proposal requires it, so presumably IE would
continue to not implement support for this until such time as they
took a position different from the one Chris Wilson has stated.

(b) They don't want to do anything that might be seen as enforcing the
DMCA (or running into the DMCA) - I am not a lawyer, so I wouldn't
want to take a strong position here, but it seems that insofar as
there's no encryption in these formats, they're probably okay.

(c) They don't want to do anything that might be construed as
restricting (legal) user freedoms or even making life harder for the
user. Examples are potentially hosting a font on a site that they
can't control the configuration of, and hence running afoul of the
same-origin/CORS restrictions. Or, in a perhaps more touchy case,
enabling download into the fonts folder.

(d) Tthere need to be no patent concerns that might conflict with the
licensing terms of the free browsers.

(e) There may be objections that using same-origin and/or CORS as a
lightweight form of license restriction is anathema to the web as a
whole, and hence browser implementors might be very loathe to
implement something like this for fear of setting bad precedents. Tom
Lord's post from earlier today summed this up nicely, and while it is
true that there is no "internet architecture board" that can force
implementations to conform, there is an architectural board that does
reflect the concerns that many browser implementors have. For example,
both Chris Wilson and Anne van Kesteren have made similar comments
about CORS potentially being misused in this context.

So, while (a), (b), and (d) seem to be okay, (c) and (e) might be
problematic. Note that EOT Lite is pretty close to .webfont or ZOT
here, and does (perhaps) get you much better interop through backwards
compatibilty with existing browsers as well, although the
"obfuscation" might get you closer to DMCA concerns.

Also, as an observation, it's not clear to me that the .webfont
proposal offers anything particularly compelling over embedding the
metadata directly into the OTF/TTF file, apart from the desktop
interop issue). ZOT offers compression, but again it's not clear to me
if that is compelling over a generic gzipping of the content as is
trivially and universally done today by web servers.

That's about as far as I can go. I don't know if Jonathan Kew and John
Daggett are actually speaking on behalf of the Gecko powers that be. I
certainly am *not* speaking for what might be implemented in WebKit (I
am not in any way empowered to do so, and others would have to speak
on this). Presumably, Håkon is speaking on behalf of Opera, and
Sylvain and Chris on behalf of IE.

Lastly, while I do feel like the list may be getting closer to a
consensus over what a strawman might look like, I don't know that I've
seen anything from any of the above that have indicated that they
would actually endorse one of the solutions and implement it. It may
be that they would prefer to be interpreted as brainstorming, and so I
don't want to be seen as putting words in their mouths, either.

-- Dirk

(Hopefully that comes with enough caveats to render me as aggressively
neutral and noncommittal).

Received on Wednesday, 29 July 2009 06:31:26 UTC