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.
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.
Thank you @Ayms and @Akita for your comments.
I think IPFS is censorship resistant as it was designed with use in the rest of the solar system in mind. When we have colonies on Mars, the “censorship” will take the form of meteor strikes and solar storms an other such natural phenomena. Network failure is the censorship in mind for IPFS.
Also, if you have humans on Mars, information availability might be critical, a life-or-death matter. IPFS was engineered with the goal of keeping data available despite calamity after calamity.
If you are trying to resist a determined state actor, it is hard to resist. In the same way, if God is out to destroy you with Martian volcanic eruptions, there is not much you can do either.
If IPFS isn’t censorship resistant, then what is?
I’m not sure I agree with you @yeehi.
Being on Mars is a long-term goal, but it should be seen at a future milestone, not the only situation IPFS is design for, despite its name.
“Censorship-resistance”, just like “privacy-preserving”, “scalable”, “fast” or “decentralized” is relative. There is a number of situation that IPFS is capable of handling gracefully. There are situations that can’t be resolved, like a node in an air-gaper container underwater with no connection (well, you can go back and forth with an USB stick, but you get the point). In between are different scenarios that different users will face, and a software that want to be censorship-resistant should try to adress the largest number possible.
IPFS is a great censorship evasion tool, but it doesn’t mean there is no room for improvement. Real users are facing censorship today by being denied connexion to bootstrap nodes. There are possible solutions for that, so it make sense to study them and see if they can be implemented and how. Not wanting to consider an improvement because it is not Martian-volcano-proof is missing the point, IMO.
You might want to take a look at https://unstoppabledomains.com/browser