EncryptedLocalStore and Storage Reliability

Recently I’ve fielded yet another question about the reliability of the EncryptedLocalStore API, which is usually a good indication that a topic deserves a post.

They key thing to understand about all storage options, encrypted or otherwise, is that there are no guarantees. Hardware failures, software failures, user error, or even deliberate user action can all lead to data disappearance and data corruption.

Applications should always be prepared to deal with these scenarios. This doesn’t necessarily mean you need fancy data-recovery options, although it might. It does mean your application shouldn’t be rendered useless upon encountering, for example, a malformed configuration file.

Does EncryptedLocalStore provide reliable storage? Probably not any more so than storing data anywhere else on a given device, as all of the same failure modes apply. Probably a bit less so, as the complex nature of the encryption mechanisms provide that many more things that can go wrong.

Note that this doesn’t excuse the presence of defects in those mechanisms. Rather, the point here is that more complex mechanisms have more points of failure, and sooner or later something will go wrong. If you’re concerned with reliability, your only realistic option is to plan for that scenario.

If you use EncryptedLocalStore to cache confidential information, such as passwords, then this issue is probably not serious, since users can generally re-enter that information. In effect, the user servers as the backup for this data.

If, however, you use EncryptedLocalStore to maintain encryption keys, or other items that the user is not aware of or cannot reproduce, then you should explore providing other backup mechanisms. If the encrypted data is valuable, you should probably back up the data and the key. If the data is a cache and is encrypted only locally, then logic to abandon and re-fill the cache may be sufficient. Whatever your scenario, an appropriate plan can no doubt be devised.

2 Responses to EncryptedLocalStore and Storage Reliability

  1. Benjamin says:

    one of my apps uses a lot of http intechange and it updates ELS very frequently. I’ve noticed that on WinXP (Win 7 never got it to do the same), if system shuts down uncleanly (power outgage,…) ELS files get lost from the folder (deleted?). I bet it must be connected with NTFS on XP and file descriptors not closed properly but that’s far out of AIR development.

    How would you propose to back up ELS files in this scenario? Should AIR app itself perform some els-files-backup.zip on let’s say app init? And if ELS files get lost on power outgage, unpack them from zip to ELS folder and reinit itself? Would that work?

    • Oliver Goldman says:

      I would propose that you don’t back up ELS. Certainly I am not comfortable that replacing the ELS file yourself is safe to do. Again, ELS should really only be used to cache sensitive data that can be acquired elsewhere if necessary, like passwords. You don’t specify what you’re storing in ELS, but you may want to reconsider whether ELS is really the appropriate storage for that data.