So our method of complying with user removal requests for GDPR is:

audit.record("user {user.name} removed their account", serialize(user));

user.delete();

🤦

Well, you remove the user, not the record of removing the user, right? :D

Next time the user might request removal of the record of removal... which you will serialise too.

This is so redundant. Does it comply with the policy?

@bioDan Of course it doesn't. It doesn't even comply with the law (right to be forgotten).

I don't think that's how this is supposed to work

@kamen Although I guess if you read, serialize and write it enough from database to database, eventually some service outage, bug, write error or bit flip will just forget or corrupt the record.

"Yes judge, we comply with the right to be forgotten. Our instructions for removing your account are pretty clear: Put 6 medium strength EMP devices in the back of 6 pickup trucks on every continent, park them next to the AWS datacenters in every region we're active in..."

@bittersweet
Last year, we needed to audit account deletions because of that.
We needed proof that the user was deleted.

"How can you prove that you deleted his personal data?"

So we created an audit saying "Account with the username X was removed"

That policy is jell-o

@zvyn Yeah rebuilding at the moment using encrypted payloads which contain all sensitive data, and separately a salted hash of social security number to detect returning fraudulent users. We now use centralized Auth, and on GDPR removal, we just toss the encryption key.