Re: EOT-Lite File Format

On Thu, 2009-07-30 at 17:25 -0700, John Hudson wrote:
> Thomas Lord wrote:
> 
> >> For implementations *only* supporting EOT-Lite, the font is not
> >> loaded.  No exceptions. 
> 
> > I think we have a problem there.  What you describe
> > is a DRM-via-standards mechanism 
> 
> Really? It seems to me that it is simply chucking something that it 
> considers an invalid file. 

That's called "intolerance in what you receive" 
and while Internet standards must not forbid 
such intolerance, neither may they require it.
("may?  according to what authority?" - answer: 
"common sense - well, at least the common sense
that comes with experience").  

A standard should require the refusal of non-conforming
data when that is necessary to protect the user from
harm - that is not the case here.


> A DRM-enabling mechanism is something that 
> restricts use of a font by a user agent. 

You have a usable font file but the standard
says "you MUST NOT use it" -- yes, that is DRM.

> The font being invalid 
> according to the format specification doesn't seem to me to be 
> DRM-enabling. I mean, how is the described behaviour
> 
>     1. Check that MagicNumber is 0x504C.
>     2. Check that the version number is either 0x00010000,
>           0x00020001, or 0x00020002.
>     3. Check that Flag bits TTEMBED_TTCOMPRESSED and
>           TTEMBED_XORENCRYPTDATA are not set.
> 
>     If any of these checks fail, the font is not loaded.
> 
> exploitable as a protection?

I am thinking of the situation of a UA maker who
goes ahead and implements support for TTCOMPRESSED
and/or XORENCRYPT... as an example.  They have done
a perfectly useful thing in support of the lawful activity
of some users yet if the Recommendation says they
"MUST NOT" do so then at the very least they lose their
"conforming implementation" badge and at worse come under
legal attack for spreading a "circumvention" device.


> I guess a font is really well protected if it won't display anywhere.:)

I agree with that. :-)

-t



> JH

Received on Friday, 31 July 2009 01:11:37 UTC