| ▲ | AshleysBrain 5 days ago |
| 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. |
|
| ▲ | flotwig 5 days ago | parent | next [-] |
| It's funny that you mention NewCookie, there is actually a deprecated Set-Cookie2 header already: https://stackoverflow.com/q/9462180/3474615 |
| |
| ▲ | h4ck_th3_pl4n3t 5 days ago | parent | next [-] | | Imagine pwning a frontend server or proxy, spawning an http/s server on another port, and being able to intercept all cookies and sessions of all users, even when you couldn't pwn the (fortified) database. This could have a huge advantage, because if you leave the original service untouched on port 80/443, there is no alert popping up on the defending blueteam side. This gives me an idea for a project... | |
| ▲ | nghia999 5 days ago | parent | prev [-] | | [flagged] |
|
|
| ▲ | RadiozRadioz 5 days ago | parent | prev | next [-] |
| NewCookie is, roughly, what browser Local Storage is. At least for some use cases. Of course, it doesn't directly integrate with headers. |
| |
| ▲ | graypegg 5 days ago | parent [-] | | I think one important use case we have for cookies is "Secure; HttpOnly" cookies. Making a token totally inaccessible from JS, but still letting the client handle the session is a use case that localStorage can't help with. (Even if there's a lot of JWTs in localStorage out there.) | | |
| ▲ | emn13 5 days ago | parent [-] | | However, potentially a localStorage (and sessionStorage!) compatible cookie-replacement api might allow for annotating keys with secure and/or HttpOnly bits? Keeping cookies and localStorage in sync is a hassle anyhow when necessary, so having the apis align a little better would be nice. Not to mention that that would have the advantage of partially heading off an inevitable criticism - that users don't want yet another tracking mechanism. After all, we already have localStorage and sessionStorage, and they're server-readable too now, just indirectly. On the other hand; the size constraints on storage will be less severe than those on tags in each http request, so perhaps this is being overly clever with risks of accidentally huge payloads suddenly being sent along with each request. | | |
| ▲ | xp84 5 days ago | parent | next [-] | | I think if I were implementing a webapp from scratch today I'd use one single Session ID cookie, store sessions in Redis (etc) indefinitely (they really aren't that big), and for things meant to be stored/accessed on the frontend (e.g. "has dismissed some dumb popup") just use local storage. Dealing with anything to do with cookies is indeed incredibly painful. | |
| ▲ | mdaniel 5 days ago | parent | prev [-] | | > and they're server-readable too now, just indirectly. Could you point me to more reading about this? It's the first time I've heard of it | | |
| ▲ | graypegg 5 days ago | parent [-] | | I think they mean that you can always send back the content of a localstorage property with javascript grabbing the value and sending another request back with it in the body. Since the front end is going to run any javascript the server sends it (disregarding adblockers at least), it's sort of a more indirect version of Set-Cookie. | | |
| ▲ | emn13 5 days ago | parent [-] | | Yeah, that's what I meant. There's no built in support; but it's indirectly readable since client-side JS can read it. | | |
| ▲ | j16sdiz 5 days ago | parent [-] | | This miss the "HttpOnly" part, which prevents javascript (think script injection vulnerability) from touching this part of the storage |
|
|
|
|
|
|
|
| ▲ | notatoad 5 days ago | parent | prev | next [-] |
| i think the main problem there is that cookies are so intractibly tied up with tracking, any attempt to create better cookies now will get shut down by privacy advocates who simply don't want the whole concept to exist. we're stuck with cookies because they exist. |
| |
| ▲ | doctorpangloss 5 days ago | parent [-] | | Every privacy advocate I know hands over exquisitely detailed private and personal information to Google and/or Apple. It seems unfair to generalize as “privacy advocates” so much as it is people who are anti-ads. Being anti-ads is a valid opinion. It has less intellectual cover than pro “privacy” though. |
|
|
| ▲ | bob1029 5 days ago | parent | prev | next [-] |
| The DOM & URL are the safest places to store client-side state. This doesn't cover all use cases, but it does cover the space of clicking pre-authorized links in emails, etc. I spend a solid month chasing ghosts around iOS Safari arbitrarily eating cookies from domains controlled by our customers. I've never seen Google/Twitter/Facebook/etc domains lose session state like this. |
| |
| ▲ | marumari 5 days ago | parent | next [-] | | Safari is a lot more strict about cookies than Chromium or Firefox, it will straight up drop or ignore (or, occasionally, truncate) cookies that the other two will happily accept. I had hoped when writing this article that Google would look at Safari and see that it was always strict about feel comfortable about changing to be the same. But doing so now would unfortunately break too many things for too many users. | |
| ▲ | nox101 5 days ago | parent | prev [-] | | If I open a second window or tab I expect when I go to 'myemail.com' that it knows who I am and shows me my account even though the url in the 2nd tab doesn't have any extra info in the URL |
|
|
| ▲ | cruffle_duffle 5 days ago | parent | prev | next [-] |
| 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. |
| |
|
| ▲ | nox101 5 days ago | parent | prev | next [-] |
| the new thing should be called "cupcakes" or "candies" or "snacks" or "munchies" |
| |
|
| ▲ | pavel_lishin 5 days ago | parent | prev [-] |
| That feels like that XKCD comic about now there being 15 standards. |
| |
