by Miha Markič
30. May 2007 15:33
Writing application data into Program Files folder is bad. Period. Only the files at install time should be written to Program Files folder.
Otherwise one is facing
- security issues (i.e. an application could inject code) and
- practical issues (if one is not an admin then one can't use the application since there are no default permissions for non-admins to write there - application will most probably crash).
For any other data generated by applications there are better locations, such as isolated storage. Program Files folder should contain only files needed to run, eh, programs and not the data generated by those programs. And same is true for registry: HKEY_LOCAL_MACHINE is not a place to store runtime data.
However, not many developers realize these problems and so there are a ton of applications that want to store data next to their executable files. In fact, I stumbled today upon an application that should be written correctly - e-banking for companies, which I use to communicate with my bank. The application goes by name HAL E-Bank/Personal by Halcom, a Slovene e-commerce company (software, services, certificate authority), and is used by many banks in Slovenia. One would expect that such application (written by such company), where security is important, would avoid this amateur mistake. Wrong. They store a plethora of application data in Program Files folder at runtime. Ouch. Bad, bad application. And not to mention also that their executables aren't signed.
Even [MS] realized that this is a huge problem and thus it built Vista with this in mind - providing support for running problematic applications even under normal user account and thus avoiding messing with Registry and Program files folder. The feature is named File System and Registry Virtualization (you'll find more info on Vista security here), but this is another story.
The bottom line is: Don't ever build applications that write data to Program Files folder.