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

>The problem is, for the protection to be effective, the specification
>has to be kept secret, otherwise there's nothing stopping someone from
>hacking their browser to save them unencrypted.  And if the specification
>is kept a secret, that discriminates against free software, by not allowing
>free browsers (such as lynx and xmosaic) to have this functionality.
>Until someone cracks it, of course.

Well, we all know that absolute security is a myth anyway. 

Let's look at it this way: would you like someone to walk in with one
of the 3 decompilers (not disassemblers, decompilers) for JAVA, and
reverse engineer your technology in half an hour, or would you like to
cause them to spend *time* breaking your security?

If you use public key technologies, and supply keys to only licensed
users (perhaps via telephone, FAX, snail mail, or secured electronic
communications), then the only people who will be *easily* able to
crack your class are people who 1) have a valid license, or some other
way of accessing a valid key. 2) That have source to the VM,
including source to the part that does the decryption etc.

If we further restrict things so that only *binaries* (shared
libraries) for the encryption technology are available, it makes it
even harder. I think that's about as close to secure as you're likely
to get in the environment we imagine such fonts in.

This doesn't need to penalise free software.

Received on Sunday, 11 August 1996 08:21:18 UTC