AIR 1.5 Cookbook released

air_cookbook.gif
I’m pleased to announce that O’Reilly has released the cookbook for Adobe AIR 1.5. I was involved with the book as technical editor, fortunate to work with authors David Tucker, Marco Casario, Koen De Weggheleire, and Rich Tretola, among other very talented contributing developers.

Like other O’Reilly cookbooks, the book aims to provide readers with a collection of practical solutions to common real-world problems that AIR developers face. The ‘recipes’ it features address a broad range of challenges, spanning topics including:

– Encrypted local data storage
– Embedded SQL database programming
– HTML content
– PDF support
– Clipboard support
– Drag and drop support
– Filesystem integration
– Taskbar and dock integration
– Service monitor framework
– Application updates

The book is available for pre-order on Amazon, but if you are attending MAX 2008 in San Francisco, it is available for purchase at the O’Reilly booth. If you can’t wait, or are not at MAX, a chapter of the book is available for free download at the AIR Developer Center, enjoy.

Adobe AIR:
What is Adobe AIR?

Amazon:
AIR 1.5 Cookbook

Adobe AIR Developer Center:
AIR 1.5 Cookbook excerpt: Applications and native window menus

-ekz

AIR: tight security for your apps. Pt 2. Bound to Bits

Following up from the previous post, it’s worth mentioning ‘strongly binding’ data in the EncryptedLocalStore (ELS). When storing your data with EncryptedLocalStore.setItem() , setting the optional ‘stronglyBound’ parameter to true will result in your data being strongly bound to the actual bits of the AIR application.

This is important to understand because it means that ANY modification of your application files will result in making that data inaccessible. So this means if the user were to update to a new version of the app, the data will not be accessible to the new version. I asked members of the Flex/Air team about this feature, specifically what risks you run by not strongly binding your data, and got back some useful feedback, particularly on i) what an attacker might attempt and ii) how one might account for version updates:

“An attacker can replace an app’s publisher ID by re-signing the victim app using a certificate that the attacker controls. After doing so, the attacker can then create his own app (with the same publisher ID), and have both the victim app and the attacking app use the same ELS files. For [an application that tracks user behavior], this is very useful to perform track fraud [if such an app were to rely] on ELS to store [the tracked data].

Strongly bound ELS items would not be accessible anymore [once] the storing app is updated (since then its bytes on disk would have been modified). To migrate these items, the older app will need to retrieve all ELS data and then encrypt them using its own [custom, non ELS] key and writes them to [local] disk. The newer app will then use the same key to retrieve them. How this key is generated is up to the developer (and directly influences the security of this migration process).

[Strong Binding] is implemented through hashing the storing and the retrieving Air apps’ bytes on disk, which means strongly bound ELS items will not typically survive from one Flex Builder debugging session to the next if the app’s code has been changed in between.”

Now tell me that isn’t good to know… Hope you guys find the above as helpful as I have.

Much thanks to Sunil Agrawal and the rest of the team for providing insight into this!

ekz

AIR: tight security for your apps. Pt 1. EncryptedLocalStore

Recently I looked into AIR security, specifically re: storing local data on the user’s machine. I’ve seen storing on the disk, and storing to SQLLite, but neither of these are secure and the data can be accessed by other apps. Fortunately your next resort doesnt have to be writing your own encryption algorithim, because we have the EncryptedLocalStore class (flash.data.*)

From Adobe livedocs:
A persistent encrypted local store is available for each AIR application installed on a user’s computer. This lets you save and retrieve data that is stored on the user’s local hard drive in an encrypted format that cannot be deciphered by other applications or users. A separate encrypted local store is used for each AIR application, and each AIR application uses a separate encrypted local store for each user. Encrypted local store data is put in a subdirectory of the user’s application data directory; the subdirectory path is Adobe/AIR/ELS/ followed by the application ID.

Similar to how one would use setProperty() when dealing with shared objects, you can call the static method EncryptedLocalStore.setItem(), passing it a ‘key’ or identifier along with your data, and store up to 10 MB of ByteArray data in the encrypted store. So, using the read/write methods of the ByteArray class, you can store much of your sensitive application data securely. To retrieve the data, call EncryptedLocalStore.getItem() with the appropriate key.

One good thing to note is that it is not by the Application ID that access rights are verified, rather by the signing certificate and publisher ID; to impersonate another application, you’d have to have stolen a signing key or have hacked AIR.

Learn more on LiveDocs: EncryptedLocalStore

ekz

I’m blogging

My name’s Ikezi* and I build RIAs at Adobe (Adobe Consulting).

I’ve been an RIA junkie for near 10 years now, and am finally making the time to share my thoughts and experiences with the community via this blog. The good times should follow soon, as there’s so much to talk about, and so many interesting things that will be happening in the world of RIAs, and at Adobe in particular.

So this first post is my official invitation for you guys to stay tuned; I’ll do my best to keep it interesting.

*its pronounced ee·kay·zee