W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

Re: EOT & DMCA concerns

From: Oliver Rigby <oliverrigby@gmail.com>
Date: Wed, 5 Aug 2009 10:29:26 +0100
Message-ID: <1467b3c10908050229l3bc0e315we16f85b394ddea6b@mail.gmail.com>
To: www-font@w3.org
On Tue, 04 Aug 2009 16:49:02 -0700 Thomas Lord wrote:
>Then to a future implementer.  An EOTL bug which
>results in accidentally rendering an EOTC font
>is quite easy to imagine.  Perhaps Moz. is above
>such a mistake yet the possibility is relevant
>to evaluating the quality of the proposed Recommendation.

This is not a reasonable concern and it can not practically happen.

It looks like there will be at least 3 magic numbers in the proposed
specification. It's hard to conceive of an implementation that's so
broken that there's three incorrect magic numbers and the browser
still decides to render it.

But even by some miracle that did happen, the proposed specification
for EOT Lite is based on a version with no rootstrings whatsoever
(0x00020000 aka 0x00010000 in the W3C submission[1]). Let's say a user
has a font which has been made for a future version of the EOT spec
which has a rootstring and they try to change the version number to
make it work with an EOTL-only browser. What will happen is that the
user will try to load it, find 'RootStringSize' and 'RootString' data
in the place that the FontData is supposed to be, and also that the
remaining size of the file is longer than necessary, so any
implementation will assume it's corrupt and it won't render. It's
simply inconceivable that an implementation will be made that
"accidentally" accepts files with rootstrings.

The only other potential corner case is where someone deliberately
tries to make an EOT file with a rootstring that's also a compliant
EOTL file on a browser with a broken magic number checker. This would
require the header of the OpenType[2] font to be the same as a
potential RootStringSize (which is an unsigned short) and the
RootString (in UTF-16), and then repeat the font header later for the
EOT-compliant browsers within the font data itself. I'm wary of
calling this it outright impossible in theory, but I'm happy to say
it's impractical for all real-world cases, and therefore can be
ignored as not being of any practical concern.

[1] http://www.w3.org/Submission/2008/SUBM-EOT-20080305/
[2] http://www.microsoft.com/typography/otspec/otff.htm
Received on Wednesday, 5 August 2009 11:43:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 11 June 2011 00:14:03 GMT