Does Firefox plan to use the same style of forced updates that Chrome does? As a web developer I am very grateful that Chrome is not only updated regularly but that these updates are forced on the end user. IE10 could be the best browser ever, but unfortunately there will still be people using IE7.
It does, but it's nowhere near as smooth, and I'm not talking about dialogs and user intervention.
Whereas Chrome has a stable extension API, Firefox really breaks at least one very popular plugin withe each "release." So then you get nasty warnings about incompatible plugin versions and whether or not you want to look up a new version of the plugin. Whereas Chrome a) doesn't break plugin APIs very often, even in alpha and beta channels and b) automatically updates plugins anyway.
Firefox also upgrades plugins automatically, provided they pass a bunch of automated tests. Unfortunately, it seems many don't.
The openness of their API is certainly a two edge sword; in one way, it lets developers dig deep in the browser's internals, which means addons can be immensely more powerful than on Chrome; on the other hand, it means they have a dependency on those same internal APIs.
They've launched the Jetpack SDK as a stable API for addons that doesn't require browser restarts to install them, but almost no one uses it:|
I wonder if there's anything other than momentum holding Jetpack back. I would be interested in trying to get some add-ons ported just for fun. I do agree that the add-ons in Firefox are way more powerful; I like that Adblock on FF can block ads before they're even retrieved (leaving my Hulu experience punctuated by silence rather than noise).
> It's not really the API which breaks, it's the versioning.
It is definitely the API which breaks in many cases. These 6-week updates change APIs, both Web APIs (used by both websites and addons) and internal APIs.
For example, websites - not addons - can and do break with Firefox and Chrome 6-week updates, because even Web APIs are changed in these rapid updates.
It is true that versioning is a problem as well, however.
Firefox has been forced to follow Chrome on this AFAIK because otherwise some website features (popular ones.. specially GDocs) wouldn't work optimally. Even right now, loading Google sites is faster (specially GMail) on Chrome because only Chrome has SPDY support (coming in a Firefox near you in some weeks thanks to the fast release mechanism!)
The Web APIs aren't stable at many levels, and HTML5 ain't standard. It's a bunch of drafts and some are even conflicting (hello audio APIs).
It seems to me that Google is the main company right now pushing in new drafts and protocols - using it to make other browsers incompatible. Generally the drafts are technically fine and good, the issue is the way they're used to kill diversity and obtain complete web (or "internet") control.
You can start to see a lot of "you need Chrome to see this website. Chrome, the fastest browser on earth by Google! <click to download>.
Specially true if you use Opera or IE which do not update as often as Firefox and Chrome.
Firefox does have a new versionless API, called the bootstrap API. It also allows extensions to stop, start and hence update, without restarting firefox.
I don't see silent updates in FF10 yet.
True silent ones are only possible if you move the install into the Roaming area, otherwise win7 with resonable security settings will ask for confirmation.
It's important to note that, yes, it is true that some IT department are reactionary and dislike the new release process, BUT that doesn't mean that are right.
There are plenty of analogous automatic update systems which are used every day in IT departments. Virus checkers are the canonical example, but increasingly SAAS applications are the same.
Many IT departments are stuck in a 1999 mode of trying to control the exact version of every software they run.
Fortunately businesses are wising up - firstly IT tried to tell them they couldn't use iPhone because they "weren't approved". That worked until the CEO demanded one.
Now some try and say rapid browser versioning and automatic releases are bad. They'll get over that, too, or otherwise they'll be ignored.
(And don't bring up the example of the IE6 websites that must use IE6 forever more. That's a problem to solve, not an excuse for keeping an entire enterprise locked to outdated technology.)
You're just wrong. There are several very good reasons why the 1999 mode is both useful and important, at least for the time being (and the next several years). Here is a brief list:
- Cross-testing. My team is responsible for roughly 150 enterprise apps of varying scale, platform, age, and quality, ranging from a few disgusting classic ASP apps to monstrosities we pay nearly $1m/yr in licensing fees for. It is neither feasible nor the best use of people's time to keep up with 12wk release cycles.
- Security. There are good reasons why not to allow local admin privileges for most users. Chrome is the first browser we've deployed that we've allowed auto-update to remain enabled, and if it didn't provide silent updates that didn't break extensions AND install in user space, we'd never have been able to do that.
- Antivirus. I'd have thought you'd know this based on the verbiage in your comment, but apparently not. Enterprise AV doesn't work like consumer AV. An orchestrating server software is installed, at which configurations are defined and from which rule sets are distributed to clients.
- Big ERP. As an example, Oracle ERP isn't compatible with every version of Java, and god help you if your users are running Linux and get confused between the official JRE and independent distributions like OpenJDK & Iced Tea. If your apps team has built extensions/interfaces to the ERP that also rely on Java, it's entirely possible or likely that they're dependent on a specific version & patch number, too.
I could go on for hours.
I don't think anyone -- at least none of my peers or colleagues -- would say rapid browser versioning & automatic releases are bad. Not being able to manage them can be risky. We have recently standardized on Chrome, but have deployed Firefox 8 as a fallback just in case, and our Windows users have IE8 (or 9, in the case of the few running Win7). For both Firefox & Chrome we included IETab in the MSI we distributed, customized with rules based on app compatibility. We also distributed a custom PAC file with proxy rules. Coincidentally, most of the web developers -- even if they prefer Chrome for browsing -- still prefer Firefox for dev & testing due to the superiority of Firebug & a few other add-ons.
I've always wondered----why can't you just install two browsers?
The old IE6 browser that can run your ancient intranet apps, and the new Chrome that can run the new SaaS apps. The new one auto-updates, and the old one doesn't.
Clearly IT departments are capable of supporting multiple programs since that's what they do when someone purchases native software instead of a ASP app.
Most companies do. IE & Safari come with their respective OS, and if you're a Windows shop you're probably going to also install either Chrome or FF. We had been standardized on FF until they expedited their release cycle, which made keeping current too much work (this will change once it updates silently without breaking add-ons), but since we were a Google Apps shop anyway, this doubled our resolve to switch to Chrome. We kept FF around as a fallback in case we ran into situations where Chrome didn't work (Juniper SSLVPN meetings in Windows, for example). We actively try to prevent users from accessing IE (removed shortcuts from desktop & Start menu, etc), btw, except for the couple hundred users who actually need it to run legacy apps we have no control over.
Note: about 80% of our employees with computers don't have internet access at all, with the exception of a proxy rule that allows them to access Google Apps (and a few other select SAAS apps). You can imagine this complicates things a wee bit.
You can't run IE6 on a modern version of Windows. You can run it in a VM, which is Microsoft's "approved" approach (they provide old version of browsers for this kind of thing)
Most people don't understand the "old IE6 app" issue - it actually applies to a very, very small number of apps. It isn't that these apps don't display in other browsers because of bad HTML - it is because they use weird IE6 only technologies. Microsoft came up with some very strange things over the years (look at Data Islands: http://msdn.microsoft.com/en-us/library/windows/desktop/ms76...), and fixing these apps isn't just HTML tweaking. Of course, if you still have a Data Island app around these days your IT department should be fired...
Do you know that security wise, since Chrome does not need administrative privs to install it means any bug, trojan, etc, can replace the Chrome binary and use it to capture/control/send/etc anything users are running?
That's the main reason why app INSTALLS should require admin privileges in general.
That's also why Chrome model for updates is a double-edged sword, and security wise its bad.
For Entreprises, you should be able to manually push out Chrome updates without getting any admin prompts or the need for admin privileges.
Regardless, for non-Entreprise use, seemless update of the browser is something one wants to have.
AFAIK Firefox plans to have an authenticated updater service running for that. It means you can't subvert the Firefox binaries to capture/control/whatever the user's pc as you need admin privileges to upgrade.
And the updater process is a tiny process that verifies signatures before upgrade, thus the likehood that it gets compromised or has bugs is very low (specially compared to browsers which are one of the most complex piece of software ever made)
I just think it is totally, absolutely and completely wrong.
I think that the "risk-averse" nature of corporate IT doesn't serve business, it holds it back.
Things like "custom ERP extensions" are excuses. If a business builds it's own software, then it should expect to maintain it.
(WRT the anti-virus thing: yes, I understand this. I also know how this really works in 95% of businesses - the vendor sends a new virus definition file, and IT rolls it out to the business when they get in the next day. In another 4.9% of businesses someone will load the definitions on a SOE desktop, check it reboots and then roll it out. It is only in that 0.1% of businesses (if that!) where IT actually adds any value to the virus definition rollout process at all. In all other cases they remove value by holding back updates until that are run through the "IT process")
IT departments need to stop complaining and get their act together.
That, and enterprise software firms should stop charging an arm and a leg for updates, and stop making software that will only run in IE (6). If you buy that software, shout at your boss, not at Firefox or Chrome.
From my understanding there will be a single one-off UAC popup which will allow a service to be installed with higher rights - that service will then carry out installations from that point on, and will be able to do so silently, as it will have the rights to do so.
Chrome avoids it by installing into the User's own folder. Firefox is installed in Program Files, which requires user authorisation.
Arguably, this is the correct place to install, as it means that the application is usable by anyone on the PC, rather than having to be installed for each user individually.
Chrome does a non-standard install and also can be self modified which isn't secure. Chrome could be replaced by a keylogger+chrome by anything running on the system.
That's why admin privileges are required for accessing Program Files to begin with.
Using a separate updater process is actually the clean way to go, on Windows.
