How censorship-resistant is IPFS intended to be?

I am looking for persistent storage which can withstand a takedown order by a court of law, and/or an attempt by a state actor to forcibly censor a website. The goal is to create a safe repository for records of human rights violations in my country during the lockdown. I’m researching options and learnt about IPFS for the first time today. I would just like to know, briefly, whether IPFS is looking to address this need or not, and if so, what is the primary mechanism? Thank you.

1 Like

Simple answer: IPFS is not censorship resistant for now, see

I think maybe your link was removed in the email-to-Discourse translation. Could you please post it again?

Indeed, here it is https://github.com/ipfs/ipfs/issues/439#issuecomment-602072704

I disagree. Censorship evasion capabilities are incomplete, but decent. It depends on your threat model.

Wikipedia is blocked in Turkey, but is still accessible from IPFS mirrors. See this blog post for details: https://blog.ipfs.io/24-uncensorable-wikipedia/

Similarly, IPFS was used for the Referendum for Independance of Catalonia (a part of Spain). Information about it were censored by Madrid, which saw it as illegal. It censored websites, but the information was mirrored on IPFS. Unfortunately, most users back then used the HTTP gateway gateway.ipfs.io, which was also censored, but tech-savvier users avoided censorship using a regular IPFS daemon and installing the simple IPFS Companion browser extension. IPFS is now way easier to use. See: http://la3.org/~kilburn/blog/catalan-government-bypass-ipfs/

You can also setup a totally uncensorable website, by hosting your assets on IPFS and linking the domain name to your website via a “decentralised DNS”, like the Ethereum Name System. Users will need to install a browser add-on, but that’s about it. See: https://medium.com/the-ethereum-name-service/ethdns-9d56298fa38a (quite technical) or https://medium.com/the-ethereum-name-service/how-to-host-your-dapp-with-ipfs-ens-and-access-it-via-ethdns-c96046059d87 .

So, censorship can be several things:

  • You are unable to access some content. IPFS can circumvent that as seen above.
  • Your ISP is able to know what to browse. IPFS can not circumvent that yet if the ISP set up surveillance nodes. Other nodes must be able to know what you want to send it to you if they have it. This include surveillance nodes.
  • You are unable to publish what you want. IPFS ensure you can.
  • You are unable to anonymously publish what you want. An ISP with constant network surveillance could probabilistic spot you were the first provider. It would be hard to prove you were the first, though. And you can circumvent that by making a third party publishing your content (a website in another jurisdiction for example). After that, it can just spot you were another provider.
  • You are unable to use IPFS altogether. This is getting technically difficult for censors as the IPFS is increasingly similar to normal web traffic. The implementation of the QUIC protocol in IPFS nodes will strengthen that further.

(A bonus feature is that you can also interact within your local network without ever pinging the Internet.)

IPFS provides no anonymity yet (which is a delicate problem, especially when combined with the already delicate problem of P2P and if you don’t want to trust any other node of the network), but can ensure you access or publish the content you want.

Some others thought around censorship:

Hope it helps

All of your examples are not “very” valid (or require some extensive technical skills), censorship-resistant necessarilly means that you can hide/anonymize things, this is not the case with ipfs, you can detect an ipfs/dht node and block it

I agree that there are some kind of decentralized p2p censorship-resistant patterns with ipfs making it not completely trivial to block, now nobody is blocking ipfs, that’s why your examples (still) work (for now)

Read also my comment here: https://github.com/ipfs/ipfs/issues/439#issuecomment-579470257 (made after reading #281, ie your link at the end of your post, showing that you did not read what I wrote before) and the last intriguing link maybe

Decentralization, p2p does not protect you more if not designed for this, it can end up to be the very contrary

Well, some information were censored, and were then available through IPFS, so I would still argue that it helps to fight censorship. The argument of IPFS needing technical skill is also debatable as UX is not really what we are talking about. Monero is very private but needs technical knowledge to be used.

About blocking IPFS all together, the same argument can be made for TOR, which has a very distinctive pattern and yet is considered to be the standard for censorship evasion.

But granted, IPFS very much lack anonymity, and that is a problem for a large range of scenari. In particular, it is probably not suitable for OP’s use case.

I read it, but to be honest I don’t really understand it. I may lack technical knowledge about it.

I agree, I never pretended otherwise.

IPFS is not blocked because nobody is blocking it, now you are right Tor is easy to detect (unless you use bridges or snowflake-like stuff), see https://github.com/Ayms/node-Tor/issues/2#issuecomment-66150611 , surprisingly node-Tor whether inside browsers or as a node could easily pass the Great China Firewall

You are right again: each time people want to anonymize they go (wrongly) for Tor, what I am proposing is not a remake of Tor

Now, I am reacting here because some of your statements are correct but people should not understand that ipfs is censorship resistant

There is also the issue that no IPFS implementation (that I am aware of) stores the nodes it has previously seen, so for nontechnical users IPFS can be censored by blocking the bootstrap nodes and I understand this to be happening at least in China.

True. It’s ongoing but it needs a big refactor. There’s progress, though: https://github.com/libp2p/go-libp2p-kad-dht/pull/460
I think they want to ship it in 0.7 in July.

1 Like