- From: Gavin Nicol <gtn@ebt.com>
- Date: Sun, 11 Aug 1996 12:19:16 GMT
- To: acb@cs.monash.edu.au
- CC: lee@sq.com, acb@cs.monash.edu.au, www-font@w3.org
>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