Awesome. Deploying Firefox is still not simple for network administrators due to their lack of official MSIs. If I still ran a network, Chrome would be the default browser just due to the sheer convenience (and that's probably what Google are hoping for).
Agreed, as an Admin having alternate browsers available in in an environment can be incredibly beneficial. Security/patch wise it's a real pain to maintain Firefox so this is a big advantage for Chrome.
Applying updates is nearly painless in Chrome. Just hit "update google chrome" and the update is applied, the browser is restarted in a matter of seconds with all your previously open windows and tabs are retained. The only downside is youtube videos you had open might automatically restart. Firefox has a similar update process but it's so much clunkier that it eats up far more time and effort. IE's update process is a joke in comparison to both (sometimes requiring a full restart of your system).
I think he is specifically refering to updating it in a managed environment. Applications set up correctly (e.g. Microsoft Office) can have updates pushed out over the network to all users, automatically. This isn't so easy with Firefox, but it should now be easy with Chrome.
Actually, that's not true. Chrome, unlike other browsers, installs in user space so admin privs aren't required. This isn't true for Chrome Frame, which has to be installed using admin rights (ref: https://groups.google.com/forum/#topic/google-chrome-frame/F...).
That's even worse! One of the major points of an application being installed by root is that it's protected from modification by users and programs users run.
Having the program be installed by root but not require admin rights to update, I presume. That sort of system is quite possible with services or scheduled tasks on Windows. In fact MSI can do that already as long as everything is signed.
The MSI offers a number of GPO switches so a domain admin can do things like disable auto-updates, disable extensions from being installed, black- or whitelist individual extensions, etc. You're commenting like you've never actually done this, which is probably why you're being downvoted.
By comparison, Chrome for Enterprise currently offers only about a dozen GPO switches and IE6 offers 1300, but the dozen they chose cover about 90% of possible use cases and the team is working on adding more all the time, as they are justified.
The kind of user who could modify chrome to subvert the will of administrators is the kind of user who could figure out a way around the root restrictions in the first place, most likely.
If it is a virus/exploit issue that you are worried about, my bet is that an auto-updating chrome is better protected from these than a root-restricted but out-of-date browser.
The thing holding our organization back from adopting Chrome over IE is file:// links. A small thing, but we use it to quick link to shared project directories. Chrome considers these a security threat and disallows them. My boss used Chrome for a week but when I couldn't get a solution to the file links he swapped back.
You can create a custom protocol and protocol handler to process file links including UNCs.
This recently allowed me to deploy a web application into an enterprise space with extensive dependencies on creating and editing word and excel documents (as well as pdfs).
The web application generates highly customized rtf from user submitted forms and provides links for users which, when clicked, will open word with the rtf loaded and its working directory properly set within their network file system. Therefore, the user can modify the rtf, simply press save and exit.
This is vastly superior to download / edit / upload schemes or replicating the functionality of word through this web application.
The users can access the files through UNC based methods they already understand and through the new web application. Its glue to wean the enterprise from windows binaries and UNC paths everywhere towards a unified web application.
It also very simple:
1. Name the protocol and generate links using it:
myproto:/path_to_file
3. Write a tiny handler as a binary, or even batch file, to be called by chrome when it parses the custom protocol
In the situation referenced above, the handler application just truncates out the protocol from the link and calls the shell with the resultant string. That means it properly handles all windows file associations. So, .rtf -> Word, .xls -> excel, .pdf -> acrobat, / -> file explorer.
To the user its actually quite seamless.
You do have to touch client machines once to setup the handler, but in this context its fine. This is not over the internet, but inside the enterprise.
I'd just noticed the other day that "Integrated Authentication" works on Windows out of the box in Chrome while testing a client's internal app. That's very helpful.
I'm thoroughly impressed with the Chromium authors. From their continuous build cycle (http://build.chromium.org/buildbot/waterfall/console) to their very active developer community, it's clear that they are driven to make a better browsing experience for everyone. By getting themselves into the business world, the footprint they've created in the browser market can become even larger.
Why are you so impressed about a continuous build cycle? I think continuous integration (including full build and test runs for roughly every push) should be a given for a non-trivial and widely-used desktop application, especially one that is released on multiple platforms. I don't see how that's something to be "impressed" about.
I'd argue that your default expectation should be the world as you wish it were, not the world that is. So here you shouldn't be impressed with the CI, but should instead have an unfavourable opinion towards software that doesn't. But that's just how I think things should be. :)
Businesses that are using Linux for their desktops are already in a different situation, since corporate updates and lock downs can be managed through a custom apt repository easily anyway.
From a personal and business perspective, the thing I find most appealing about Chrome is that it feels so much faster than other browsers. In practice, this means you can extend the life of old hardware which is primarily used for browsing the web, and save money from having to upgrade.
I wish Google would allow for downloading the installer via FTP like Mozilla does this with Firefox. I like it because it keeps me from ever having to launch Internet Explorer.
this is the free crack to get em hooked before they drop chrome os on the enterprise.
in all reality, i have been on google apps deployments where chrome was being adopted and there was no easy way to push it to 1000s of users, let alone configure and manage. this will really make life easier for admins transitioning to google apps who choose to adopt chrome as well.
not to mention google is providing support for chrome to those who have google apps for business.