The AIR application installer panel that displays the publisher identity has been simplified when an application is signed with a chained certificate

Sure enough, it is a much more welcoming experience as can be seen from the screenshots below:

Previous to AIR 1.5.2

AIR 1.5.2

Mmmmm… much better!

There are also a few API changes that developers should take note of including a favorite of mine- the ability to intercept an ESC key in fullscreen interactive mode. A bunch of other cool stuff and many, many bugfixes are included.

Get Adobe AIR 1.5.2

Adobe AIR 1.5.2 Release Notes

This will be my attempt to document the steps taken to get the certificate migration to function correctly. I’m using Flex Builder 3 on Windows Vista.

In many of my AIR apps, I use the AIR Update Framework which allows an app to check for updates to itself. Anytime a user would try and auto-update or even download and install an updated .air file manually (without first performing an uninstall), they would receive a generic installation error. That’s no good.

My first inclination was to place a warning in the updater XML file letting users know to UNINSTALL the app- then REINSTALL because of the cert change. Not very graceful and the update notes are collapsed by default anyway- no one would see them. That’s when I began searching and found this in the LiveDocs:

It tells you a lot but fell a few points short for me. ADT (AIR Development Toolkit) was referenced- was this included in the FB3 SDKs or was this an additional download? Where do I find it?

After a bit of digging around, I located it in “C:\Program Files (x86)\Adobe\Flex Builder 3\sdks\3.2.0\bin”. To get it to work properly though, one should set up an environment variable in Windows. On Vista, this is done by going to System Properties, clicking Advanced System Settings, and pressing the “Environment Variables” button. You’ll want to look for the “Path” variable under “System Variables” and append the location of ADT to this. Be sure to separate each Path value item with a semi-colon.

The proper syntax for performing a certificate migration is “adt –migrate -storetype pkcs12 -keystore cert.p12 myApp.air myApp.air”. So I opened up a command prompt, navigated to the application directory and punched in my command. No good. ADT spit back an error that it couldn’t locate ‘java’. I know that Java is running on my system- so on a hunch, I added another environment variable to point to my Java installation folder- “C:\Program Files (x86)\Java\jre6\bin”.

Running ADT again and I was prompted for my certificate key and upon entering that, ADT was able to successfully migrate my cert!

Starting with version 10,0,2, if Flash Player sees a “Content-Disposition: attachment” header while downloading a SWF file, it will ignore the SWF file rather than play it. Note that this restriction applies only to SWF files and not to other types of content, such as images, sounds, text, or XML files, policy files, etc.

If you control the HTTP server on which the SWF file resides, determine whether you trust the SWF file to execute in the server’s domain. If so, remove the “Content-Disposition: attachment” header by changing your HTTP server’s configuration.

While our resolution did differ slightly from the one posted above.  It effectively does the same thing.

I’ve read the documentation on FMS3 security features and have used quite a few myself.  Knowing these features, I could not understand how the Flash Player security model could be at fault- it seemed much more likely that the developers simply didn’t cover all their bases.

Whenever I read something like this, I am naturally concerned as I’ve thrown quite a bit of support behind FMS over the years.

Well, it seems that my hunch was correct and Adobe is not to blame.  People are far too quick to pass judgement on things like this, whether it’s Adobe, Microsoft, Apple or some other giant corporation, everyone jumps on the bandwagon when a story like this breaks.  Give it a rest…

Not sure if this will work or if the security sandbox prevents access to RTMP data unconditionally. I know this method has been used for simple cross-domain data transfers over HTTP with success. This may be something different alltogether as a security policy file doesn’t mean “boo” in regard to RTMP streams. More documentation on these security restrictions and more news on the features of FMS3 would help.

SWF files installed with Apollo applications do not need to look for cross-domain policy files. Capabilities that normally require another SWF file to grant access by calling the Security.allowDomain() method are not restricted to SWF files installed in Apollo applications.

This sounds very good. I’ve always found Flash Player security a bit restrictive. No other platform that I’m aware of has such tight rules about reading crossdomain data.

It is also stated that:

All other resources—those that are not installed with the Apollo application—are put in the same security sandboxes as they would be placed in if they were running in Flash Player in a web browser. Remote resources are put in sandboxes according to their source domains, and local resources are put in the local-with-networking, local-with-filesystem, or local-trusted sandbox.

So I guess I am pretty confused at this point… these statements seem to be in conflict with one another. I’ll have to build some sample apps to sort this out for myself.

EDIT: After toying around with Apollo and reading further into the documentation, my perception is that Flash content built with Apollo has a certain set of security features, while SWF files loaded into an Apollo application have a similar but different set of features.