61–70 of 167 posts
Earlier quoted context omitted.
Chances of com1000 being delegated is low.
Why would it need to be designed? Email delivery depends on DNS, which is unencrypted and spoofable. Spoofing emails is also doable.
Earlier quoted context omitted.
Why not just anonymize the data instead? Not using foreign key constraint just for the sake of GDPR sounds weird.
That and why not allow null for the foreign key constraint and set it to nullify upon deletion? Or indeed, anonymise data.
So I'm torn, because I think there may just be a major problem I've not yet grown my apps big enough to suffer. Anyone have thoughts either way?
And in a naive relational database implementation, deleting a user would cascade and delete activity associated with that user.
The easiest way around this is to do soft deletes where the data stays in the db, but the flag deactivates the user's account. Looks like the NYT just did a poor implementation of a soft-delete.
Doing real deletes on user accounts is a surprisingly challenging problem and I'd be willing to bet very few companies do real deletes where all of your data is wiped permanently from the company. For legal and financial reasons, companies often need to keep track of historical user activity. If a company states in their investor quarterly report that they had 1M active users, they better be able to prove it in an au…
Well that's an understatement. NYT has the tech resources to do this a million better ways.
> investor quarterly report [...] active users
Speaking of "active user" counts, it's convenient that "jsmith1000" is plausibly an active user, whereas "jsmith(state:deleted)" is not. Hm.
I’d bet (a small amount of) money they have no ability to delete accounts at all, and it goes all the way down to foreign key constraints introduced by a well-meaning but inexperienced developer that unnecessarily couple the accounts table to many other records.
Regardless of the constraint on the key, the design fact remains that deleting a user record that might, for example, have associated transaction data (like subscription payments) is a little complex. You don't want to cascade that deletion to a record of credit card charges, but you also need to make sure that all queries respect that the user record might now be deleted - ie make it an outer-join. It's far more rob…
Note that "anonymization" has been legally found (DSB-D123.270/0009) to be acceptable to meet GDPR "erasure" requirements. However, this requires irrevocable overwriting of PII rather than just slapping 1000 on the end ;-) If they'd changed the username and email address to some random string, however, they would most likely be compliant.
Wouldn't they also need to replace saved billing details, like address and full name, to anonymized garbage?
The legal base for allowing this national rule in European law is Art. 6, 1c GDPR.
I’d bet (a small amount of) money they have no ability to delete accounts at all, and it goes all the way down to foreign key constraints introduced by a well-meaning but inexperienced developer that unnecessarily couple the accounts table to many other records.
In that case it seems simpler to introduce an IsDeleted flag than to have a convention that 1000 goes on the end of the name.
Doing real deletes on user accounts is a surprisingly challenging problem and I'd be willing to bet very few companies do real deletes where all of your data is wiped permanently from the company. For legal and financial reasons, companies often need to keep track of historical user activity. If a company states in their investor quarterly report that they had 1M active users, they better be able to prove it in an au…
Doing real deletes on user accounts is a surprisingly challenging problem and I'd be willing to bet very few companies do real deletes where all of your data is wiped permanently from the company. For legal and financial reasons, companies often need to keep track of historical user activity. If a company states in their investor quarterly report that they had 1M active users, they better be able to prove it in an au…
On the other hand, "is deleted" flags end up causing issues when you forget to put "where not is_deleted" in your queries.
Lately I've faced kind of an inverse situation - I have a system that I can't control where things are permanently deleted once in a while for multiple reasons (rogue users, aging out of old versions) and so as I accumulate information in a little data warehouse for reporting, I decided to implement an "is deleted" flag there. Eventually though, deleting from the source was turned off because it's really not necessary.