Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Handling cookies is a minefield

grayduck.mn

Post reply on HN
Print view View original

11–20 of 270 posts

Re: Handling cookies is a minefield

#11

Post by jerf »

minitech wrote: post #9
jerf wrote: post #3

And the article isn't even about the proliferation of attributes cookies have, that browsers honor, and in some cases are just mandatory. I was trying to explain SameSite to a coworker, and scrolled down a bit... https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#co... wait, cookie prefixes ? What the heck are those? The draft appears to date to 2016, but I've been trying to write secure cookie code for longer…

> https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#co... wait, cookie prefixes? What the heck are those? https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#co... > For more information about cookie prefixes and the current state of browser support, see the Prefixes section of the Set-Cookie reference article. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se... (Cookie prefixes have been wi…

[flagged]

Re: Handling cookies is a minefield

#12

Post by AshleysBrain »

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.

Re: Handling cookies is a minefield

#15

Post by cruffle_duffle »

AshleysBrain wrote: post #12

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.

Needs a better name than NewCookie though. Suggestions include SuperCookie, UltraCookie or BetterCookie

Or to be slightly more serious avoid calling it a cookie and call it something else. Too much baggage surrounding the word cookie.

Re: Handling cookies is a minefield

#16

Post by pavel_lishin »

AshleysBrain wrote: post #12

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.

That feels like that XKCD comic about now there being 15 standards.

Re: Handling cookies is a minefield

#18

Post by RadiozRadioz »

AshleysBrain wrote: post #12

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.

NewCookie is, roughly, what browser Local Storage is.

At least for some use cases. Of course, it doesn't directly integrate with headers.

Re: Handling cookies is a minefield

#20

Post by marcosdumay »

jerf wrote: post #3

And the article isn't even about the proliferation of attributes cookies have, that browsers honor, and in some cases are just mandatory. I was trying to explain SameSite to a coworker, and scrolled down a bit... https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#co... wait, cookie prefixes ? What the heck are those? The draft appears to date to 2016, but I've been trying to write secure cookie code for longer…

Well, prefixes are opt-in. You don't have to keep-up with them.

The only recent large problem with cookies were to changes to avoid CSRF, those were opt-out, but they were also extremely overdue.

All of the web standards are always gaining new random features. You don't have to keep-up with most of them. They do look like bad abstractions, but maybe it's just the problem that is hard.

Post reply on HN