In both cases (cookie vs localStorage) you're really just storing your data as a string value, not truly a JSON object, so whether you use a cookie or localStorage is more dependent on the use case.

If you only ever need the stored data on the client, localStorage is your pick. If you need to pass it back to the server with each request, cookies.

JSON is explicitly a string serialization format.

Right, I meant it's not a JavaScript object. It's serialized into a string in any case, no matter which API you're stuffing it into. So it's a bit of a non-sequitur for the parent to suggest that it's somehow weird to store JSON in a cookie, but not in localStorage. It's all just strings.

I find it weird too. I’ve always considered cookies like very stupid key value stores.

It would never occur to me to put something more than a simple token in a cookie. A username, and email address, some opaque thing.

The idea of trying to use it for arbitrary strings just seems weird to my intuition, but I don’t really know why. Maybe just because when I was learning about them long ago I don’t remember seeing that in any of the examples.

My point is that there really is no such thing as "truly a JSON object".

Combine local storage with service worker, so you pass the data to the server if needed. Completely without setting cookies.

And if I don't want any javascript to see my values, ever? Or how do you handle CSRF?

Httponly cookie is the way, but then you just don't use json as cookie value that is send on every request.

Csrf is no problem as the data from service worker is only active on the site itself. If you speak about csrf with a website where you can't trust js, you're site is broken as xhr/fetch use the same httponly cookies and is affected as well.

Since when can you trust js?

Big websites use js and if they leak most of the time it's not a js issue.

I think the distrust of js is a personal issue.

I mean, anyone can open devtools and change the code to do whatever ... or install an extension that does it. So, since when can you guarantee that a browser client will actually do what you program it to do? In my experience, you can't guarantee anything on the client -- since forever. I was asking when/if that changed. I don't see why you would make that a personal attack?

But that a general problem, having a html only page with a form is the same problem. Only transfer what the user should see.

You need server verification for data that's important. Native programs can be changed with over programs or hex editor.

The talk was about data that is stored into cookies as json and csrf. (Cookies can be changed with devtools or extension)

Csrf is always an attack from third party against the user, if the user extract the data itself that's no csrf problem.

Because of this I thought you distrust js that can get attacked from third party, but yes js is as easy to change like .net or java programs.

You're really going to hate it when you learn about JSON Web Tokens, which exist exactly to hack past this sort of problem.

Jwt is encoded and it is used for data without a server session.

I'm not a fan for jwt and it used more often than it should, but sometimes it makes sense.

But at least they’re base 64 encoded so you don’t have to worry about the special characters

Good way to hit max header length issues. Ask me how I know.

How?

Well you see when a front end developer and a backend developer hate each other very much, they do a special hug and nine days later a 400 request header or cookie too large error is born.

(Seriously though, someone trying to implement breadcrumbs fe-only)

I'm not them, but that 419 pattern in the logs is burned into my adrenaline response: https://duckduckgo.com/?t=ffab&q=nginx+419+cookie+header&ia=...

I used chromelogger years ago that created often a too big http header over time https://craig.is/writing/chrome-logger

Are they ubiquitous? I'm no client side guru, I know I could look at makeuseof etc, but why not ask some professionals instead.

At the very least localstorage is supported across the board

No. It is disabled in many browsers when opened in private mode. Where you can have session cookies