Yeah .. although, as I mentioned, that helps only in an upgrade scenario and not otherwise since if someone were to tamper with an AIR file he could also repackage and sign it with a new certificate of his own.

I’m assuming (haven’t tested it) that AIR runtime warns the user if there is a mismatch between the certificates of an old version and a new version during an upgrade .. so a self signed certificate does help in that scenario.

It does provide some security by ensuring that the AIR file has not been tampered with since it was created.

However, the publisher’s origin cannot be verified or trusted.

mike chambers

mesh@adobe.com

Thanks for the correction .. ya its not possible to package an AIR file without at least a self signed certificate.

Although, what good is a self signed certificate … there is no guarantee of identity. In fact the AIR install wizard shouldn’t and doesn’t even show a self signed identity.

Mrinal

Don’t you mean that most AIR developers are self signing air apps? I don’t think it is possible to package an app without signing it (atleast by a self-signed certificate)

This post is really informative and thanks for sharing your knowledge, and finally i feel that if the Title of this post scares the non-developers, but when we read the post its not that scary , and very informative and developers can gather some basics here.

regards,
kumar.

I totally trust you guys … the signature will just assure me (and other users) that the air file came directly from you and was not tampered with before it reached me.

Glad you realize the importance of this.

I love twhirl,

Cheers,
Mrinal

We’re not evil you can trust us, but I appreciate your concerns and let me know if I can reassure you in any way.

While code-signing in desktop applications is underused (available, but underused!), most desktop applications do not install automatically out of a browser as AIR applications can. And in my experience (having dealt with only partially tech-literate relatives!), people are more likely to blindly click ‘ok’ on things that pop up out of a browser than on a desktop. Only marginally so, but still.

And yes, really, we need better methods for handling authentication without having to trust the secret details to a third-party.

I think that the title was misleading. However, I agree with the actual post.

-End users should be careful when they install desktop applications.

-Developers should sign their application with a cert from a known and trusted authority.

-End users should be careful about giving apps user / pass for services.

This last item is really up to the service provides, who need to provide auth other than http auth. For example, FriendFeed and Flickr handle this in a way that doesn’t require the user to give their auth info directly to the app. It is more work for the developer to implement, but ultimately safer for the end user.

mike chambers

mesh@adobe.com

mike chambers

mesh@adobe.com