Comment by STRML | Hacker News Reader

Comment by STRML | Hacker News Reader

Parent Full thread

It is not that simple. Cookies can have attributes such as "HTTPOnly" (don't allow access from JavaScript), "Secure" (only send on TLS-enabled sites), and expiry. While it may seem possible to replicate some of these with JavaScript, there are a few problems:

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.

> Not everybody has JS enabled (your content site shouldn't require it)

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.

Name a localstorage auth mechanism on 1st request ?

If you don’t already have a valid session cookie name a cookie solution to first request authentication.

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.

> "Secure" (only send on TLS-enabled sites)

localStorage treats http and https as separate sites.

Reply on news.ycombinator.com