Re: EOT & DMCA concerns

On Tue, 2009-08-04 at 12:23 -0500, Tab Atkins Jr. wrote:

> Indeed, that's a potential problem if anyone were suggesting that
> browser vendors should parse EOT files and ignore the rootstrings.
> 
> I questioned the relevance of this because no one has suggested that.

Which leaves the EOTL proposal in the uncomfortable 
situation of insisting that rootstrings be enforced - 
if not by honoring them then by rejecting any and all
files that contain one.

Poor Håkon would be getting angry bug reports from
people who use set ups that generate EOTC and who have
heard that Opera has *some* kind of EOT support - so
why do their fonts work in IE but not Opera?  And he'll
be legally encumbered from changing Opera so as to 
satisfy the filers of those bugs.

Poor Dagget might eventually find that Firefox has
had an EOTL bug for a year or two that results in
the accidental rendering of some EOTC fonts.  Worse,
perhaps resulting in some number of sites "in the wild"
that rely on this bug.

There is a legal minefield surrounding strict
EOTL unless there is broad agreement that the
intention is for people to be free to implement
EOTC while ignoring the "protection" features.

> In specific, the EOTL proposals do not suggest that.  

No, they suggest that UAs not implementing EOTC
MUST reject EOTC files.


> The EOTL1.1
> format is based on an EOT version without rootstrings.  Even in the
> hypothetical EOTLwrip format, a conformant application can distinguish
> between EOTLwrip and plain EOT with rootstrings, and can correctly
> enforce the rootstrings in the latter (or drop the file on the floor,
> if they don't want to support rootstrings).
> 
> The EOTLwrip format explicitly does not have rootstrings.  It has
> several padding areas filled with explicitly meaningless bits.  There
> is nothing at any point in the specification that is intended or
> implied to act as a protection measure, no matter how meager.  An EOT
> file with rootstrings cannot be confused for an EOTLwrap file in a
> conformant application.
> 
> The EOTL1.1 format explicitly does not have rootstrings.  It has
> several padding areas filled with explicitly meaningless bits.  An EOT
> file with rootstrings is formatted incorrectly for an EOTL1.1 file,
> and will be rejected by a conformant application (at least, rejected
> by the EOTL-parsing codepath).


It's interesting that if a second browser 
happened to use exactly the same algorithms
as IE to implement EOTL compatibility, they
would be in patent trouble.   And if a patch
were made that disabled rootstring enforcement
in that algorithm, they'd be in DMCA territory.

EOTL is surrounded by a legal minefield.
And strict EOTL won't handle a single font
that is found in the wild or the font output 
by any but one very recently written program.
Which is an odd place to wind up when discussion
of EOT variants was taken up to achieve downward
compatibility.

-t


> ~TJ

Received on Tuesday, 4 August 2009 17:39:04 UTC