Sencha Inc. | HTML5 Apps

Blog

The HTML5 Family: Web Storage

May 27, 2010 | Ed Spencer

HTML5We're going to be blogging about next generation web technologies for the next few weeks, as well as how they fit into an AJAX framework like Ext JS. We started with an overview of HTML5 (and the use and mis-use of the term). Now we'll dig into one of the easier and smaller pieces: Web Storage.

Two of the new APIs defined in HTML5 provide storage capabilities in the user's browser. Browser storage is nothing new—cookies have been around since 1994 and have long been used to save small amounts of data to be passed between a server and client. Cookies have a few problems however:
  • They can never be more than 4kb in size
  • Different browsers allow a different number of cookies to be created per domain - modern browsers should cater for 300 cookies but older browsers such as IE7 allow far fewer
  • Cookies are transmitted to the server on every request. Because modern internet connections are heavily asymmetric, upload is typically far slower than download and this extra weight can quickly add up
Attempts have been made in the past to improve on this situation. Microsoft introduced its userData construct as early as IE5 but, with its odd syntax and lack of support from other browsers, it never gained any traction. In the interim, Google released its Gears project with its SQLite in-browser database but again this was never standardised upon, and has since been abandoned in favor of HTML5.

The HTML5 Way

Web Storage

localStorage +
sessionStorage
HTML5 provides two new objects in which data can be stored: localStorage and sessionStorage. Collectively these are known as Web Storage. The API for each object is identical, but their long term persistence is different. Any data saved to localStorage persists across browser sessions and is available whether the user closes and reopens a window, restarts their browser or even restarts their computer altogether. sessionStorage is more transient - it persists while a user navigates between pages in a single browser window, but is lost as soon as that window is closed. sessionStorage data is not shared with other windows, but if a window with sessionStorage opens another window, the sessionStorage data is copied into the new window. Browsers implement a limit to the amount of data that can be stored in each object - the W3C recommends an initial limit of 5 megabytes per origin, though they recognise the arbitrary nature of that limitation. At this time, browsers handle this limitation differently - for example iPhone will ask the user if they wish to increase the limit to 10 megabytes. For the time being, storing more than 5Mb in either of these objects should be considered risky. Web Storage is currently supported across most modern browsers, though support for the sessionStorage and localStorage objects can vary. localStorage is supported by Chrome 5, Firefox 3.6, Safari 4, Opera 10.5 and IE8. sessionStorage is not supported in older versions of Chrome, but is in older versions of Firefox. It's worth consulting a good comparison chart before deciding on whether or not to use these objects in your application.

A Quick Example

As the API for each object is identical, this example applies equally well to either. Here we are going to use the slightly more useful localStorage. Let's say we've written a blog authoring tool and would like to save the user's progress while they create their masterpiece. We extracted the data from a form and now wish to save it for later retrieval:
localStorage.setItem("title", "My blog title");
localStorage.setItem("body", "This will be the best blog post evar!!!1");
Setting data on these storage objects is extremely simple - we just provide a string for the key and a string for the value. Importantly, we can only store strings in Web Storage - any JSON objects must be serialised on the way in and deserialised on the way out. Retrieving our data is equally simple:
var title = localStorage.getItem("title");
var body  = localStorage.getItem("body");
In the meantime, the user could have closed the window or their browser, or come back days later - our application will still work as though it was all done in a single session. Web Storage provides a simple way to clear up after we're done:
localStorage.clear();
Be careful when clearing localStorage data. Although different domains are given different localStorage objects (i.e. you can't clear another domain's localStorage), it is possible that more than one script is using localStorage on the same domain so it is better to remove your data more selectively:
localStorage.removeItem("title");
localStorage.removeItem("body");

And that's it for Web Storage — one of the simpler technologies in the HTML5 family.


The HTML5 Family

Our continuing coverage of the many technologies which make up what people refer to as “HTML5”, we call The HTML5 Family. See all our published posts here:

  1. A HTML5 Primer for the Overwhelmed
  2. Web Storage « Currently reading
  3. CSS3
  4. Web Workers

There are 11 responses. Add yours.

Vlad

5 years ago

There is a more feature-rich feature comparison chart at http://caniuse.com/ - highly recommend.

Michael Kaufman

5 years ago

Hi,

I really like ExtJS. Very impressive components.

Flash has been getting/setting 100K Shared Objects (flash cookies) since 2004. (100k = default. More space with user permission)

You can store byte arrays,value objects, bitmap data, compressed binary action script byte code etc… Compress it and you could shove megs in there (but would take a performance hit so it’s best to keep things relatively small).

