Version 8 of source protection

[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:

Category Concept