http://www.srware.net/en/software_srware_iron.php

Simply put, the location of the application is orthogonal to the matter of how it manages its data and to suggest otherwise is, at best, misinformed. In fact, The Google Chrome “approach” actually differs very little except that [a] most, if not all, user settings are stored in files _other_ than the user’s own registry hive (irrelevant as it’s simple one arbitrary set of files vs another, all of which are under %USERPROFILE%) [b] the application is installed into the user’s profile which many – quite rightly – find perplexing. It’s bad for those using roaming profiles. It’s bad for system administrators who expect to have a modicum of control over which applications are available to their users. It’s also bad from a security point of view; application executables and libraries contained under ‘Program Files’ are not writeable by members of the standard ‘Users’ group, therefore making it very difficult for applications to be subverted by malware, or even accidentally corrupted (notwithstanding the vast numbers of consumers who unfortunately run under accounts that are members of the ‘Administrators’ group). This arrangement is subverted by placing application binaries within the profile.

It’s the same under other operating systems, such as Unix and its derivatives. A process operating under a non-root user account has absolutely no business attempting to write to /usr during normal operation, which is why only the superuser can do so. However, it will have full read/write access to the home directory.

Drawing a distinct line between applications – which need not be writable other than by users bestowed with the relevant privileges – and user data is good practice. And no, it’s not pointless to discuss it. Some people stake their livelihoods on such matters and it is unfortunate that some of these same people might otherwise be happy to deploy Chrome if Google were to get there act together. And, as someone else has already pointed out, Google’s approach here is wasteful in terms of resources. Do we really want multiple instances of statically-linked applications choking up user profiles?

Incidentally, the issue has also been raised over at Google Groups.

Simply put, the location of the application is orthogonal to the matter of how it manages its data and to suggest otherwise is, at best, misinformed. In fact, The Google Chrome “approach” actually differs very little except that [a] most, if not all, user settings are stored in files _other_ than the user’s own registry hive (irrelevant as it’s simple one arbitrary set of files vs another, all of which are under %USERPROFILE%) [b] the application is installed into the user’s profile which many – quite rightly – find perplexing. It’s bad for those using roaming profiles. It’s bad for system administrators who expect to have a modicum of control over which applications are available to their users. It’s also bad from a security point of view; application executables and libraries contained under ‘Program Files’ are not writeable by members of the standard ‘Users’ group, therefore making it very difficult for applications to be subverted by malware, or even accidentally corrupted (notwithstanding the vast numbers of consumers who unfortunately run under accounts that are members of the ‘Administrators’ group). This arrangement is subverted by placing application binaries within the profile.

It’s the same under other operating systems, such as Unix and its derivatives. A process operating under a non-root user account has absolutely no business attempting to write to /usr during normal operation, which is why only the superuser can do so. However, it will have full read/write access to the home directory.

Drawing a distinct line between applications – which need not be writable other than by users bestowed with the relevant privileges – and user data is good practice. And no, it is not “pointless” to discuss it. Some people stake their livelihoods on such matters and, ironically, some of these same people might be otherwise happy to deploy it if Google were to get their act together.

Also, as someone else has already pointed out, Google’s approach here is wasteful in terms of resources. Do we really want multiple instances of statically-linked applications choking up user profiles?

Incidentally, the issue has also been raised over at Google Groups.