Isolated Storage
- What Is Isolated Storage?
- Using Isolated Storage
- Persisting Application Settings
- Security Considerations
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The question of where to store user-specific application settings has plagued developers since the dawn of the PC. Prior to Windows 3.1, applications typically stored settings in a configuration file in the application directory. Windows 3.1 introduced the concept of initialization (.INI) files, and their associated headaches—corruption of WIN.INI, INI droppings all over the Windows directory, and inadvertent corruption or deletion of other applications' INI files. The Win32 platform introduced the registry—a system-wide configuration database in which developers were encouraged to store application settings. However, it's a bad idea to store large amounts of data in the registry, and giving just anybody write access to the registry poses a serious security risk. The registry is a fine place to store application configuration data that system administrators control, but it's not a good place for user-specific application settings. In .NET programs, those settings belong in isolated storage.
What Is Isolated Storage?
According to the .NET definition, "Isolated storage is a storage mechanism that provides isolation and safety by defining standardized ways of associating code with saved data." The isolated storage subsystem standardizes access methods, provides security by preventing other programs and users from accessing application-specific data, and supplies tools that help system administrators configure and control the storage space. Isolated storage provides a standard, flexible, and (to an extent) secure location for an application to store its settings—a place where other applications can't inadvertently overwrite or delete.
How Isolated Is It?
Access to an isolated storage file is always restricted to the user who created the file. This setup prevents users from inadvertently overwriting or deleting application settings that were created by other users or programs. The .NET runtime uses the operating system user-identity mechanism to support this isolation. In addition to user isolation, storage can be isolated based on the assembly (a DLL that contains all kinds of .NET-specific stuff), or on the combined application domain and assembly. () By combining user, domain, and assembly, the .NET framework provides these two types of storage isolation:
Isolation by user and assembly. Data isolated by user and assembly can be accessed only by the user who originally created it, and only from code that resides in a particular assembly. This type of isolation is useful if you have multiple applications that need to access the same configuration data for a particular user. If you create a separate assembly that accesses the isolated storage, any application that calls the assembly can access the data for that user.
Isolation by user, domain, and assembly. Isolation by user, domain, and assembly is more restrictive. In addition to restricting access based on user and assembly, the runtime ensures that the only application that can access the data is the application that originally created it. This type of isolation prevents data leakage between applications, as well as data corruption by other applications.
When To Use Isolated Storage
With the few exceptions noted below, you should use isolated storage anytime you need to store user-specific application settings. These situations cover a wide range of possibilities:
Downloaded controls. Controls downloaded from the Internet don't have permissions to access the file system, but they do have isolated storage permissions. Isolated storage is the only way that these controls can persist user-specific data without requiring that the system administrator grant more permissions to the code.
Web application storage. Web applications have the same I/O limitations as downloaded controls, and so must use isolated storage for any kind of persistent data storage.
Shared component storage. As I pointed out earlier, isolated storage is an ideal way to persist data between multiple applications that all use the same settings for a particular user.
Standalone client application storage. Although standalone applications typically have full access to the file system and the registry, isolated storage is usually a better choice for user-specific settings because using it prevents inadvertent corruption of one user's data by another user. It also provides a standard location for settings, thereby making it easier to secure application directories.
Server application storage. Server applications can impersonate the logged-in user to persist user-specific settings. This provides the same level of isolation for server applications as for standalone client applications, preventing data leakage between users.
Roaming. Because isolated storage data is stored in a user's profile directory, enabling roaming profiles makes all of the user's application-specific storage available to that user, regardless of the computer on which the user is logged in.
Of course, there are a few situations in which you shouldn't use isolated storage:
Storing high-value secrets. Don't use isolated storage to persist unencrypted keys or passwords, or other secret information. Isolated storage files are stored on disk (see the Microsoft documentation for the location), where they're vulnerable to snooping or corruption by unmanaged code, highly trusted code, and trusted computer users.
Administrator settings. You shouldn't use isolated storage to persist configuration and deployment settings that are controlled by administrators.