I’m sorry, I designed this poison and there is no antidote. But take it anyway…
- IPFS
 
I started my security journey by getting pushed into it kicking and screaming. Really. We built a managed FTP solution that was popular. Midsize and Enterprise customers liked it. Then this internet thing took off. Those customers suddenly realized that they were pushing a lot of sensitive data over the internet in the clear. So, they pounded on our door and we agreed, with Phil Zimmerman’s encouragement, to add PGP file encryption to our managed FTP solution. Then we did some database encryption. Then we got pushed onto multiple operating systems. Then, oh crap, we realized we needed to get serious about encryption and key management. So, we did. And we developed some other solutions with encryption for data privacy.
 
Along the way a friend got interested in blockchain. That looked interesting, it has cryptography! And Merkle trees! Wow, that was awesome. But stuff you posted to the blockchain ledger was in the clear. So, we developed an application for encryption and key management for Ethereum. That did not become a product. That’s a story for another day.
 
Some years later I discovered the InterPlanetary File System, or IPFS, developed by Protocol Labs. It also has cryptography and Merkle trees (Merkle DAG, actually)! It’s distributed and decentralized. Cool! Said the idiot who never learns a lesson the first time. This led to a managed file system application design based on IPFS, then the addition of encryption and key management, then secure and reliable messaging, then a patent filing, then learning enough go language programming to be seriously dangerous, and some other scratching and pecking. What could go wrong?
 
This:  Once you store a file on IPFS you can never delete it.
 
That’s a feature, not a bug. The IPFS designers made it this way on purpose. There is literally no way to delete a file from IPFS and its thousands of nodes. This is not because of some limitation in the programming language, or in some limitation of cryptography or of the Merkle tree architecture, or in some inherent aspect of distributed systems architecture. No, this is by design.
 
Imagine a system that publicly stores files without a delete function and what it implies:
 
-       No way to delete CSAM material.
-       No way to delete or inhibit any type of defamatory or abusive content.
-       No way to combat doxing and abuse.
-       No way to comply with GDPR and CPRA right to know/change/delete/opt-out.
-       No way to moderate users or content.
 
This is just a partial list of problems. No one is accountable, everyone is complicit. It doesn’t get any better from there.
 
I’ve heard the arguments about this technology helping to prevent censorship. I understand the application and network architecture, and this is just BS, in my opinion. This is toxic technology in the extreme.
 
I believe that if you create technology that clearly produces irreversible harm, you should bear some responsibility and accountability for that. As technologists we can’t avoid that there is a moral dimension to our work. We should own that aspect of what we do, and operate as compassionate human beings. Personally, I think the harms of IPFS in its current form far outweigh any potential benefits. Until the technology changes it should be avoided. I certainly won’t have anything to do with it.
 
Mastodon is far from perfect, but it empowers instance administrators and individual users to curate and moderate their own experience. A user can be blocked, and posts can be deleted. Toxic instances can be blocked and defederated. Could it be better? Yes, I think so. But we can already see and personally experience emotionally healthy and life-affirming communities, like this one at infosec.exchange.
 
This is the way.
 
#Web3 #Web30 #IPFS #FIL #Mastodon

Follow

@patrick_townsend

Oh, you're missing it, Mastodon and ActivityPub have the exact same issue you've identified with IPFS!

Content deletion on ActivityPub is exactly as unenforced as it is on IPFS.

Your instance broadcasts content out to other instances, and you can also broadcast a request for deletion, but the remote instances are under no obligation to actually honor the request nor prove that they have.

@volkris @patrick_townsend IMHO, IPFS goes somewhat further than ActivityPub because it implements content-addressing. Instead of relying on human-readable names (like usernames or domain names or URLs), content in IPFS is addressed by its hash. This is by design because human-readable names require intermediaries for resolution which have become an attack/abuse vector.

However, IPFS is not designed at all to guarantee the *availability* of data, even if you have the content's hash.

@volkris @patrick_townsend Deletion really is too much to ask from a system which does not provide availability in the first place. What it provides is content integrity (data cannot be tampered by name-resolving intermediaries or others) and decentralization for content providers (anyone who has the content can give it to you if you want it).

@patrick_townsend

Ultimately your problem is with specifically CIDs published via DHTs.

"Content Addressing" is here to stay. Even a GIT commit is represented by a Content Address (merkle hash). There's no better identifier for a chunk of data than it's hash. This applies to "good" information and "bad" information.

Like any other technology, CIDs can be used either for "good" or for "bad". So don't blame IPFS. The concepts going on inside IPFS are actually an inevitable step for any technological society I believe. As fundamental as going from vacuum tubes to solid state. At each point along the spectrum of technological innovation bad people will be doing bad things, and good people will be doing good things.

@volkris @nilesh
Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.