How to reliably and safely store data associated with a chunk of executing code persistently troubles secure computing in the Windows world. Giving the code permission to read or write disk files is risky -- even the controlled environments of Web browser cookies have exposed risks -- and allowing access to the Windows registry exposes yet another set of risks. So the choice largely has been between limiting benefits to the code's user in the name of safety or giving even friendly code carte blanche access to a system.
Isolated Storage is one of Microsoft's responses to this problem in the .NET framework. Conceptually similar to the persistence behaviors in Internet Explorer, isolated storage provides a secure sandbox location for data associated with the specific assembly with which it was created. When isolated storage permissions (IsolatedStorageFilePermission) are granted to an assembly it gets a limited set of permissions that do not include reading and writing files. Isolated storage might be used by an application to keep activity logs, save settings, or save state data to disk for later use.
Isolated storage consists of a set of types and methods supported by the .NET Framework for local storage. In essence, each assembly is given access to a segregated storage on disk. No access to other data is allowed, and it provides a convenient way to specify unique space for storage without the need to determine file paths. The actual location varies by Windows version, whether user profiles are enabled, whether the version of Windows was upgraded from another version, and other factors.
When using isolated storage, applications save data to a unique data compartment associated with some aspect of the code's identity, such as its Web site, publisher, or signature. The data compartment is an abstraction, not a specific storage location. The compartment consists of one or more isolated storage files called stores, which contain the actual directory locations where data is stored.
The amount of storage space available to an assembly is determined by the source of the assembly. So by default code downloaded from the Internet has less storage than code from the intranet, and code from restricted sites zones has no access to any isolated storage. By manipulating the properties of the IsolatedStorageFilePermission object, you can control the use of isolated storage based on user and code source, as well as the amount of storage available. You can even use the UnrestrictedIsolatedStorage setting of the IsolatedStorageContainment enumeration to allow unrestricted access to all isolated storage. Not a wise thing to do in most production apps, but it does allow an assembly to enumerate the contents of the isolated storage data store.
Isolated storage doesn't exactly replace the registry or disk files, but it finally provides an easy way to save application data in a controlled environment, segregated from other system resources, without bloating the registry with random detritus.