Re: CSS3 @font-face / EOT Fonts - new compromise proposal

2008/11/13 Levantovsky, Vladimir <Vladimir.Levantovsky@monotypeimaging.com>:
> On Wednesday, November 12, 2008 5:58 PM Dave Crossland wrote:
>>
>> (Please distinguish free fonts from proprietary fonts; free
>> fonts are often developed commercially eg Ascender's
>> Liberation and Droid)
>
> Dave, I believe we've had enough of these rhetoric on OpenType list, I
> don't want to pollute this reflector.

I think is important to be precise.

>> ROC suggested using gzip as the compression+obfuscation, or
>> developeing an unpatented split-stream font compression
>> method. As a foundry, would Monotype support either of these
>> compression schemes as "good enough" obfuscation?
>
> I can't see how gzip or any other standard utility compression could be
> considered an obfuscation - when people buy fonts on our website they
> download them in a zip file.

Gzip is a compression scheme. A file format with a short header and
then a gzip stream would not be readable by existing unzip utilities.
I would not expect the unzip utilities that ship with Windows and Mac
OS X to ever support it.

If MTX patents are made GPL compatible, which they must be if they
will be part of a W3C standard, then any unzip utility can implement
EOT decompression as easily as that gzip format.

> As far as any "to be developed in the future" obfuscation is concerned -
> it will be publicly disclosed and completely unprotected.

Just like MTX must be if it to be part of a W3C standard.

> Can it be good enough? MTX achieves high levels of
> compression by partially (or completely) eliminating certain data
> from an original font and
> recreating them on the fly at the decompression stage.

But that "high level" must be compared to unemcumbered and
code-on-the-shelf levels. That is, how much extra compression does it
get, for how much extra work for all parties involved?

> I consider this
> technique to be rather strong obfuscation - would you agree?

I disagree; there can be "strong encryption" but the idea of "strong
obfuscation" is a mirage. That's because encryption requires 2
parties, sender reciever and attacker - Alice Bob and Carol - while
obfuscation requires just sender and reciever.

With obfuscation, "the attacker is *also the recipient*. It's not
Alice and Bob and Carol, it's just Alice and Bob. Alice sells Bob a
DVD. She sells Bob a DVD player. The DVD has a movie on it -- say,
Pirates of the Caribbean -- and it's enciphered with an algorithm
called CSS -- Content Scrambling System. The DVD player has a CSS
un-scrambler.  Now, let's take stock of what's a secret here: the
cipher is well-known. The ciphertext is most assuredly in enemy hands,
arrr. So what? As long as the key is secret from the attacker, we're
golden. But there's the rub. Alice wants Bob to buy Pirates of the
Caribbean from her. Bob will only buy Pirates of the Caribbean if he
can descramble the CSS-encrypted VOB -- video object -- on his DVD
player. Otherwise, the disc is only useful to Bob as a drinks-coaster.
So Alice has to provide Bob -- the attacker -- with the key, the
cipher and the ciphertext. Hilarity ensues."

- http://craphound.com/msftdrm.txt

Cheers,
Dave

Received on Thursday, 13 November 2008 19:13:42 UTC