Doesn't Google Chrome run under %AppData% in a default (non-MSI) install? (This is how it's able to silently update itself, even when run as a non-administrator.)
Yes, and from a security point of view it should be treated as hostile accordingly.
There is no need to actively circumvent Windows security like this. Firefox, among many other examples, is quite capable of automatically updating itself using a proper Windows service mechanism.
It's long past time that Google were called out on this one. Not only is it a potential security risk, it also interferes with backups of %AppData%, which is generally an area of Windows PCs that you do want to save regularly in case of disasters.
ClickOnce-installed applications are limited to "Internet Zone" permissions. This can make them immensely frustrating to develop with, actually, since many of MS's own development frameworks fail miserably in Internet Zone even when they have no reason to do so (mostly they generate temporary files in places they aren't allowed).
I'm not sure how Google Chrome gets permissions to save files into your documents and whatnot from there - I don't recall Chrome requesting a permissions escalation during install or anything.
[1] http://msdn.microsoft.com/en-us/library/142dbbz4%28v=vs.90%2...
They have had it for ages, presumably to answer your mentioned complaints.
EDIT: If I want to run/update something (Chrome) in Userland, why should an OS security model stop me? My guess is, Microsoft have successfully confused a common business requirement with a security one.
Of course, Windows has now partially solved that with UAC. Unfortunately you can never know if you can trust the software or not though. However this does stop malware from secretly running without your permission, since it would require a UAC prompt to run. Then we get into uneducated users.
In windows there are too many ways to get elevated. And only one level of elevation.
After all, there are tons of popular projects requesting users to run "curl http://... | sudo sh" and consider that a good idea, too.
I keep trying to teach my nephews that the default answer to that question is no... but of course, "yes" is the way you get anything done.
Do you know one of the most asked questions in Mac OS X user forums from new users is how to disable root?
I fail to see the difference. Sorry.
You don't even need to do that. You should need administrator access to install software initially, but that installation process can set up a system service that handles any subsequent updates automatically. This then runs independent of any current user on the system, and therefore does not depend on their personal privileges, nor does it need to prompt anyone for permissions for every update.
Clearly there is a risk involved with any process that can automatically download code you will subsequently execute. However, with proper access control, at least a compromised application running in user space can't do things like modifying its own executable so the malware has a place to live or, more generally, anything else that the user couldn't do without elevating their privilege level.
This certainly doesn't get us to an ideal security model. As I noted elsewhere in this discussion, a user on most systems today can probably still do things like e-mailing all the sensitive work documents they can access to a hostile party with just their normal privileges. However, it does at least prevent one common kind of attack.
Every time my interent connection slows (WiFi) I know it's Chrome Updater so I kill it via Task Manager and everthing is good again.
There doesn't apear to be away to turn it off inside Chrome itself and turning off updates via the registry does not seem to stop it.
Or try Firefox!
You could say it's in its DNA
/ducks
The real problem, I think, is that Microsoft thinks requiring admin rights to write to "Program Files" is the be-all and end-all of solving the "application-environment integrity problem." That works for enterprise-wide deploys of sysadmin-supported software, but falls down for user-specific installations. On OSX, "application-environment integrity" can be enforced easily enough, since the OS delineates applications by a line called "the app bundle." OSX can (though I'm not sure it does) just disallow apps from writing into other apps' bundles without a "do you really mean it" prompt. But in Windows, the The Directory Is The Application Bundle[1], and so Windows doesn't know that this directory is special and should be protected from having other apps in other directories tinkering with it.
[1] http://blogs.msdn.com/b/oldnewthing/archive/2011/06/20/10176...