[systemvoltage]

Thank you. According to a quick search [1],

""" Cookies and local storage serve different purposes. Cookies are primarily for reading server-side, local storage can only be read by the client-side. So the question is, in your app, who needs this data — the client or the server?

If it's your client (your JavaScript), then by all means switch. You're wasting bandwidth by sending all the data in each HTTP header.

If it's your server, local storage isn't so useful because you'd have to forward the data along somehow (with Ajax or hidden form fields or something). This might be okay if the server only needs a small subset of the total data for each request. """

So I guess server-side no-JS applications are going to be caught in this crossfire?

[1] https://stackoverflow.com/questions/3220660/local-storage-vs...

[ZephyrBlu]

Client side apps will be caught as well. Putting a JWT in a HttpOnly cookie is a common pattern. In fact, many people recommend this approach over localStorage for security reasons.

[qyi]

PHPBB era forums would let you authenticate by putting a session ID in the URL. No cookies needed. There are many ways to do authentication without cookies. There's also basic auth. The whole "we use cookies" thing is a weird misnomer to make laypeople understand that the website is talking about the same concept those FUD articles about web tracking have talked about (tracking can be done through thousands of different vectors, no cookies needed).

>So I guess server-side no-JS applications are going to be caught in this crossfire?

No, as nicbou said, the "we use cookies" popup seems to be only required for tracking/advertising cookies.

[sergeykish]

Both cookie and localStorage are just a way to identify session. Basically:

    GET /user/#{localStorage.id}

vs

    GET /user
    Cookie: id=#{Cookie.id}

In both cases GDPR restricts user tracking and allows storing data that's required for domain to function properly.