Slashdot Mirror
Adobe Joins Linux Foundation, Develops AIR For Linux
2muchcoffeeman writes "Adobe announced Monday that it is joining the Linux Foundation and alpha-released a Linux version of its new Adobe Internet Runtime environment, which allows Internet-enabled applications to run on Windows and Mac OS desktops, for Linux. According to Adobe, the alpha version lacks some key features that will be available in the final product and only runs with Sun Java, not GNU Java. Adobe also released an alpha of Flex Builder for Linux Monday."
Not meant as a troll, but it is hard to find an objective explanation of how AIR is going to fill a huge need or bake better bread.
64-bit Flash!
If you install an AIR app, it can install the runtime at the same time. It's pretty transparent, and certainly better than stuff like the Java installer with Web Start. Also, if any company can build an install base it's Adobe. Look at the penetration of Flash.
The notion of trust is nothing new. The basic question comes down to this, do you trust the code (or coders for the code that) you are about to run or not? If you don't, then don't run the code. If you do, then go ahead and run the code.
That question may be easy to ask but not so easy to answer. Maybe you trust the organization but there could be inadvertent security vulnerabilities in the code. Or maybe you don't know much about the organization who authored or published the application. How do you decide whether or not to trust the application?
In theory, open source mitigates this trust issue because you can study the code yourself. In practice, it's not so easy. First of all, access to the source code is immaterial to people who are not coders themselves. Second, it would take a lot of time and mind to study the code for a large project. Sure, any competent programmer could study and verify for his or herself that my open source project can be trusted because it really isn't all that big. How can you be sure that Firefox doesn't have any malicious code in it?
One approach to this problem is to run programs in what is called a sandbox. What that means is that the program isn't written in what is called the native "machine" code. Rather, it is written in a code for a virtual machine. Every time that code makes an API call, the virtual machine checks to see if it is permitted from a security perspective. Applications that run in a sandbox don't get a lot of permissions. It is OK to run an application that you don't completely trust within the sandbox because the virtual machine is going to deny any requests that could compromise or take advantage of your system anyway.
That is why the complaint about ActiveX. Both ActiveX controls and Java applets run in a web browser. The Java applet has to run in the sandbox (unless it is signed but it is beyond the scope of this post to introduce PKI and X.509 certificates) but the ActiveX control never runs in a sandbox.
Later iterations of this sandbox concept allow the user more control over what the program can and cannot do. In .NET, this is called Code Access Security and in J2SE, this is called Java Security Policy. Before running an application, the user can specify what API calls that the application can and cannot call. The problem here is that this specification is not easy to tweak for mere mortals. When you just double click the application icon, you are running the application with whatever policy that the publishing company specified. So, you are back to trusting that company since there is nothing that keeps them from specifying a policy that is wide open.
I have no experience in AIR so I could not tell you whether or not that virtual machine implements any kind of policy control. Perhaps someone that is knowledgeable about AIR would care to clarify here?