As I pointed out in my re-write of my original responce, even if Chrome was installed in Program Files, compromising it would still give malware a persistent co

As I pointed out in my re-write of my original responce, even if Chrome was installed in Program Files, compromising it would still give malware a persistent compromise on the user. With regards to your OS-level access control, I think we have examples of how to do it without usability problems. For example, in smartphones, when apps get installed they define what permissions they need. If we assume the publisher of an app is not malicous, then their is no need for a typical user to need to know about this, and we can view it as the app saying "these are the things I am going to access, if I try to access anything else, then I have probably been compromised". The smartphone implementation seems a bit to crude to be very effective in stopping malware, however there is no reason why we should not be able to make a more fine grained system. For example, in the Linux world, we have apparmor, which does effectively the same, but is much more configurable. Still, this only requires the program to be honest at install time, and to not have write access to the apparmor configuration file; the user does not need to be aware of its existence. The problem with these systems is that programs need to do things that we do not want malware to be able to do. For example, Chrome has an auto-update feature. If it gets compromised, then the malware can overwrite the executable just as easily (unless the OS enforces code signing). Say that the program wants to be able to create shortcuts on the desktop, and save data to the harddrive. Now, if it gets compromised, the malware can save itself to the harddrive, and create a shortcut on the desktop labeled "Chrome.exe".