[Why it matters]
There are several issues here [This seems like it has likely been discussed elsewhere on the wiki - perhaps some pointers are appropriate?]
- One may wish to prevent the user of an application from knowing what is being done algorithmically, out of security concerns.
- One may wish to prevent the user from knowing what is being done out of intellectual property concerns
- One may wish to prevent the user from modifying the code out of maintenance support concerns
- One may wish to prevent the user from modifying the code to prevent abuse (for instance, to hopefully limit the amount of cheating one might do in multi-player games)
[Why
Java,
C, ... aren't really all that hot for security.]
[Distinguish
obfuscation and full-blown
encryption.]
It
is practical to deliver encrypted
Tcl-coded applications.
Steve Blinkhorn, for example, has written, "Various of my
Tclkit-based projects are delivered using
blowfish encryption, with some extra attention given to the security of keys. There's nothing especially difficult about doing this with single-file
Starpacks, and the actual encryption code is miniscule - I routinely build
starkits with multiple versions of a mini-extension for various platforms, with little impact on the overall size. For instance, a version of
tclhttpd with some custom code (including encryption) packaged up as a single-file executable with tclkit has 300Kbytes or so to spare for a document tree and still fits on a 3.5" floppy, is in live use now, doesn't crash and supports some quite complex client-server transactions with a
Metakit database (the code for which, of course, comes as part of the Tclkit executable).
With a two-file (Starkit) solution, it is possible to update client software on remote sites transparently, so far as the user is concerned, and on a user-by-user basis, because the .kit file looks to the executable like a
file system."
Tcl packages and applications related to this topic: