Your Customizable Flash Apps Could Steal Your Business

A few months ago I built a pretty hefty Flash app for presenting online courses. This course player consisted of a single SWF which loaded everything for the course dynamically--content SWFs, mp3 voice-overs, and last but not least, the XML configuration files. These config files allowed my team to easily modify the the title, navigation, and content for the course without ever needing to edit Actionscript code or recompile the course player SWF. This made it really easy to create new e-learning courses:

1. Flash designers put together some snazzy content SWFs
2. Somebody edits the XML to tell the course player when the content SWFs should be loaded
3. Run that course player SWF or EXE and voilà! You just built a new course!

That saved us a lot of work! Problem is, it could also lose us a lot of work. Once a client gets a hold of the course player SWF, they could potentially hire some one else to create the content and edit the XML. We invested in building the course player so we had to make sure we got a return for that investment—by using it to build our courses at a lower cost.

Creating Write-Protected XML Configuration Files

So we needed to prevent 3rd parties from editing the XML. Since the read-only file attribute obviously wasn't going to do the trick I came up with an alternate solution: checksums. Basically, the config file contains a key which is based on the XML configuration properties. If a property is changed, the checksum key needs to be recalculated and pasted into the XML file. When the course player loads the XML, it calculates the checksum and compares it with the value in the config file. If they don't match, it barfs all over the screen.. or gives a friendly message asking them not to modify the configuration files.

I also built a handy little checksum calculator which basically loads the current XML configuration and spits out the key. If you're doing this

Giving an Inch Without Giving a Mile

The cool thing about this is you can decide which configuration properties you want to protect and which ones the client can change. By choosing carefully which configuration parameters get translated into the protective key, you can allow them to correct a couple typos in the quiz while preventing them from changing the quiz text completely.