Isolatated storage in Silverlight

Increasing quotas

Isolated storage is a facility that lets you read/write (transient) data without worrying about other applications accessing this data. We first introduced this in Silverlight about a year ago with the alpha release. Its support was fairly basic though, and you couldn't store more than 1mb of data per application. We have given this feature an upgrade in Silverlight 2 beta 1. Although the default limit is less than it was before (100kb instead of 1mb), you can now ask the user for a larger quota. You can do this by calling IsolatedStorageFile.TryIncreaseQuotaTo(long):

1 
2 
3 
4 
5 
6 
7 
8 
9 
10 

void OnMouseLeftButtonDown(…) {
    using (IsolatedStorageFile store = IsolatedStorageFile.GetUserStoreForApplication()) {
        if (store.TryIncreaseQuotaTo(/* 2mb */ 2 * 1024 * 1024)) {
            // The user accepted our request.
        }
        else {
            // Quota not increased… Deal with it.
        }
    }
}

This method can only be called from a Silverlight initiated action, such as a mouse-down event on a WPF object. There's no cross-browser way to tell if a user clicked on a HTML object, so unfortunately this isn't supported. We decided to only support TryIncreaseQuotaTo in response to user-initiated actions because without this restriction an app could ask for more data at arbitrary, unexpected moments. This can be both annoying and unsafe – a user could accidentally accept a request for a larger quota if the dialog suddenly takes away focus.

Silverlight will only ask the user for one of the pre-defined quotas: 100kb, 1mb, 5mb, 10mb or unlimited. This means that if you ask for 2mb, the user will actually be asked for 5mb. We do this to avoid asking the user every other second if it's ok to increase the quota by another few bytes - something the average user probably wouldn't understand.

Level of isolation

Each Silverlight application gets its own isolated store. This means that if you have two applications in the same directory, they will each get their own isolated store. This store will be accessible from every browser that's supported by Silverlight, which means you can write data in FF and read back this data in IE.

We considered using isolation per page that hosts a Silverlight application. Unfortunately this doesn't work well in shared hosting scenarios. A page at www.contoso.com/joe/foo.html can have an iframe with www.contoso.com/john/bar.html in it, and access its DOM. This means it can inject its own Silverlight application into that DOM, and thus get access to the isolated store of the other website on the same domain.

The HTML 5 spec runs into exactly this problem as well. For this type of scenario it recommends you simply do not use offline storage. Given the fact that by default you can't just execute your own code within a different Silverlight application's application domain, Silverlight should not be prone to this kind of cross-site attack.

There is a downside to Silverlight's implementation though. When hosting a Silverlight application on a server and letting third-party websites add this to their page, they would all share the same isolated store. This might not be desirable. You could work around this by using URL rewriting on the server, but you need to be careful about the potential security implications this can have.

Finally, while isolated stores are shared per application, quotas are shared per domain. This is done in anticipation of a configuration dialog we will likely be adding in a future build. Having quotas per application rather than per domain means it would make configuration a lot harder for users.