4 Client-Side Web Storage Options That Replace Cookies
Several standards exist for storing large amounts of data in a user's Web browser. Each has its benefits, tradeoffs, W3C standardization status and level of browser support. All are better than cookies.
Tue, September 03, 2013
CIO — Today's Web applications handle large amounts of data processing on the client side. They may even need to be able to operate offline. These demands things go a long way toward explaining why client-side data storage is vital to next-generation Web-based applications.
Until recently, however, cookies were pretty much the only way to store data in a user's browser. If a Web app needed repeated access to some bit of data, it needed to ship that data to the server, then make repeated requests to the server, or store that data in cookies.
Cookies offer only limited storage space — a maximum of 4K or 4096 bytes — so large amounts of data had to be broken into cookie-size chunks and managed explicitly and directly.
This isn't a workable approach to storage allocation and management. Obviously, a new approach was needed.
It Doesn't Take Much for Cookies to Crumble
Web browsers were originally nothing more than applications for loading documents via HTTP and parsing HTML. Shortly after the first Netscape browser appeared, however, it became obvious that much more was both possible and necessary, but that some mechanism for tracking state using the inherently stateless HTTP protocol would be needed. Lou Montulli thus implemented the browser cookie (also known as the "magic cookie") in 1994, for version 0.9b of the Mosiac Netscape browser.
Cookies, along with access to server-side scripts that the Common Gateway Interface (CGI) provided, enabled the earliest Web applications. Ultimately, this started us down a path toward browsers transforming into a universal application platform.
Alas, cookies are flawed. As noted, they can store only very small amounts of data, and they're vulnerable to numerous types of attack, which limits their usefulness for storing personal or sensitive data.
Further compounding the problem is the observation that this theoretical 4K cookie is transferred from the browser to the server; most users have asynchronous Internet connections, whereupon upload speeds are slower than download speeds. Inevitably, transferring cookie data inside HTTP headers creates unnecessary overhead.