1
edit
Talk:Software Update: Difference between revisions
→Automatic Updates vs System Security
Cognominal (talk | contribs) (live xpi updates) |
Ctempleton3 (talk | contribs) |
||
| (6 intermediate revisions by 4 users not shown) | |||
| Line 81: | Line 81: | ||
[[User:Cognominal|Cognominal]] 14:20, 3 Jun 2005 (PDT) | [[User:Cognominal|Cognominal]] 14:20, 3 Jun 2005 (PDT) | ||
Part of the plan worries me, to quote the first paragraph: | |||
"Revise the existing toolkit code which downloads XPI updates. Provide a silent mode that will be used for security updates. Do this only if the user has agreed (via some UI during installation perhaps) and only if the user has write permission to the installation directory. We don't want this update system to get in the way of RPM or MSI based solutions, etc." | |||
Picture the large microsoft windows running company where employees are users, not even "power users", and don't have write permission to the installation directory. The quoted paragraph seems to specifically exclude the clients automatically upgrading. Now, I think the way other programs running under windows get around the necessary priviledge elevation, is by running a "service" as a user with rights to the installation directory, e.g. system, or administrator, which the client running as user can connect to. Without this, there doesn't seem to be a way of managing firefox without visiting each an every computer it is installed on. | |||
== Automatic Updates vs System Security == | |||
spmirowski wondering: | |||
"Picture the large microsoft windows running company where employees are users, not even "power users", and don't have write permission to the installation directory. The quoted paragraph seems to specifically exclude the clients automatically upgrading. Now, I think the way other programs running under windows get around the necessary priviledge elevation, is by running a "service" as a user with rights to the installation directory, e.g. system, or administrator, which the client running as user can connect to. Without this, there doesn't seem to be a way of managing firefox without visiting each an every computer it is installed on." | |||
As an administrator of a multiple Domains and stand-alone networks over many campuses, it is a poor system to upgrade Firefox if it must be done an administrator on each machine. If it was a service or a program that called an admin account to do the upgrade, it would a be much less of a head ache. I don't like IE, however, automatic updates saves me so much time. Certainly, I don't want to give Users/Domain User RW access to programs to do updates. Less perm to the Users, less security issues. | |||
Most home computers bought, OEM etc, are improperly setup. Stores/OEMs set up the default account as an administrator (this is why so many people have spyware, malware issues). But for those home computers that are setup for limited user or just user accounts, the same problem will occur as well. And that's just Windows. | |||
What about GNU/Linux or OSX? Root owns my programs. Will Firefox have to be ran as Root or a super user just to update? | |||
<i>ctempleton3:</i> I work for a large multinational defense corporation. Our division's corporate policies do not allow for Firefox to be used because there is no centralized system to push down updates to individual users. Our MIS department believes that a copy of Firefox that remains unpatched after a security flaw is found is more dangerous than a copy of Internet Explorer that is patched. I ask that you as developers look into a open source system of pushing down updates to users | |||
== Software Updates Revised == | |||
My interest is in the complete update process and I think some vital elements are missing. | |||
* To begin with I read in the discussions that some customised plug-ins, such as imagedownload, cannot cope with updates. This knowledge should be stored somewhere explicitly, and used by the update checker. | |||
* I think we're missing out on valuable feedback on failed installations. Why don't we use talkback? It would be nice to see how many deployments actually fail, and do something about it. | |||
* Older compiled versions cannot be downloaded from the site. I know we want to encourage users to work with the latest version, however, I hear from system managers that they need to first test updates on a different system, before company wide deployment. The updater does not support this yet, especially due to the fact that you cannot give a different location as to where updates can be found. | |||
Feel free to comment on this, these conclusions are based on some research I've been doing in the area of software deployment. | |||
== Are silent downloads and mandatory upgrades a good thing? == | |||
I think that automatic download and installation of upgrades without user consent is problematic. | |||
For example, what if the new version has some bug? What if it is not even a bug, but a functionality change that not all users like? What if this affects only 2% of users? Depending on software popularity, even a small percentage of users can translate into very very large numbers. | |||
I think that to retain user satisfaction, which is critical for product popularity, the users should be allowed to decide for themselves when and how they want to download/install available upgrades. | |||