In my previous post, I explained that installing an AIR application sometimes requires admin rights. This begs the question: Should AIR take pains to avoid those parts of application install that sometimes require admin rights? Some applications do support this, including recently Google Chrome.
We considered this when designing the AIR install experience and ultimately decided this would be a mis-feature. It breaks down to two cases:
- You're the admin for the machine on which you're installing software. (This is the typical consumer scenario.) You don't need to install without admin rights because you've got them.
- You're not the admin, and you don't have admin rights. You want a non-admin-rights install because otherwise you can't install the application. (This is a typical enterprise scenario.)
In this second case, however, your machine is locked down for a reason: the admin doesn't want you to install anything. If they knew you were avoiding this restriction by installing without admin rights, they'd probably close that loophole, too. See, for example, this article about stopping users from installing Google Chrome.
So any specific support in AIR for installing applications without admin rights would be temporary at best, as admins could still prevent it. Worse, it makes extra works for admins who have to jump through hoops to keep their machines locked down. Since we're interested in making sure AIR stays friendly for enterprise deployments, and this feature has no value for non-enterprises, well, it just doesn't seem to make much sense.
After reading this "Should AIR take pains", I have to ask if any classes would be removed if AIR was made non-admin friendly?
It is a little annoying, because I do make applications for our intranet where the users have no rights. I can't even use an update framework so each update has to be installed manually by our IT guy (who is usually grumpy). However, if it means sacrificing some classes, I would say no, leave it how it is now.
[No, no classes would have to be removed. Would your admin be happier if AIR supported user installs? If so, why doesn't he give his users rights to install applications? —Oliver]
From a developer perspective, the initial deployment usually isn't any concern. The biggest concern is not being able to use an automatic update framework for my applications within enterprises. On the other hand, in those types of environments the IT department usually (as you said) wants control over which applications are installed and when, so no issues there I think.
I have however seen scenarios in smaller companies (50-100 employees) where they have one IT guy and he's locked down the rights to install software on the computers, but the company doesn't use any centralized deployment software (such as e.g. Tivoli) because the individual needs of each employee are so diverse, the IT guy would have to create separate images for almost everyone anyway. So he runs around the office installing software on everyones machines (including updates). In these types of scenarios it would be usefull for an AIR application to be able to update itself. Perhaps a flow where the updater checks if a previous version of the software has been installed (which it does already anyway) and if yes, allows the update. If no previous version is detected, the install is not allowed.
Yes, that would make his job much easier, and would take away some of the begging I have to do :)
They don't want users to install any programs without their consent to avoid viruses and such, which I think is standard in most business settings.
Submitted my last entry too quick. This would make it much easier being able to set up an install badge on our intranet, and utilize the update framework for any updates.
Jens Wegar's second scenario is exactly what I'm dealing with.
I think there are several scenarios where the admin wants to allow the users to install and update just air-applications in an otherwise locked-down windows environment.
With the current air runtime the admin has only the choice between "all open" and "all locked-down". Why not letting the admin decide whats the best for his environment?
Within a locked-down environment the nice air application updater is almost useless.
Portable applications rule as web application do. I can not use any AIR applications on my USB drive. AIR is not very common. Why use AIR again?
Oliver,
I'm a developer for Customs and Border Protection. We have 18,000 users around the country that use the applications that we build.
Your position that "admins" should decide what can and cannot be "installed" on user's desktop is well intentioned, but flawed in regards to adoption of your product (and by extension, what we develop using your products).
I have no problem with requiring Administrator rights to install Air itself, but Air application, are you kidding me?
No federal agency is going to have a policy that allows end users to install applications to "global" locations. This is true on whatever platform I've used at work (Linux and Windows). It's incredibly difficult, even on large, high-profile projects to get all of the various security people to accredit an application, to get it deployed at the client site.
I'm currently in the midst of getting Adobe Air to be accredited for our organization, and you WOULD NOT BELIEVE the amount of paperwork this involves, the number of meetings explaining to non-technical people the benefits, the number of signatures required, and the TIME. It will probably be March 2010 (optimistically), before final authority is granted to move Adobe Air into our standard machine images, and to get it moved into the field.
It's incredibly discouraging to me -- depressing, really -- to read your remarks dismissing the important of "local installs" for end users. I would love to evangelize the use of Adobe Air within our organization, but that is never going to happen, if every time I want to distribute an application to the end user, I have to get an administrator to sign off.
I'm begging you, and by extension Adobe, to reconsider your position. Perhaps a compromise can be reached. For example, a "local" install might not have access to the local file system, but could still open windows outside the browser, work in the background, etc. Or perhaps the installation of Air, could include some "trusted certificate authorities" that would allow installs of applications signed by those CAs without any administrative rights. That's do-able in our organization.
Thanks very much for your time and consideration.
Oliver,
I think we've discussed this in the past. What would be helpful to improve user experience is to:
1) Detect the user's admin rights during install so they can be provided instructions as to what to do. Not all users are aware of their status as a non-admin. Possibly there's way to do this already, I just haven't found it.
2) Allow an application to be 'grandfathered'. Once installed with admin rights, the local user would be allowed to update the application without admin intervention. That would be HUGE. Possibly this could be an option presented to the original installer to permit grandfathering, so long as the rights conferred in the original install aren't expanded in any way.
Jeff
I think it makes a lot of sense to allow non-administrator installation of AIR apps in Windows. OS X already does this and there are many environments where IT does not grant corporate users administrator privileges but would want to allow them to install AIR applications.
To make it really slick, you could ask the question during installation of the AIR runtime environment to allow IT to control it without having to "hack" anything.
It opens up another niche for AIR development.
I have just arrived at the same point - we are perfectly happy with an admin install of AIR and even an initial admin install of the application itself (we have to distribute to our app 250 employees). Thats fine, BUT then not being able to push out an update to the application automatically and having to rely on the IT dept to update it for us on each machine individually SUCKS big time and kills this one dead in the water.
Seconding Greg's comment above. The inability to install AIR applications without admin rights is from my organization's perspective a major negative, which significantly decreases our interest in using Adobe AIR as a development platform.
I think you should implement fine grained controls and information about them if you want to encourage it's adoption.
I posted the following at
"http://www.splitbrain.org/blog/2008-04/18-adobe_air_on_linux-a_security_nightmare#MTC_form"
=========================================================
AIR on Linux
Whilst I agree that it should certainly support sudo to gain priviledges, I think there are bigger problems.
I feel websites have far more power than they often need and use javascripts unnecessarily meaning users just leave it on (including Adobe and the code their programs generate), never mind air using foreign code which seems dependent on a developer security model that can run even when the browser is closed rather than a fine grained framework, with options!. Flash was originally a simple animation package and has become a video software (and communication package), which is why most people install it, creating even more unneeded security risk, which I hope will be replaced by straight forward and transparent OGV/theora which would allow priviledge separationssss, which is key as the root password arguments pointed out.
Whilst it should be separated from your boot and system files, running as a user is still unacceptible for a foreign untrusted source. There are enough problems with flash adverts already. If untrusted execution is neccessary to provide for things like pleasing a false sense of security in the bbc iplayers ability to be cross platform and protect video and please producers at the real expense of user security, then it should be highly limitable or limited and atleast have a separate password and robust password system for installing the air apps, Javascript sandboxing failed time and again.
What can a restricted user do;
download and read most or all of your data and send it, make your web browser load something everytime it runs and conduct attacks, these are priviledges that could be deemed more important than the system itself which can be recovered from online repositories, if it wasn't for the fact that having access to the system would mean access to everything anyway and modern motherboard manufacturers being stupid.
The only way I am going to use it at the moment as there are enough security problems on the web, is on a system that is cut off from most of my network and that I am not too concerned about, and I will watch that system to make sure it's not obviously infecting unprotected websites and users of the internet.
This needs to be sorted out or I would hope that it would affect it's adoptability. At the moment they seem to only be talking about developer (potential attacker) and not end-user security (air security paper.pdf). Even if you care and are able, the information seems non existent, though I came across this
"According to Adobe bulletin, the issues are all remotely exploitable. The could allow an attacker who successfully exploits the vulnerability to execute untrusted JavaScript with elevated privileges."
I'm going to test it out on one machine, see what I can control via configuration and make read only and whether preventing even a question of further install is possible. It hasn't got a man page, so I'm not hoping for much, without blind hope and testing.
Someone got a microsoft certificate from a CA once and could sign programs anyway and there was a recent null encoding attack on SSL certificates, which are more about making money than protection.