Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yeah, as far as I understand, cookies is the only storage method that will be left to use for long-term storage of user data. If I'm wrong, someone please correct me.

Edit: getting downvoted without any reasoning provided, so I assume I'm incorrect, there are more/less ways of storing data in the future for Safari users?



Not sure if this answers that, but: https://webkit.org/blog/8613/intelligent-tracking-prevention...

Cookies can either be set in HTTP responses or through the document.cookie API, the latter sometimes referred to as client-side cookies. With ITP 2.1, all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry.


Cookies expire in the same way.


With cookies you can set the expire time yourself, as a developer. And looking at the list of the original blogpost from webkit (https://webkit.org/blog/10218/full-third-party-cookie-blocki...) it shows the following will be affected by the 7 day cap:

Indexed DB, LocalStorage, Media keys, SessionStorage, Service Worker registrations

Since cookies are not mentioned, I'm assuming it's NOT affected by the 7 day cap but will instead continue to work as normal (except for the fact that 3rd party cookies will stop working, which is a Good Thing)


If the cookie is set by http headers, yes. If it's set with client side js, though, it's capped at 7 days (since ITP 2.1).


Does this mean I'll soon be setting up an dummy "cookie maker" endpoint on my server that turns XHR body data into HTTPS cookie data as a workaround? :/


Interesting, I did not know that. Thanks for clarifying!


What if you have a cookie set by http and try to update it with js? Will it self-destruct now?


Technically, when you update it via js you're overwriting the existing cookie with a new one. And, from my understanding, it's then subject to the same restrictions as any other cookie set client side.

So in order to have a long-lived cookie, you essentially need to treat them as read-only client side, and push any and all update/write logic to the server such that it'll return a set-cookie header with any changes you require.


I would guess is works, but expiration is capped at today + 7 days.


Secure + HttpOnly do not expire at 7 days. These are invisible client-side.


great, sounds like we‘ll get to consent to storing cookies more frequently - everybody loves these banners. there’s even more fun to be had, thanks to GDPR dialogs with 73 nested toggles.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: