HTML5 Local Storage Revisited

Originally published at: http://www.sitepoint.com/html5-local-storage-revisited/

Local storage is part of the HTML5 Web Storage API and it allows you to store data on the browser. Unlike cookies, data stored using local storage isn’t sent back to the server. All data stays on the client, and you can currently store from 2MB to 10MB. This limit is tied to the specific browser, protocol (HTTP or HTTPS), port, and top level domain in use.

In this article, we’ll discuss how to use this API to improve the performance of a website. I’ll assume that you know what local storage is and the methods exposed, so if you need a refresh I suggest you to read the article An Overview of the Web Storage API.

Available disk space

Before we start the discussion, I want to give you an overview of the available disk space in major mobile and desktop browsers. The following tables are based on the article Working with quota on mobile browsers.

Continue reading this article on SitePoint
1 Like

Thank you for this article. I have not used localStorage in a production environment - I’ve only played around with it a bit, and I do love it.

However, I did learn something about localStorage (and, by default, sessionStorage, too) that is something to be aware of.

If you clear your browser cookies, local/sessionStorage is not affected. HOWEVER, if you clear the browser history, all of local/sessionStorage is cleared.

So, if a user clears their cache and cookies on every exit, you’re site/app is safe with localStorage.

But if the user clears browser history on exit, localStorage is useless. Or, at least, it won’t be there the next time the user visits.

V/r,

:slight_smile:

Yes that’s true local storage gets deleted when deleting browser history, i believe it might be due to privacy issues

Local Storage is a neat concept but since it is a String:String key:value pair store you’ll need to deal with conversions when dealing with numbers, dates, maps, arrays, etc.

The 5MB Safari limit also makes large scale apps just simply not an option. However the simplicity of the API is appreciated and thus Mozilla’s localForage framework http://mozilla.github.io/localForage/ is a great alternative with a very similar (but async) API that sits on top of the more capable IndexedDB APIs.

Hopefully in time all browsers will support the Quota API and or increase the localStorage to a realistic level! :wink:

The good news for this particular issue, is that JSON is an excellent format in which to store such data.

1 Like

I know that the user (if they know how) can change the limit in FF and IE; does Safari have the same ability?

V/r,

:slight_smile:

Local storage is also a handy way of transferring data between windows or tabs, if that’s needed.

You can test the storage limit and user settings with exception handling. If referring to window.localStorage throws an error, then user security policy has disabled it. If setting a value throws an error, then you’ve exceeded the data limit. The safest approach is to use exception handling every time you use local storage.

try
{
    var storage = window.localStorage;
}
catch(ex)
{
    //storage is disabled by user settings
}


try
{
    storage.key = value;
}
catch(ex)
{
    //set would exceed storage quota
}

JSON is very useful, but JSON itself is expensive to parse – if the data is complex and hierarchical, then yeah, JSON is a good choice. But if it’s just a bunch of simple values, then it’s better to use a simple delimiter (like comma) and parse that manually.

But in that browser cache vs local storage graph, are the colour codes the wrong way round, or am I missing something? The written conclusion is that local storage is faster, but the graph shows that browser cache is faster in every case.

It’s also worth noting potential race conditions with local storage:

storage.key = value;

console.log(storage.key);    //may be undefined

In practise, I’ve only ever encountered this problem once, with immediate set and read like the example above. I solved it with a 1ms timeout, but even that was probably way more time than it really needed.

Probably the best way to handle it. But I’m currently using an alternative approach.

var strge = (!!window.localStorage) ? "localStorage" : "cookie" ;
var storage = (strge === "localStorage") ? window.localStorage : false ;

Then,

if(!!storage) { do localStorage stuff; } else { do cookie stuff; }

V/r,

:slight_smile:

Interesting. But if the data you’re using is small enough (and doesn’t matter if it’s sent in network requests), then why not just use cookies for all?

Security. Cookies, even if set for only a specific domain, can be hacked (if a hacker or script-kiddie know what they’re doing.) local/sessionStorage is more difficult to intercept (not impossible, just really, really, really difficult.)

Although, I understand that local/sessionStorage can be set by the developer to be available to specific domains.

V/r,

:slight_smile:

That’s kind of my point though – storage and cookies have different features. So what possible use is a function that falls back to cookies if storage isn’t available?

Y’know what… I don’t care, anymore. You’re the second person in one day to give a semi-snarky response to my thoughts.

Don’t agree with it. I don’t care.

I really shouldn’t be using company time to do non-work-related things, anyway.

:slight_smile:

Mate, I wasn’t remotely snarky. I’m simply discussing your approach with you.

The lady doth protest too much, methinks

1 Like

Perhaps listing the differences would be useful. The main two I can think of are:

  • The difference in the amount of space available.
  • That cookies get sent to the server and local/session storage doesn’t.

Yeah, those two differences are the significant ones.

Cookies only give you 4K, which is obviously a lot less than 2-10MB!

Cookies can be written and read by the server, but storage is client-side only (although Node.js has a storage extension with the same syntax, and that data can be passed across the network).

The network difference also gives rise to a minor security benefit, in that local storage data can’t be intercepted by man in the middle attacks. But local storage isn’t secure storage, and it’s just as easy for users to modify their own storage data, eg. to modify stored credentials in order to assume another identity (if they know the other identity’s credentials). And of course it’s just as vulnerable to XSS attacks as any other data.

Oh, and storage has an event which fires in response to storage changes. This event is the mechanism through which you can communicate between windows and tabs (because it fires in all instances, not just the active one; it would also make it possible to implement cross-window drag and drop with keyboard support, but that’s another article!).

I think that’s it, can’t think of anything else – unless you count browser support (obviously much wider for cookies); or the fact that local storage is way cleaner and easier to use :smile:

“local/sessionStorage is more difficult to intercept (not impossible, just really, really, really difficult.)”

If you mean “intercept” as in something between the client and server, then it is more then difficult, it is impossible as LS values aren’t sent to the server. If you mean “intercept” as in see/modify, then you are very wrong. Modifying LS values is as simple as opening up dev tools. You get a nice view of all the data and you can modify them easily enough. To be clear, that doesn’t make the feature bad, I love LS, but it is trivial for users to see how you use it.

Ray! Glad to see you, again. How’s the new gig?

Yeah, user modification - for those who even know A) it’s there, and B) how to get to it - is mucho easy. As brothercake points out, that can be used to assume someone else’s online identity for a particular site/app. But the user would have to know what ID to assume. I think encrypting the data would be a deterrent, but only for all but the most pedantic and determined.

V/r,

:slight_smile:

That’s the bottom line isn’t it – obfuscation isn’t security. It doesn’t matter how difficult it is or how determined or knowledgeable someone would have to be; if the data is exposed, then it’s not secure.

Even if you encrypted it, well then you’d have to decrypt it again – using client-side code … which the user can see, and use themselves!

Local storage is useful for a whole host of things, but secure information is not one of those things :slight_smile:

1 Like

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.