Isn't that fundamentally impossible? There's nothing preventing someone from setting up an archive site dedicated to storing/serving deleted content.
Take the example of a traditional website or web application like Facebook. When I post content I can select who will be able to access that content and there is no way for anyone NOT in the groups I select to pull down that data even in an encrypted form.
If Filecoin operated this way, then there would be no way for anyone to archive the data, because they could not access it in the first place.
What the parent posters are saying is that there's no way to trust that your (encrypted) data won't end up landing on the hard drive of someone who chooses to capture everything that passes through said hard drive.
Whether the node itself keeps the data is kind of immaterial, if there's no technical limitation preventing the owner of the node from keeping your data.
But also, as an open-membership decentralized network, there's also no real way to incentivize node implementations to obey deletion requests.
It's helpful to think about peer-to-peer networks as if every node was programmed from scratch by the person or organization running it, to do exactly and only what that person/organization wants it to do. (Not true, obviously, but the incentives behind there being a free market of p2p node software work out similarly to if it was.)
In such an environment, why would a given node owner want to add a "read a deletion-request log, and actually-delete everything mentioned in it" feature to their node in particular? Especially if they weren't a party with their own private data stored that they were interested in ever deleting, but instead were only on the network to make money hosting other people's stuff; or because they wanted to insert public data sets onto the network?
The threat model I'm thinking about is a malicious actor requests an IPFS object that he/she knows holds data that is valuable, but that they can not decrypt. They then hold this object for a period of time till at some point they are able to break into it using improved computing power or exploiting some flaw in the implementation.
Now, you raise a good point about Filecoin being an open membership network. In my particular example, the malicious actor could just decide to run an IPFS node and start holding any data that comes to it for future malicious purposes and maybe they start pulling down specific files that they want to target directly. I don't have a solution to this other than to think that having some reputation built into the IPFS node network could help mitigate that risk. You might imagine that nodes with high reputation are trusted and it is harder(requires a lot of time/money) as a node operator to become part of that group. People might decide to only trust the highly reputable nodes with their private data and utilize all nodes for public data.
Then 3 years later all the snapshots end up on a torrent site, after you paid that whole time to "delete data".
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.
Yes, it is. If you delete the keys, nobody has access at all to the data. The ciphertext is irrelevant.
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.
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.
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.
But all that would do would be to push people to do it off-network instead.
However, I assume when a file is "unpinned" in IPFS you stop earning Filecoin for storing it? I'm not sure but I can't imagine why it would be any other way.
There's maybe a reason for the owner of a "Filecoin node" to want to delete data "on the network." But that data ends up stored on many IPFS nodes, some (many?) of those hosted by people who've never even heard of Filecoin, but are just running on the public IPFS network for other reasons (usually the same reasons someone would donate to the Internet Archive, or host a public-access Debian APT mirror.)
When you look up a file "on Filecoin", you're really looking it up from the IPFS network. Filecoin just incentivizes the insertion process. But data inserted "into Filecoin" is now on IPFS. So you have to think about what an IPFS node would (want to) do with your data.
Why would these "pure" IPFS nodes that have your data, care about deleting it in response to requests? That's not what IPFS is "for." These nodes aren't participating in the filesystem-like storage paradigm that Filecoin represents. They're participating in a "content-addressable storage" paradigm. Deletion would be a violation of the ideology that likely motivates them to run their node.
Using S3 at least means you’re in a contractual relationship with Amazon, who thus has a monetary incentive from all its customers to “do what it says on the tin”, lest they all lose faith in its claims and boycott/switch to some other object-storage provider. Amazon can do this, because it's a single coherent closed-membership hierarchical organization, rather than an open-membership p2p network which people could join for reasons at odds with the network's "designed" incentives.
Without a "Proof of Deletion", adding a deletion-request system to Filecoin would only be a mitigation against ciphertext-recovery at best—something that increases the probability that your file will be fully erased from the network—rather than a true guarantee that the entire system will attempt to achieve an explicit consensus state where the ciphertext has been purged from it.
So, if you're a system architect, why would you choose to store private data on a service (Filecoin) that can only offer a high probability of erasure, rather than one (S3) that can offer a guarantee of non-recovery?
And if it's clear that there's no reason to make that decision in favour of Filecoin, then turn that around: why, as the Filecoin or IPFS node-software authors, would you bother to add this feature, if it would be the game-theoretic dominant strategy for software architects that have this use-case to ignore Filecoin/IPFS in favor of some other solution, with or without the added feature?
-----
All that being said, I'm ignoring a distinction here that's fairly important: there are two types of private data — timely and timeless private data.
• Timeless private data would have just as much value if it was obtained years from now, as it would have if it were obtained today. (Someone's Bitcoin-wallet private keys, for example. Or compromising photos of a politician.)
• Timely private data has high value to its owner upon creation, but that value erodes over time; until, at some point, even the creator themselves doesn't much care if it gets leaked. (Apple's next iPhone design, for example. Or the source code to Super Mario World. Or military intelligence.)
There's actually far more timely private data in the world than timeless private data. And encryption, all by itself, basically solves the protection needs of timely private data. Cryptanalysis seems to only really advance in power alongside Moore's law; so anything encrypted using modern encryption technology, won't be brute-forced for a number of years yet. So you can take your timely private data, encrypt it, and stick a printout of the base64 ciphertext in the public square, if you like. By the time anyone can decrypt it, there'll be no value in doing so.
Filecoin/IPFS works just fine to hold timely private data. And since that's most private data, it actually supports the needs of most system architects just fine.
It's quite the rare use-case that requires decentralized storage of timeless private data. The fact that this type of data is so rare, though, is another strike against IPFS or Filecoin node-software developers being interested in introducing a feature specifically meant to help that use-case. Filecoin/IPFS would still be a non-dominant strategy for the timeless-private-data case, so there'd still be no point; but on top of that, it's a niche-within-a-niche.
Data retention for ciphertext where the keys, stored and distributed elsewhere, have been deleted/zeroized, is a complete non-issue.
Basically, how do you know what we are encrypting today, won't be able to have the encryption broken 30 or 50 years from now?
Why do you want this? The files are encrypted and thus illegible. To anyone without the key they look like random noise.
If you're defending against your own government, they already control the network and could hold on to your S3 network traffic until they can decrypt it.
If you're defending against an individual how would they know where to download your file from? I assume the network doesn't broadcast a connection between real life identity and the data you're storing. And if the individual can monitor your physical network, then they can again decrypt the network traffic eventually.
If you're defending against the server hosting your content, they would have to host your old data for years past you stopping the service before they could decrypt the content, which would be a massive investment.
Finally, do you have reason to believe that our current encryption algorithms will be cracked anytime soon? The last big innovation I heard was SHA-1 generating a hash collision in 2017, but even that took thousands of dollars in compute resources, and SHA-1 was known to be defective for a long time before that. I imagine if we use our best algorithms they'll hold up for quite a while longer.
So my understanding is that in the example of a decentralized app that uses Filecoin to store an IPFS object on the network the IPFS object id could be sniffed on the localhost by something like Wireshark. This way an attacker could identify the encrypted objects that are of interest to them and then independently request them from the IPFS network.
In terms of threat, I'm primarily thinking of larger criminal organizations that might target things like files containing SSNs, credit history, etc.
SHA-1 is an example, but my biggest concern comes from the potential of quantum computing to render what we consider secure today obsolete. (https://www.technologyreview.com/2019/05/30/65724/how-a-quan...)