6 ms·

We don't soft delete payloads at Raygun (https://raygun.com https://raygun.com), for the very fact that typically if one of our customers wants to delete someth

We don't soft delete payloads at Raygun (https://raygun.com https://raygun.com), for the very fact that typically if one of our customers wants to delete something it's because they might have sent something they don't want a third party to have. We have filters and other PII filtering tools etc, but it every now and then something might be sent by mistake. Having said that, you'd be amazed how often folks ask for things to be undeleted (despite a big warning dialog). Clearly developers pervasively believe soft deletes are occurring everywhere.

Someone 9y ago
It isn’t that hard to combine soft deletes with delayed hard deletes: generate a new encryption key every day for “data deleted today”, and encrypt deleted data with it. After X days, destroy the decryption key. If you use asymmetric encryption, you can keep the group of people who who can recover “deleted data” small. You could even have an independent party generate your encryption key pair, give you the encryption key, and your customer, on request, the decryption key (I think there is a business model for a non-profit here).
- skj 9y ago
  Instead of having a key that you delete (and also build non trivial infrastructure to support), why not delete the actual data?
  - Someone 9y ago
    Because the key is smaller, it is easier to make sure you deleted every copy of that key than that you deleted every copy of the data. The data also might be part of a larger backup that you would have to take apart and reassemble in order to delete the data, or might be in a place where doing that is costly (e.g. on Amazon Glacier)
    - chc 9y ago
      It seems precisely as easy to make sure you've deleted every copy of the data as it is to make sure you've encrypted every copy of the data.
      - mehrdadn 9y ago
        Edit: apologies, seems I read way too quickly! Thanks for pointing it out.
        tkxxx7 9y ago
        You seem to be commenting out of context: > generate a new encryption key every day for “data deleted today”, The question is not can we encrypt at storage. We’re now talking about encrypting as a soft-deletion method, which means we need to know everywhere the data is stored at deletion time, whether to delete it or to encrypt it with this new “deletion” key.
        qubex 9y ago
        Thanks for raising that issue, I was somewhat confused by the mentioning of encryption as a soft-deletion method... it made precious little sense to me, but everybody seemed to go along with it and I thought I was missing something very fundamentally ’right’ about that idea. Turns out it’s not so.
- stickdogg 9y ago
  Absolutely!
gcb0 9y ago
and why offer the false sense of security? if they upload a private key, and delete because they "don't want a third party to have". do you also guarantee it wasn't seen or cached anywhere else? I dont know the details of that product, but I usually treat anything uploaded even once as compromised from that point on.
- Jweb_Guru 9y ago
  This is the same argument people used to make for why it was fine for capabilities to be unrevocable--someone could have copied the data anyway (or whatever) so there was no point in revoking it. In reality, most of the time nobody but the host of a deleted item has access to the data, has a way to tie it to the originator, and has a motive to use it, especially without significant effort. Being able to delete things is a very important feature (not to mention a legal requirement in many countries!), and it's disturbing to me how many people seem to want to justify a world where every bit of data is saved, forever.
russdpale 9y ago
That's great you guys do that. But it cant be proven, why take your word for it? Ultimately, its the trust that is ghe problem, and that is what needs to be removed eother through new technology or legislation or both.
meddlepal 9y ago
How do you handle: 1. Deletions from backups 2. Deleting material that has been deleted prior to the restoration of the backup?

Someone 9y ago

It isn’t that hard to combine soft deletes with delayed hard deletes: generate a new encryption key every day for “data deleted today”, and encrypt deleted data with it. After X days, destroy the decryption key. If you use asymmetric encryption, you can keep the group of people who who can recover “deleted data” small. You could even have an independent party generate your encryption key pair, give you the encryption key, and your customer, on request, the decryption key (I think there is a business model for a non-profit here).

skj 9y ago
Instead of having a key that you delete (and also build non trivial infrastructure to support), why not delete the actual data?
- Someone 9y ago
  Because the key is smaller, it is easier to make sure you deleted every copy of that key than that you deleted every copy of the data. The data also might be part of a larger backup that you would have to take apart and reassemble in order to delete the data, or might be in a place where doing that is costly (e.g. on Amazon Glacier)
  - chc 9y ago
    It seems precisely as easy to make sure you've deleted every copy of the data as it is to make sure you've encrypted every copy of the data.
    - mehrdadn 9y ago
      Edit: apologies, seems I read way too quickly! Thanks for pointing it out.
      - tkxxx7 9y ago
        You seem to be commenting out of context: > generate a new encryption key every day for “data deleted today”, The question is not can we encrypt at storage. We’re now talking about encrypting as a soft-deletion method, which means we need to know everywhere the data is stored at deletion time, whether to delete it or to encrypt it with this new “deletion” key.
        qubex 9y ago
        Thanks for raising that issue, I was somewhat confused by the mentioning of encryption as a soft-deletion method... it made precious little sense to me, but everybody seemed to go along with it and I thought I was missing something very fundamentally ’right’ about that idea. Turns out it’s not so.
stickdogg 9y ago
Absolutely!

gcb0 9y ago

and why offer the false sense of security? if they upload a private key, and delete because they "don't want a third party to have". do you also guarantee it wasn't seen or cached anywhere else? I dont know the details of that product, but I usually treat anything uploaded even once as compromised from that point on.

Jweb_Guru 9y ago
This is the same argument people used to make for why it was fine for capabilities to be unrevocable--someone could have copied the data anyway (or whatever) so there was no point in revoking it. In reality, most of the time nobody but the host of a deleted item has access to the data, has a way to tie it to the originator, and has a motive to use it, especially without significant effort. Being able to delete things is a very important feature (not to mention a legal requirement in many countries!), and it's disturbing to me how many people seem to want to justify a world where every bit of data is saved, forever.

russdpale 9y ago

That's great you guys do that. But it cant be proven, why take your word for it? Ultimately, its the trust that is ghe problem, and that is what needs to be removed eother through new technology or legislation or both.

meddlepal 9y ago

How do you handle: 1. Deletions from backups 2. Deleting material that has been deleted prior to the restoration of the backup?