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

Re: Java applets for font protection (was: pixel fonts)

From: <lee@sq.com>
Date: Sat, 10 Aug 96 16:23:11 EDT
Message-Id: <9608102023.AA16986@sqrex.sq.com>
To: acb@cs.monash.edu.au, gtn@ebt.com
Cc: www-font@w3.org
acb@cs.monash.edu.au (Andrew C. Bulhak) wrote:


> One way around this may be to adapt a technique from the computer virus
> "industry"; namely polymorphic code.  Have the program which generates
> font applets (each with a limited scope) perform transformations on the
> code to perturb it.

The trouble is that once someone has spent four months slaving away to
produce FontBreaker, anyone can use it easily.

I only know one mechnism that works at all well: random encodings.
Unfortunately, this renders the text unintelligible for readers without
the font, so won't do for us.  It would work for printing, though.

The idea is that you re-encode the font so that position 65 (say), instead
of containing an A, might have an `e'.

Now, this is a simple cypher, but the point is that the obvious way to
reverse it and restore the original encoding involves going into a font
editor and actually looking at each glyph & deciding what it is.  I.e.
hand work, and too much trouble for most people to go to.

Of course, once it's done, someone could post the `corrected' font.

And if you can deduce the algorithm for randomising the encoding vector,
you can immanentise the escutcheon, so to speak.

Some TeX PS drivers used to do this, and so did SoftQuad's troff HPLJ
driver, because the font was built up on the fly, so the characters were
added to a font-built-on-the-fly in the order in which they were seen
in the output.  It really makes life hard for people who want to do text
searching in Acrobat :-)

So possibly if outline fonts were `lightly encrypted' between server and
browser, e.g. with 40-bit public key or modified DES, and stored thus
in the browser's cache, and even more lightly obfuscated on their way
to the printer, and not actually installed into the system during use, but
entirely internal to the browser, there would be many fewer difficulties.

The `light encryption' between browser and server might involve the IP
address of the server, for example, so that merely taking a copy of a
font and putting it up on your server would give you an object that
wouldn't `decrypt' to anything useful.

I think it's important to remember (and most people on this list are very,
very well aware of this) that Adobe is advertising PDF heavily (or was a
few months ago) on the strength of its font embedding to preserve corporate
identities.  I'd rather see outline fonts used on the web than a move to
PDF and away from HTML (and still further away from SGML).

Received on Saturday, 10 August 1996 16:23:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:37 UTC