201–210 of 270 posts
Earlier quoted context omitted.
You just described how the whole web operates. It works just fine.
Even if you want client side, we have better ways now than cookies.
Earlier quoted context omitted.
So the problem with Postel's law is that people don't follow Postel's law?
The problem is that it's a prisoner's dilemma. And you can't cooperate on a prisoner's dilemma against the entire world.
Doing otherwise will require cooperation to adjust on the specificities clients expect, and you fall into the trap of the prisoner dilemna.
That is a bit of a minefield, I agree… The way around this, as a developer, is URL-safe-base64 encode the value. Then you have a bytes primitive & you can use whatever inner representation your heart desires. But the article does also note that you're not 100% in control, either. (Nor should you be, it is a user agent, after all.) I do wish more UAs opted for "obey the standard" over "bytes and an prayer on the wire"…
Earlier quoted context omitted.
The closest thing is https://en.wikipedia.org/wiki/Scone .
I've had something (in the US) that was called a "scone", and it was rigid, which disqualifies it from being similar to a biscuit in my mind. Is that generally true of scones?
The article mocks Postel's law, but if the setter of the cookie had been conservative in what they sent, there would have been no need for the article...
> The article mocks Postel's law As they should. Postel's Law was a terrible idea and has created minefields all over the place. Sometimes, those mines aren't just bugs, but create gaping security holes. If your client is sending data that doesn't conform to spec, you have a bug, and you need to fix it. It should never be up to the server to figure out what you meant and accept it.
You can see that in the case where ASN.1 data need to be exchanged. You could decide to always send them in the DER form (conservative) but accept BER (liberal). BER is still an unambiguous encoding for ASN.1 data but allow several representations for the same data.
The problem with BER mainly lies with cryptographic signature as the signature will only match a specific encoding so that's why DER is used in certificates. But you can still apply Postel's law, you may still accept BER fields when parsing file. If the field has been incorrectly encoded in a varied form which is incompatible with the signature, you will just reject it as you would reject it because it is not standard with DER. But still, you lessen the burden to make sure all parts follow exactly the standards the same way and things tend to work more reliably across server/clients combinations.
Cookies seem to be a big complicated mess, and meanwhile are almost impossible to change for backwards-compatibility reasons. Is this a case to create a new separate mechanism? For example a NewCookie mechanism could be specified instead, and redesigned from the ground-up to work consistently. It could have all the modern security measures built-in, a stricter specification, proper support for unicode, etc.
the new thing should be called "cupcakes" or "candies" or "snacks" or "munchies"
IT IS a mess, but I never saw json inside a cookie. For json I use local storage or indexeddb.
You're really going to hate it when you learn about JSON Web Tokens, which exist exactly to hack past this sort of problem.
I'm not a fan for jwt and it used more often than it should, but sometimes it makes sense.
Earlier quoted context omitted.
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.