Imagine a personal finance site storing your stock portfolio and historical prices locally, creating quick access to charting and planning tools powered by pre-loaded data. Your favorite blogging tool might already use local storage to automatically save drafts of your blog posts, checking for spelling and grammar mistakes based on locally stored individual preferences. A personalized homepage might store your selected widgets and their content locally, quickly loading your information dashboard with or without an available Internet connection.
|Flash Player 6 and above||Flash local Shared Object||100 KB|
|Internet Explorer 5 and above||userData||1 MB|
|Firefox 2 and above||DOM Storage||5 MB|
A HTTP cookie persists user data in a single browser across multiple browsing sessions, allowing a website to track items placed in a shopping cart, recognize a logged-on user, save a site preference, and more.
Cookies are limited to 4 KB of storage per domain and are a good way to persist user data for convenience or tracking. Modern web browsers contain cookie and privacy management features to wipe away stored cookies and their stored data and therefore have limited utility for continued persistence. Cookies are sent along with every request on a given domain, adding extra weight to every message exchanged between an end-user’s browser and your site, even if the cookie data is only occasionally utilized.
Browser cookies are the most common form of persisting data across multiple website visits but their limited size, common deletion, and added weight limit the usefulness of this time-tested storage method.
Flash local Shared Object
Websites can take advantage of Abode’s ubiquitous Flash Player to store data as a local shared object or Flash cookie. Flash storage objects are available in Flash Player 6 or above, reaching 96% of web users in mature markets as of September 2006.
Flash Player can store up to 100 KB per domain without any user interaction. Storage limits can be increased by prompting the user for a larger allocation. Stored data is accessible across the user’s Flash Player instances, loading stored data into Internet Explorer, Firefox, and even Flash apps such as Apollo.
It’s possible to view, delete, and change Flash cookies stored on your computer through the Flash settings manager, but most storage will occur seamlessly behind the scenes without involving the user.
Flash local shared objects provide a reasonable amount of storage across multiple browsers and applications. The Flash Player plugin requires some additional allocated system resources at runtime for a single function, but you can limit its use to only those pages on your domain requiring a local storage component.
Internet Explorer 5 and above supports data persistence using a
userData behavior. Per-document and per-domain storage restrictions vary based on a site’s security zone.
|Security Zone||Page storage||Domain storage|
|Intranet||512 KB||10 MB|
|Internet||128 KB||1 MB|
|Restricted||64 KB||640 KB|
An enterprise application has access to up to 10 MB of storage for each internal domain and Internet applications can take advantage of up to 1 MB of storage per domain, or 128 KB on every page view. These XML files reside in the user’s settings folder and will not be removed when the user clears out cookies, temporary files, or autocomplete settings in Internet Explorer.
Internet Explorer exposes a relatively large local storage component for web applications to query when needed. It’s especially useful in corporate environments, creating up to 10 MB of fast-access data for each user.
Firefox DOM Storage
Firefox 2 supports local storage based on the WHATWG DOM storage method, simply referenced as DOM Storage in the Mozilla context.
Current versions of Firefox 2 allow unlimited storage through the DOM Storage feature but future Firefox releases (post-22.214.171.124) will restrict usage to 5 MB per-domain. A website can access not only data within its own subdomain or domain, but within a given top-level domain (.gov, .com, etc.) or any requesting page, creating some interesting opportunities for shared data namespaces.
DOM Storage can queue an alert events when a browser connects or disconnects from the network, prompting a data sync once a user’s local changes are able to talk to a remote server.
The standardization process behind WHATWG DOM Storage for web applications holds promise for future implementations of browser-based storage from other working group members such as WebKit/Safari and even Google. These storage methods are very new and I expect many implementation details will become solidified in the Firefox 3 development process.
Web applications using these latest technologies can deploy an upgrade on-the-fly, initializing a new set of libraries and web page templates after examining a user’s browser and bandwidth for compatibility. Web applications such as Google Calendar might store your appointments locally, exposing this data to Google Maps or other mapping applications to plan the route to your next appointment without submitting a new server requests for the same data. Your webmail will be downloaded locally, quickly loaded even if you are on a plane.
I’m excited to see more applications start to use client-side storage available in modern browsers such as Internet Explorer, Firefox, and the Flash plugin. I’ll happily give up the space of a MP3 file in exchange for a better experience in my favorite web application. I think we’ll hear a lot more about client-side storage for web applications in the coming year.