▲ | Terr_ 7 months ago | |
For many of the most painful deletion questions, the root problem is that when the software was first made the stakeholders/product-org didn't think about use-cases for deleting things. At best, they assume a "do not show" property can be placed onto things, which falls apart when you get to legal issues that compel actual removal. | ||
▲ | tempodox 7 months ago | parent | next [-] | |
That depends on the context. In some cases you're not allowed to physically delete because you need to provide an audit trail for 10 years or so. You could move those rows into separate audit tables instead. However, that requirement should not come as a surprise. | ||
▲ | BlueTemplar 7 months ago | parent | prev | next [-] | |
But, just like this article using «physically deleted», when in practice it's not the case (the bits are just freed to be overwritten some unknown amounts of time later), does legal compliance just completely ignores this fact of actual physical deletion ??* (AFAIK it takes several passes of overwriting bits with random bits on magneto-mechanical storage to not be able to retrieve any significant fragments of the original data, and things are even worse on transistor storage, which casually makes copies of the data for wear leveling reasons.) *With the exception of state secrets of course, where we know that storage is mechanically destroyed «with extreme prejudice». | ||
▲ | buildingcrash7 7 months ago | parent | prev [-] | |
>software was first made the stakeholders/product-org Practically all building, physical and software is made for a purpose first, the process is mainly an obstacle that needs to be minimized. A piece of software is trying to solve a problem just like a door is. It's driven by economics where the recipients don't want to pay any more than they need to and someone is always willing to undercut you by cutting corners. |