I attended two days of briefings on Adobe’s developer-focused products, especially the forthcoming AIR (Adobe Integrated Runtime).
In essence, AIR is the Flash player supplemented by additional features to enable applications that are not browser-hosted, but installed as desktop applications. AIR is great for some scenarios, weak for others. Here’s 10 reasons to love it:
1. Fast execution. ActionScript 3.0 has a JIT (just-in-time) compiler, putting it on a par with Java or .NET for raw performance.
2. Cross-platform. AIR apps will run on Windows XP and Vista, Mac OS X (PowerPC and Intel), Linux (though not in the beta).
3. Easy conversion of existing Flex or HTML applications. It’s the same basic runtime. In the case of HTML, AIR apps rely on WebKit, the core component in Apple’s Safari web browser.
4. Easy installation. Provided the runtime has installed successfully, installing AIR applications is likely to be be trouble-free, since all the files go into the application directory.
5. SQLite. AIR applications have use of a fast local database.
6. Synchronization services provided you use LiveCycle. Synchronization is the difficult part of enabling offline support in occasionally connected applications.
7. Rich design and multimedia. This is Flash, so ideal for highly customized UIs, animation, sound and video. Adobe is proving the point by creating a media player built with AIR. Existing Flash developers can easily use their skills to build AIR applications.
8. Great for web vendors who want a desktop presence. For example, one of the demo applications is for buying on eBay. If eBay persuades you to install it, then it is no longer dependent on you firing up a web browser and navigating to its site. It is also a good way to disintermediate Google.
9. Declarative programming via FLEX. Declarative programming is the best way to code a GUI and consume components.
10. ActionScript 3.0 combines the flexibility of JavaScript with grown-up object orientation. Option for dynamic or strict typing according to developer preference.
So is AIR your next development platform? Maybe, but there are some downsides:
1. Limited extensibility. AIR apps have file access, clipboard access, support multiple windows, support drag and drop, and can trigger notifications (“toast” in Windows). If you app needs to interact with the desktop in other ways, the chances are that AIR is not suitable. For example, there’s no access to COM automation, and no way to execute external applications. The reason is to maintain cross-platform compatibility. That’s a worthy goal, but it would be good to have a way out of the sandbox. Unlike Java or .NET, you cannot extend AIR with custom native code libraries. Nor can you call operating system APIs.
2. Database access limited to SQLite or web services.
3. Enterprises need to roll out applications over the network in a controlled manner. AIR has no specific support for enterprise deployment. On Windows, AIR does not use the Windows Installer service. Either Adobe or 3rd parties will need to create deployment wrappers to overcome this.
4. Proprietary technology. AIR applications depend on Adobe’s runtime.
5. No threading support. Architect Kevin Lynch says this is a strong candidate for a future release.
6. No model for commercial components. It is not clear to me how a component vendor could sell an AIR component while protecting it from unlicensed deployment. This may limit the availability of 3rd party components, with a corresponding impact on productivity.
7. Schizophrenic development model. AIR supports either Flex development, or HTML applications which run in WebKit. The ugly side of this flexibility is that there are two SDKs, even two JavaScript virtual machines with different capabilities and characteristics. While it is nice to have a way to render HTML, I am not convinced that the web application model is worth it, given the complications it causes. After all, web applications run perfectly well in the browser.
8. Security concerns. AIR is close to the worst of both worlds, being tightly sandboxed from a developer perspective, but not particularly safe from the user’s perspective. Adobe says it will allow unsigned applications, which I think is a mistake.* AIR has the same access to the file system as the user, which in the case of users running on Windows XP with full admin rights is very extensive. Example bad scenarios would include downloading malware and placing it your startup folder, or searching your file system for bank details and uploading them to some internet location. That said, Adobe says there will be more security features, so conclusions are premature.
9. Synchronization service depends on LiveCycle, the server-side piece which runs on J2E application servers. This is one of the ways Adobe makes money out of AIR, with the other obvious one being design and development tools. A consequence of point 4 above.
10. Lack of UI standards may lead to annoying inconsistencies between AIR applications. We are used to this on the Web; now it is coming to the desktop as well.
*I was told that application signing is not required, but Daniel Dura comments below that this is not the case; however he says self-signed applications will be allowed. Perhaps this is one of the things under discussion. Personally I think the default should be to require applications signed by a trusted certificate, but to provide a way for developers to switch this off.
While I don’t dispute any of your listed items on both sides of the good/bad fence, I do think #8 on the bad is something that can be suspected of all executables, AIR or otherwise.
Directly relative to a situation where actionscript can be brought to the desktop, ZINC, SWf Studio, mProjector and all the rest of the major wrappers can do the same regarding #8, would not require an added runtime download or install (allowing them to actually obfuscate their authroing app whereas AIR makes it obvious who to blame) and since they are NOT constrained by the lack of #1 on your bad list…they can do far worse.
If a developer is of the mindset to be malicious, the authoring environment or programming language are not to blame…the developer is. Common sense dictates all software installs in the modern world and I see no reason why Adobe should be held to standards no other wrapper creator is and lets face it…AIR is simply a wrapper that needs a core. It just adds more possible core choices than those mentioned that embed flashplayer alone (since it embeds a webkit engine in it’s runtime, it’s not specific to an swf/actionscript core) and IMO is far less of a security risk than what exists now.
If MDM ZINC can literally smoke a users drive if the developer chooses to make it so….I don’t suspect their upcoming MDM Pandora will be less capable than ZINC but most likely MORE capable. I’m not worried about AIR installs half as much as the ones I can’t point a finger at 🙂
Just one small correction. We will require that all applications are signed. Although, developers will be able to self-sign their applications.
Danny
Adobe Systems
I’d like to add #11 to your “cons” list: the AIR (and Flex2) SDK licenses pretty much state that once you’ve built an application, you’ve probably violated the license. Forgive me if this turns out poorly formatted, as I don’t see a Preview Comment button…
If you visit the Adobe AIR downloads site, you are supposed to check off the following statement:
That license contains the following clause:
Part (a) of that clause should be OK, though I’m worried how Adobe’s attorneys might spin the term “expropriate”. Part (c) is of some concern because it lacks any sort of statement of intent (i.e., a bug in your application that leaves the AIR runtime in a borked state might run afoul of this clause, even if you didn’t intend to bork AIR).
Part (b), though, is utter nonsense, because it has no limitations on scope. There are tens of thousands of jurisdictions in the United States alone, from the federal level down to towns and villages. According to part (b), you’re stating that you’re complying will all their laws, statutes, ordinances, and regulations (“violates any…”). Not to mention all the laws, statutes, ordinances, and regulations from jurisdictions outside the United States, since the license clause doesn’t restrict matters to any specific geography. For all I know, there’s some village in Upper Mongolia that has banned GUIs with buttons, yet by agreeing to this license, I am effectively agreeing not to build GUIs with buttons if such a regulation exists anywhere. To top it off, they toss in “rights”, which gives Adobe’s attorneys a nice malleable term for anything else they don’t like but can’t find a law, regulation, ordinance, or statute against.
The upshot is that Adobe pretty much can sue anybody they want who builds applications with Adobe AIR. While one would hope their intent is not to sue everybody, I for one am not interested in developing under licenses with these sorts of terms. It’s too bad, because AIR and Flex2 (which has the same legalese, last I looked) are interesting technologies.
It may come with a JIT compiler, but the performance will not quite be on a par with Java/.NET. It still should be fast enough for most things though.
Interesting point. I agree that it is unlikely to match Java/.NET on first release. But “performance” is tough to nail down. It will be interesting to look at startup time and memory usage as well as number-crunching speed; and to look at graphics perf., especially when hardware acceleration is added to Flash.
Tim
Check out Weborb Air Edition (http://www.themidnightcoders.com/blog/2007/07/weborb-air-edition.html). it’s an embedable version of Weborb that lets you connect directly from a AIR app to a local database. More to it than that but it is a good fit for that problem.
Interesting review. Let me add some pros :
– Very active dev community. Port of Flex3 to open source will be fructified. A lot of open-source components – it is rare that you need to develop your own components.
– Techno integration. You can display HTML and PDF inline. And you have a excellent bridge between Javascript engine and ActionScript.
I’m getting tired of hearing this. Yes, executable code that runs on your computer can harm your computer. This is not a new development, and shouldn’t come as a surprise to anyone. You can write malware in C++, Java, C#, Perl, and any other language. If you execute that code on your computer, you will get hurt. That’s not a “security problem” with Java or any other language — it’s an artifact of the way reality is. Trusting that which is untrustworthy results in Bad Stuff. Period, end of story.
If you don’t know the app you are downloading and running is trustworthy, you shouldn’t be running it! If you want to restrict executable code, run it with reduced permissions. Run it in a virtual machine. But that is an operating system, network administrator and/or end user problem — if we took the attitude that “locally executable code is dangerous” we wouldn’t have software on the desktop at all!
True, but some code is safer than others. For example, Javascript running in the browser should be safe (but sometimes isn’t because of browser bugs), Java applets are sandboxed, so are Flash SWFs running in the browser. Adobe is aiming to make AIR apps very easy to install from the Internet. That being the case, it seems to me that they should be more secure than, say, any old executable that you download and run.
It is all very well saying “If you don’t know the app you are downloading and running is trustworthy, you shouldn’t be running it,” but many users simply do not understand what the issues are or how to find out whether an app is trustworthy. In fairness, it is not particularly easy, especially with unsigned apps. At home or in small businesses there is no network administrator; just a user.
What begins as a home user problem ends up as a problem for all of us, when hijacked computers start pumping out spam or participating in DOS attacks.
We need all the help we can get to make computing safer.
Tim
Adobe is aiming to make AIR apps very easy to install from the Internet. That being the case, it seems to me that they should be more secure than, say, any old executable that you download and run.
How so? You make it sound as if you press a button and an AIR app mysteriously appears. My understanding is at 1.0 they will detect if you have the runtime installed and if not it will first install that and then will download and install the application but at no time is the end user unaware of any step in the process. The truth of the matter is they are more involving and require more user awareness via attention and yes/no prompts than “any old executable” downloaded in a browser and if you have ever seen an AIR install screen you know they give an end user warning about possible ramifications of downloaded untrusted software that would scare the pants off the average user.
Again….if I wanted to wrap some nasty code in an unsigned app and be completely clandestine about it….AIR wouldn’t be the tool of choice. Other wrappers would allow faster installation and far more ability to dig into the guts of the system in question and I could hide every move I make with suppressed command prompts and asset packing which I can extract at runtime and go to town with.
While I’m happy to see you are concerned about general computer users safety, I do think you are forgetting to spread a little of the product armegeddon to some other applications which do the asme…do it better and are also sorely in need of some “end user awareness”.
Installing an AIR app requires *more* user intervention than any old executable. Here’s what’s required to run malicious code packaged a a native executable:
1) Click link to malware.exe
2) Choose “run now” in the IE dialog that pops up
Bang, you’re dead.
Here’s what’s involved in an AIR app:
1) Click link to malware.air
2) Click “open with AIR installer”
3) Click “yes I want to give Jonny’s Computer-Devourer full and unrestricted access to my computer”
4) Choose an install location and hit continue
AIR has introduced a number of additional steps that give the user a chance to back out.
Chris S put it nicely — the AIR installer warning screen would “scare the pants off the average user.” You’ve got 1 large and 2 medium red “X”‘s, and “System Access: UNRESTRICTED” appearing in *two* locations on that screen.
I think Adobe would do right to discourage malware writers from using AIR as an attack vector–and I think they’ve already done it with the multi-step installation process, and the loud “warning, don’t proceed unless you trust this publisher” warning dialog.
I understand there will be a couple of different models. In one model what you describe is pretty much what happens, but the apps are sandboxed. In the other model, which is the only one in the current beta, you run an installer which, as you say, raises a warning dialog. On Vista you also get a UAC warning.
It is a little different from clicking an exe file, since the .air file type is registered to the AIR installer (I’m presuming the runtime is already installed). So you don’t get the normal browser “do you want to run/save”, but rather an AIR dialog saying the same thing. Try it:
http://labs.adobe.com/technologies/air/samples/
The install process is very easy, which is good, but it’s a shame that the sandboxing isn’t more granular. Currently, as I observed, you get many of the disadvantages of a sandbox (limited extensibility) but little gain in security.
Again as I noted, I think we should wait a bit before making final judgements as I gather that there are more security pieces to come.
Not sure about that, I’ve written a fair amount about security issues, especially on Windows.
Tim
First, this dialog may change in the final release.
Second, I don’t like it. Why should you have to give some little utility unrestricted system access? We can do better than that.
Tim
Not sure about that, I’ve written a fair amount about security issues, especially on Windows.
I’m talking about how we are pretending Adobe invented this desktop abilty and how they should somehow be the ones to define the standards of desktop software and are somehow getting all the negative press when in reality I can do more harm on a Win box with Zinc, mProjector, SWFS and all the rest of the authoring environments that require nothing of the end user except the need for them to click to install. They even carry along their own Flashplayer and can wreak havoc if a developer chooses and are in the exact same realm of usage possibilities as AIR. They interact with the web and the OS, offer the same ability to any old user with even a rudimentary understanding of Actionscript and have been on the market for years without a single instance of a massive DOS attack or any other kind I have ever heard of I might add. So far in beta we have file system access and have yet to hear of one single massive attack with AIR beta in all these months as well. Are AIR deveopers waiting till the stroke of midnight on some predetermined date to carpet bomb the world with bad apples or could it possibly be that there are better tools suited to the purpose to explain the lack of not one single instance of anything massively bad occuring thusfar?
With AIR being less capable than other apps in the same arena (even though it adds it’s own runtime and the ability for html/js developers to come onboard it is still a wrapper that needs a core)…..how is it Adobe has to set the standards or meet anyones unrealistic expectations and in effect cut it’s own legs off before it’s even in final? Writing to the disk has been mentioned…we can already do that with many other tools and we can write to other things as well like the registry. Same with a lot of the negative aspects being fingered at AIR and going under the radar in regards to other tools that allow the same IMO.
Desktop software via wrapped cores wasn’t invented by Adobe…it’s a latecomer.
Are you saying this is a good thing or a bad thing?
Incidentally, while it might be different behind the scenes, to the end user it’s the same deal–they need to decide whether or not they want to run local, native code on their computer, and they *must* choose “yes” or the process won’t continue.
I don’t like it either. What do you propose, giving the user options about how much access to give the program? That would be cool. It would be *very* cool, actually!
But there are two things I *don’t* want to happen:
1) I don’t want AIR as a platform to be hobbled with security restrictions. It will make it less useful to us as developers, but won’t stop malware writers from continuing their exploits along other attack vectors.
2) I don’t want AIR’s 1.0 release to be delayed for months because they’re working on offering more granularity on the sandboxing. For v1.0, perhaps there will be no sandboxing. That’s fine; I’ve lived my whole life with apps that have “unrestricted” access to my computer, and correspondingly, run only trusted apps. And I look forward to the day when I have more granular control over permissions on my workstation without needing VMware.
It doesn’t, of course, and I’ve repeatedly made the point about not being final.
That said, Adobe will be held to higher standards than smaller players because Flash etc is so widely used, it’s the price of success.
Plus, we are in a bad situation with regard to security, we need to make it better. Technology like AIR can actually help.
Tim
I can see where you are coming from. Since I’ve argued for making AIR more extensible (and therefore even less secure, I guess) I agree with you about not hobbling it. I think the sandboxing could be better, but most of my concerns will be allayed if signed apps are required for end users. Developers can do what they like 🙂
Tim
How do you envision signing working? Are you thinking similar to SSL certificates, where you pay to have a trusted authority sign your application? If you have to pay in order to get a trusted signature on every app you distribute, that could really dampen the open-source side of the community.
Normally you have to pay only once every couple of years, to get a certificate with which to sign the apps. There has to be a charge, because the certificate provider is meant to verify you are who you say you are.
It’s not a big cost, but as you say could put off the most casual developers. I think it is worth it.
Tim
Hmm, I’m not so sure. If I want to write and distribute a .NET or Java app for free, I don’t have to get it signed…
It’s a trade-off. I’d have it require signed apps by default, and let developers or others who know what they are doing switch that off if they want.
Tim
Regarding the #2 downside, if by “database access” you mean, data sitting on a server, the data can also be accessed using xml, remoting (lcds, web orb, etc.), name/value pair strings, etc.
Some pages can’t fit in to a 800×600 screen. I have to scroll left and right to read all the text.
Con:
No support for plugins such as quicktime.
Jamie
One correction: AIR does use the Windows Installer service, both for installing the runtime and for installing AIR-based applications. (This is not to say we have good enterprise deployment support yet, mind you. We’re aware of those limitations and hope to address them in the future.)
regards,
Oliver Goldman
Adobe AIR Engineering
Adobe Systems Inc.