Archive for March, 2011

Unique Device Identifiers on AIR Mobile

Application developers frequently want a mechanism by which they can track a device’s identity. Such a value is frequently used in conjunction with copy protection schemes to, for example, limit the total number of devices on which a user can view purchased content.

AIR ostensibly does not include an API for obtaining such an identifier. Such an API would be straightforward to implement on iOS, since iOS itself provides an identifier that can be used for this purpose. However, on Android, no such facility is provided. Seems surprising to some, but even the Android team agrees.

How to work around it? I recommend using Math.random() to generate an ID on first launch and save it locally. It’s portable, and does a better job of protecting user privacy than the iOS device identifier does. Of course it can be reset, but then users also sometimes lose or dispose of devices, so any scheme needs a mechanism to flush old device IDs from the system as “no longer in use.”

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.