Hacker News Reader

Comment by gsnedders | Hacker News Reader

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).

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.

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? :/

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.

Reply on news.ycombinator.com