Nonetheless, I’m looking forward to seeing all the browser makers agreeing on how to best implement it html5 storage some day.

Since HTML5 local storage is kept separate from js cookies (like Silverlight, Gears, Flash), it opens up a world of 3rd party privacy issues for HTML5 as these objects will likely NOT get deleted with a clear cache or delete temporary data. It will be interesting to see if privacy groups freak out about this like they did when they learned Flash had persistent cookies.

From W3C:

“6 Privacy

6.1 User tracking

A third-party advertiser (or any entity capable of getting content distributed to multiple sites) could use a unique identifier stored in its local storage area to track a user across multiple sessions, building a profile of the user’s interests to allow for highly targeted advertising. In conjunction with a site that is aware of the user’s real identity (for example an e-commerce site that requires authenticated credentials), this could allow oppressive groups to target individuals with greater accuracy than in a world with purely anonymous Web usage.”


Keep up the great work!

-MK

Michael Mullany

5 years ago

Hi Michael,

I feel like the remainder of the W3C privacy provisions should be added in the interest of completeness. It’s basically up to the user agent to do the right thing here:

FROM: http://dev.w3.org/html5/webstorage/#privacy

Blocking third-party storage

  User agents may restrict access to the localStorage objects to scripts originating at the domain of the top-level document of the browsing context, for instance denying access to the API for pages from other domains running in iframes.

Expiring stored data

  User agents may, if so configured by the user, automatically delete stored data after a period of time.

  For example, a user agent could be configured to treat third-party local storage areas as session-only storage, deleting the data once the user had closed all the browsing contexts that could access it.

  This can restrict the ability of a site to track a user, as the site would then only be able to track the user across multiple sessions when he authenticates with the site itself (e.g. by making a purchase or logging in to a service).

  However, this also reduces the usefulness of the API as a long-term storage mechanism. It can also put the user’s data at risk, if the user does not fully understand the implications of data expiration.
Treating persistent storage as cookies

  If users attempt to protect their privacy by clearing cookies without also clearing data stored in the local storage area, sites can defeat those attempts by using the two features as redundant backup for each other. User agents should present the interfaces for clearing these in a way that helps users to understand this possibility and enables them to delete data in all persistent storage features simultaneously. [COOKIES]
Site-specific white-listing of access to local storage areas

  User agents may allow sites to access session storage areas in an unrestricted manner, but require the user to authorize access to local storage areas.
Origin-tracking of stored data

  User agents may record the origins of sites that contained content from third-party origins that caused data to be stored.

  If this information is then used to present the view of data currently in persistent storage, it would allow the user to make informed decisions about which parts of the persistent storage to prune. Combined with a blacklist (“delete this data and prevent this domain from ever storing data again”), the user can restrict the use of persistent storage to sites that he trusts.
Shared blacklists

  User agents may allow users to share their persistent storage domain blacklists.

  This would allow communities to act together to protect their privacy.

While these suggestions prevent trivial use of this API for user tracking, they do not block it altogether. Within a single domain, a site can continue to track the user during a session, and can then pass all this information to the third party along with any identifying information (names, credit card numbers, addresses) obtained by the site. If a third party cooperates with multiple sites to obtain such information, a profile can still be created.

However, user tracking is to some extent possible even with no cooperation from the user agent whatsoever, for instance by using session identifiers in URLs, a technique already commonly used for innocuous purposes but easily repurposed for user tracking (even retroactively). This information can then be shared with other sites, using using visitors’ IP addresses and other user-specific data (e.g. user-agent headers and configuration settings) to combine separate sessions into coherent user profiles.

Robert

5 years ago

how’s the security of sessionStorage and/or localStorage?

Tag Ekle

5 years ago

Web Strage, perhaps the best part HTML5

Ed Spencer

5 years ago

@Robert as I mention in the article, each domain has a single localStorage object that all scripts running on that domain all share, so it is not the most secure place to store data.

Sid

5 years ago

Hey I also had a brush with webstorage I was writing an extension for Chrome. I put in a few ideas on how to make the programming simple http://mnesia.wikispaces.com/HTML5+and+webstorage.
Cause Its asynchronous so like AJAX may require similar techniques to make it work well. But it is if adopted atleast we have a standard.

konst

4 years ago

Nice Job on the Site - I have bookmarked you and will come back when I have a bit more time.

Flannaganm

4 years ago

I think its the best of HTML5 released.

EqualLogic prijzen

4 years ago

Great article! Very helpfull so thanks for sharing!

rates

3 years ago

 
Love your stuff. Just became a fan and liked your page on FB! ratetake.com

Comments are Gravatar enabled. Your email address will not be shown.

Commenting is not available in this channel entry.