NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Introduction to Isolated Storage

Applications often need to store data – traditionally file systems have satisfied this requirement for both client and server based systems. However, web applications present a new set of requirements for data storage by applications because they often consist of several components from various sources, and because these new applications often exist “on the web” rather than being installed into systems as has been the rule in the past.

So what’s wrong with conventional file systems for application storage? Data is stored in a hierarchical file system as referenced by a unique path (e.g. c:\files\my-app\file1.txt) so applications must use various ad hoc methods to locate their own area on any given system, and to avoid interfering with the data of another application that might happen to have the same name or use the same area. The design of these systems provides no help for applications as to how they should parcel up space, since the architecture dates back to the days of static pre-installed applications on single systems – often where most or all applications were made by the same people, in which case it is easy to avoid these pitfalls. However, in a world where applications and components come from many different sources and need to work together smoothly (without cross-interference) in all combinations, these ad hoc techniques (i.e. hope you have chosen a unique path for your application’s data) break down quickly.

What are the security implications of using file systems for application data? From a security standpoint, file systems have an inherent weakness in that data written by one application for one purpose is potentially exposed to other applications, including possibly malicious use of the data. Certainly with security mechanisms such as ACLs (access control lists that say who can use what files) some protections exist, however: (a) current implementations restrict what users can use what files – leaving unaddressed the problem of unwanted access by code even running within the context of a trustworthy user; (b) security is only possible to the extent there is active and thorough administration. For example, for any new application and administrator needs to assign it a unique path for its files, configure the application to only use files in that area (which can’t be enforced normally), and then ensure that security is setup properly on all systems before the application is allowed to run there. With web applications this represents a large expenditure of effort, if it is really feasible at all.

Isolated storage provides a configuration-less data store for applications. Data compartments are defined based on the identity of the application or component code – there is no need to conjure unique paths to ensure that data storage of different applications does not overlap so long as the identities are unique. Administrators can limit how much storage applications may have based on trust, plus set an overall size limit to prevent disk-full errors when many pieces of code compete for available resources.