News for hackers. Stuff that matters.
Re:Full third-party cookie blocking and more by dillondoyle on Tuesday March 24, 2020 @04:27PM (#22678620)
This is what we do. Store a 1st party httponly secure cookie jwt representing the user, then grab any extra data from the backend. Or just something like session cookie but persist it.

I wouldn't be surprised if this is one of the ways ad tracking tries to rebuild a universal identifier like the old urchin module. Might not be as easy as a cname but those might get blocked. It's always a game of cat and mouse. Could place uuid as 1st party httponly cookie. maybe uuid is domain scoped. then 'echo out' so accessible by 3rd party JS. Like a hash, one would need to know the global pooled uuid already and then combined with knowable domain could tie that uuid into the 2nd party tracking pool.

Re:Full third-party cookie blocking and more by dfabulich on Tuesday March 24, 2020 @05:28PM (#22679220)
1st party httponly secure cookies will be erased in seven days.

You need the user to manually provide an identifier (i.e. login) to avoid losing everything.

The user's password safe is now the only non-volatile storage mechanism on Safari.

Re:Full third-party cookie blocking and more by shakna on Tuesday March 24, 2020 @09:44PM (#22681211)
> 1st party httponly secure cookies will be erased in seven days.

httponly cookies can't be set from JS, and the seven day erasure only applies to cookies set from JS. That's why they're the recommended method for keeping a user logged in.

Re:Full third-party cookie blocking and more by johncolanduoni on Tuesday March 24, 2020 @06:10PM (#22679613)
They explicitly say 1st party httponly secure cookies are exempt and are their first recommended alternative.