Using invisible files is really a token effort as far as security goes. You can usually see the invisible files using basic finder views, and you can find plenty of apps out there that make them visible, if not. There are ways to get some level of security, but applescript has limitations that simply do not afford a truly secure environment. As jonn8 said in another thread, you won’t find many scripters that have good, solid ways of doing this who will reveal their secrets. I think that the first factor when determining the security necessary for your app is ‘Who is the end user?’ Are you marketting this to other applescripters? If so, most of us could hack it apart pretty quickly given the right motivation ;). If you’re selling it to ‘regular folks’, I would say most of them would not even know how to view the package contents of an app… and if they did they wouldn’t know how to begin figuring out what the “jumble” of characters and symbols meant (assuming a deployment style package and a reasonable attempt at encrypting your data).
I think we can safely assume that most ‘regular users’ are not browsing this forum for ways to crack $5 shareware apps. Since ‘diminishing returns’ are a problem anyways, the few enthuiastic app crakers looking through here for crumbs of info are a drop in the bucket. And…since most of us here could beat the system anyways, sharing knowledge among peers (at least some) would be a good discussion and may help us all find a “better way”. That said, arumdevil, you’re on a good path with the “hidden” file concept…a data file that is not just sitting out in the open. I’m actually using two files, both identical, but in two places. The second file is a bit ‘hidden’ and remote, to try to check if the user has trashed the app and re-installed (of course if they find the second file, re-installing is still possible). I hide the first in the application package itself (:Contents:Resources:THEFILE). This is good because no matter where you put the app, the file is always in the same place. I “encrypt” the path to the file in my script and scatter the encrypion keys and values for all of my encryption throughout the script, so it is not totally obvious what things are when reading the script in a text editor like bbedit. I also write a copy of the file to a remote place, like the library directory or somewhere in the system directory (assuming you want to do some authorization/permissions magic). Anyways, use a totally arbitrary name for the two files, but something that seems appropriate and sounds “official” so as to not draw attention to itself. I recommend changing the file’s creation and modification dates so the file can not be searched for in sherlock according to it’s dates. Unfortunately, there aren’t a whole lot of places to hide things, and creating a whole new directory on a computer with an observant user is a pretty obvious change, so that’s a bad route in my opinion. As I said earlier, having a good encryption method is also a good idea and probably warrants much more attention than I’m giving it here.
As I mentioned to you in another post, I am working on a ‘prepackaged’ system I will make available as soon as it’s somewhat complete. I code for fun, so making my system available to everyone won’t ruin my security needs. I figure, if anything, people can find ways to improve on or modify the system I build to provide the security they are looking for. Realize though that you could end up doubling your file size just adding a simple, easily defeated security measure. Without solid knowledge of shell use and probably some unix tricks, AScripters should be realistic about what level of security they truly have.
When I finish my code, you’ll be welcome to it.
j
EDIT…
An afterthought…I change the modification dates and creation dates of the files to hide them from the search, but I also actually use the dates to do some of the time-stamp checking. Even if a user finds the file, they probably will not think that the actual date of the file is important. Since the creation date comes from the date it was saved on YOUR computer, not when it was installed on the user’s, only a savvy user would see or know how to overcome this obstacle.