RE: EOT-Lite File Format

Thursday, July 30, 2009 John Daggett <jdaggett@mozilla.com>:

>I don't thinking XOR'ing the data adds much in the way of obfuscation
>and it affects performance since it requires an extra pass over the
>data and potentially extra memory buffers to push things around.

>For an unpublished standard it would hide things like strings somewhat
>but for a published standard it does little.

All true. Once published, the obfuscation is toothless. It becomes nonsensical. Unless I'm missing some subsidiary benefit. IMO - the XOR swizzle, too, should die with EOT CL.

Regards,

rich

-----Original Message-----
From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf Of John Daggett
Sent: Thursday, July 30, 2009 8:43 PM
To: www-font
Subject: Re: EOT-Lite File Format

Christopher Slye wrote:

> > No, it's a validity check.  If a file is XOR-swizzled or MTX
> > compressed it's not a valid EOT-Lite file.  Same as trying to use
> > a HTML file as an image file, it's not in a valid format.
> 
> I was under the impression that XOR "swizzling" was okay for EOTL.
> Ascender's tool provides it as an option.

In the file format I wrote, I had it as part of EOT-Classic behavior.

I don't thinking XOR'ing the data adds much in the way of obfuscation
and it affects performance since it requires an extra pass over the
data and potentially extra memory buffers to push things around.

Compressed formats have a similar burden but the benefit is smaller
data size, there's very little in tangible benefit to XOR'ing data.
For an unpublished standard it would hide things like strings somewhat
but for a published standard it does little.

Received on Friday, 31 July 2009 00:57:08 UTC