1. Not everybody has JS enabled (your content site shouldn't require it)
2. If using localStorage, users can write their own data. Depending on how you store data, this ranges from "not a problem at all" to "serious attack vector". At the least, it increases risk if an attacker gets XSS.
3. Data stored in localStorage can't be transmitted upon page load, it has to be transmitted after the initial load, once scripts have executed. For some things, this is fine, for e.g. auth, this is pretty bad.
They are different technologies: localStorage & sessionStorage are not a full replacement for cookies.
That said, tracking is rampant across the web and with it, cookies. Getting rid of them would make some of this harder - but not at all impossible - while breaking other legitimate flows.
It is just as true that not everybody has cookies enabled.
> If using localStorage, users can write their own data. Depending on how you store data, this ranges from "not a problem at all" to "serious attack vector". At the least, it increases risk if an attacker gets XSS.
Users can write their own cookies as well: document.cookie = "whatever"; Users should have control to access and edit the data they are storing on their own devices.
> for e.g. auth, this is pretty bad.
Any data that is embedded in dynamically written HTML is fully available upon page load, so you don't need cookies or any other storage mechanism to solve that problem. You only need a way to send the data in the HTTP response.
> They are different technologies: localStorage & sessionStorage are not a full replacement for cookies.
They are a full replacement unless you lack confidence writing the necessary mechanisms in JavaScript that are typically left to Spring MVC for Java developers on the server.
With a local storage solution I would embed a session hash in some dynamically written HTML or a response header that is then stored in localStorage and then on every subsequent page request in the current HTTPS session send back that session hash prepended with a salt in the https request header. Then it’s always on initial page request but only after the session is established by the server.
localStorage treats http and https as separate sites.
Cookies allow storage of 4kb data in a file per single origin policy domain. They are slow to access and require an archaic API. At one point this made sense because it’s all we had.
Local storage features an amazingly primitive API, stores 5mb per domain, and is dramatically faster to access. Local storage is achieved universal support since IE8. From a storage perspective localStorage is a complete and superior replacement for cookies.
The only remaining difference is that cookies are artifacts separate from the browser. They can be sent in a an HTTP response without either a unique HTTP request and without appending that data to another artifact, such as hidden text in an HTML file. localStorage does not have that as it is meant to be local and thus would require JavaScript to write data from an HTTP response into storage. One extra step.
In practical terms all that means is that cookies can be written by a server application by developers who lack basic understanding of browser technologies. In software we call this kind of incompetence ”accepted practice”, but other industries call it negligence. I suspect if end users sued individual developers by name every time they were harmed or violated by bad software there would be less negligence in the world.