6 ms·

"deleted" is just a fancy word "inaccessible to the user"

callalex 2y ago
No, it really isn’t. Anyone who uses that word that way is just factually incorrect, and probably pretty irresponsible depending on the context. Software should not tell lies.
- dumbo-octopus 2y ago
  > delete: remove or obliterate (written or printed matter), especially by drawing a line through it or marking it with a delete sign Which is, indeed, what every modern database does.
  - 8organicbits 2y ago
    I think you are referring to tombstoning. That's usually a temporary process that may immediately delete the underlying data, keeping a tombstone to ensure the deletion propagates to all storage nodes. A compaction process purges the underlying data (if still present) and the tombstones after a suitable delay. It's a fancy delete that takes some time to process, but the data is eventually gone. You could turn off the compaction, if you wanted. I believe Kafka make deletion difficult, since it's an append-only log, but Kafka doesn't work well with laws that require deletion of data, so I don't believe it's a popular choice any longer (I.E. isn't modern).
    - dumbo-octopus 2y ago
      If you run a DELETE FROM in any modern sql engine, which is the absolute best you could expect when asking for a delete in the UI^, the data is nowhere near gone. It’s still in all the backups, all the WALs, all the transactions that started before yours, etc. It’s marked for eventual removal, and that’s it. Just as the definition of delete I provided says. ^ (more likely they’ll just update the table to set a deleted flag)
      - UweSchmidt 2y ago
        Imagine the data that was deleted is of the highest level of illegality you can imagine. Under no circumstance can your service be associated with that content. - What was your "definition of delete" again? - You mentioned some of the convenient technical defaults your frameworks and tools provide out-of-the-box, can you think of ways to improve the situation? (You might re-run delete requests after restoring a backup; transaction should resolve in a timely fashion, failed deletes can be communicated to the user quickly etc.)
        dumbo-octopus 2y ago
        We are missing the point here. The GP was claiming that delete meant something other than adding a mark to an item that you want to eventually be removed from the system. It doesn’t.
        UweSchmidt 2y ago
        I understand that you describe the status quo in many systems today. However, besides the technical aspect you talked about the "absolute best you could expect when asking for a delete in the UI^". I think this where I, other posters in the thread, most people, and probably the GDPR and other legislature, would disagree. We expect significantly more effort to clean up deleted data. This includes, for example, the ability to delete datasets from backups, as well as a general accountability of how often and where all the data is stored and if, and when a deletion process is complete.
        dumbo-octopus 2y ago
        > GDPR and other legislature Nope. GDPR allows deleted data to be retained in backups so long as there is an expiration process in place. Doesn’t matter how long it is. But certainly nobody has a right to forcing a company to pull all of their backups from cold storage and trove through them all any time any deletion request takes place. That’d be the quickest path to Distributed Denial of Bank Account Funds imaginable. Even the GDPR isn’t that bone-headed. But yes, it is part of the law that the provider should tell you that your data isn’t actually being erased and instead it will be kept around until they get around to erasing everything as part of their standard timelines. But that knowledge doesn’t do anyone much good. > CNIL confirmed that you’ll have one month to answer to a removal request, and that you don’t need to delete a backup set in order to remove an individual from it. https://blog.quantum.com/2018/01/26/backup-administrators-the-1-advice-to-deal-with-gdpr-and-the-right-of-erasure/ https://blog.quantum.com/2018/01/26/backup-administrators-th...
  - mdavidn 2y ago
    Every modern file system works like this too. Then there’s copy-on-write snapshotting and SSD wear leveling to worry about. Data isn’t actually destroyed until the space is reused to store something else at an indeterminate point in the future. Or when its encryption key is overwritten. But it probably is a good idea to stop returning deleted data from web APIs.
  - cottsak 2y ago
    this is why when I'm building confirm UI, I prefer the term "destroy?" on the confirm action. It's much clearer to the user that this is a destructive and irreversible action and we will be removing this data/state. *obviously doesn't apply to soft deletes.
Dylan16807 2y ago
It's tolerated for there to be temporary inaccessible copies sticking around when something is deleted. What GitHub is doing here is neither temporary nor inaccessible.
stubish 2y ago
No, deleted is a word for deleted. But we started saying things were "deleted", while our eyes flicked to the stack of backup tapes in the corner, acknowledging the white lie, because really deleting things conflicted with other priorities and was hard. And we left it there, until privacy regulations came along and it turned out not using the normal definition of deleted could get you sued. So IMO Github is wide open to paying damages to the first person able to demonstrate them.
pvillano 2y ago
"Bought" is just a fancy word for "granted a license for usage, subject to terms and conditions, which may be revoked at any time, for any reason, without any warning"

No, it really isn’t. Anyone who uses that word that way is just factually incorrect, and probably pretty irresponsible depending on the context. Software should not tell lies.

dumbo-octopus 2y ago
> delete: remove or obliterate (written or printed matter), especially by drawing a line through it or marking it with a delete sign Which is, indeed, what every modern database does.
- 8organicbits 2y ago
  I think you are referring to tombstoning. That's usually a temporary process that may immediately delete the underlying data, keeping a tombstone to ensure the deletion propagates to all storage nodes. A compaction process purges the underlying data (if still present) and the tombstones after a suitable delay. It's a fancy delete that takes some time to process, but the data is eventually gone. You could turn off the compaction, if you wanted. I believe Kafka make deletion difficult, since it's an append-only log, but Kafka doesn't work well with laws that require deletion of data, so I don't believe it's a popular choice any longer (I.E. isn't modern).
  - dumbo-octopus 2y ago
    If you run a DELETE FROM in any modern sql engine, which is the absolute best you could expect when asking for a delete in the UI^, the data is nowhere near gone. It’s still in all the backups, all the WALs, all the transactions that started before yours, etc. It’s marked for eventual removal, and that’s it. Just as the definition of delete I provided says. ^ (more likely they’ll just update the table to set a deleted flag)
    - UweSchmidt 2y ago
      Imagine the data that was deleted is of the highest level of illegality you can imagine. Under no circumstance can your service be associated with that content. - What was your "definition of delete" again? - You mentioned some of the convenient technical defaults your frameworks and tools provide out-of-the-box, can you think of ways to improve the situation? (You might re-run delete requests after restoring a backup; transaction should resolve in a timely fashion, failed deletes can be communicated to the user quickly etc.)
      - dumbo-octopus 2y ago
        We are missing the point here. The GP was claiming that delete meant something other than adding a mark to an item that you want to eventually be removed from the system. It doesn’t.
        UweSchmidt 2y ago
        I understand that you describe the status quo in many systems today. However, besides the technical aspect you talked about the "absolute best you could expect when asking for a delete in the UI^". I think this where I, other posters in the thread, most people, and probably the GDPR and other legislature, would disagree. We expect significantly more effort to clean up deleted data. This includes, for example, the ability to delete datasets from backups, as well as a general accountability of how often and where all the data is stored and if, and when a deletion process is complete.
        dumbo-octopus 2y ago
        > GDPR and other legislature Nope. GDPR allows deleted data to be retained in backups so long as there is an expiration process in place. Doesn’t matter how long it is. But certainly nobody has a right to forcing a company to pull all of their backups from cold storage and trove through them all any time any deletion request takes place. That’d be the quickest path to Distributed Denial of Bank Account Funds imaginable. Even the GDPR isn’t that bone-headed. But yes, it is part of the law that the provider should tell you that your data isn’t actually being erased and instead it will be kept around until they get around to erasing everything as part of their standard timelines. But that knowledge doesn’t do anyone much good. > CNIL confirmed that you’ll have one month to answer to a removal request, and that you don’t need to delete a backup set in order to remove an individual from it. https://blog.quantum.com/2018/01/26/backup-administrators-the-1-advice-to-deal-with-gdpr-and-the-right-of-erasure/ https://blog.quantum.com/2018/01/26/backup-administrators-th...
- mdavidn 2y ago
  Every modern file system works like this too. Then there’s copy-on-write snapshotting and SSD wear leveling to worry about. Data isn’t actually destroyed until the space is reused to store something else at an indeterminate point in the future. Or when its encryption key is overwritten. But it probably is a good idea to stop returning deleted data from web APIs.
- cottsak 2y ago
  this is why when I'm building confirm UI, I prefer the term "destroy?" on the confirm action. It's much clearer to the user that this is a destructive and irreversible action and we will be removing this data/state. *obviously doesn't apply to soft deletes.

Dylan16807 2y ago

It's tolerated for there to be temporary inaccessible copies sticking around when something is deleted. What GitHub is doing here is neither temporary nor inaccessible.

stubish 2y ago

No, deleted is a word for deleted. But we started saying things were "deleted", while our eyes flicked to the stack of backup tapes in the corner, acknowledging the white lie, because really deleting things conflicted with other priorities and was hard. And we left it there, until privacy regulations came along and it turned out not using the normal definition of deleted could get you sued. So IMO Github is wide open to paying damages to the first person able to demonstrate them.

pvillano 2y ago

"Bought" is just a fancy word for "granted a license for usage, subject to terms and conditions, which may be revoked at any time, for any reason, without any warning"