I agree, at least afaik there is no way to construct a formal "Proof of Deletion". This risk though I believe exists with even centralized services, so for example if I ask Amazon to delete this blob of data I actually don't know if in fact they did delete it. We all just assume they are doing what they are purporting to do, because if they aren't then there could be significant legal repercussions.
In the Filecoin case, I would still think that it should be possible to guarantee that a particular object is not being actively served by a node on the network at any particular point in time and penalizing nodes (loss of Filecoin) that do not pass this check.
I disagree. Again encryption is not the same as not having access at all to the data. If centralized services offer the concept of having access control mechanisms available and we trust them to delete the files, then why not have those same types of mechanisms in place for a decentralized network? Asking people to delete their keys is user hostile and will likely lead to people just not using the service.
The ciphertext is irrelevant now, today. That might not always be the case if computing power improves sufficiently to be able to breakthrough that encryption or a flaw in the encryption algorithm (or default parameters being used in a particular implementation) is discovered. At that point, it would be nice to know that even the ciphertext was not exposed.
If your data is so important that it needs to be protected from future theoretical attacks.... what the heck are you doing uploading it to a globally distributed and decentralized platform?!
Said another way: you are trying to fit a centralized-shaped peg into a decentralized-shaped hole... wrong tool for the job.
If your use case does involve this situation somehow (?) then the only real solution is to encrypt it, as others in this thread have pointed out. There is simply no other option in an open-membership P2P network... otherwise the RIAA and MPAA would have long ago crushed BitTorrent.
I'm not trying to fit any peg into any hole. Filecoin is the one that advertises the network is for private data. It's hard to quantify the risk from future theoretical attacks and anyone that is storing private data on Filecoin (or IPFS) needs to weigh their own risk tolerance.
Other networks have implemented mechanisms for the network nodes to delete files as detailed elsewhere in this thread and I think it is entirely reasonable to say there is more that could be done at the network level to help mitigate exposure. Dealing in absolutes is a dangerous proposition.
When I say "user" here I'm talking about me the service provider being the user of the network. Instead of "user hostile", what I should have said is it "just doesn't solve the problem of access".
The concern I have is about malicious actors being able to access the raw objects held on the Filecoin network. They won't be able to do anything with the encrypted objects immediately, but I don't know that you can claim that will always be the case decades from now.
>In the Filecoin case, I would still think that it should be possible to guarantee that a particular object is not being actively served by a node on the network at any particular point in time and penalizing nodes (loss of Filecoin) that do not pass this check.
But all that would do would be to push people to do it off-network instead.
Yes, I agree. It is just a mitigation. At least though it would not be actively available on the main network. The more I think about this, the more I think being able to have some sort of reputation system for node operators would be really valuable.
