Skip to content
This repository has been archived by the owner on Feb 8, 2023. It is now read-only.

Building a new censorship circumvention tool: what do we need to know? #221

Open
ivilata opened this issue Feb 20, 2017 · 3 comments
Open

Comments

@ivilata
Copy link

ivilata commented Feb 20, 2017

Dear IPFS fellows,

At eQualit.ie we're beginning a project to develop a new Free/Open Source censorship circumvention system based around the idea of our original CeNo project, a system which uses the Freenet P2P platform to retrieve web content and make it safely available under censorship conditions. We're keen to evaluate existing options, projects, technologies and approaches so we're conducting something of a literature review.

With this purpose, we're reaching out to people involved in similar or related projects. We'd love to hear what you think is the current state of the art in this area, and particularly about technologies you'd describe as trustworthy, reliable and established. In particular, we're looking for tools that have one or more of the following properties:

  1. Content is available under censorship conditions, ideally even after connection to the Internet has been completely cut for a whole region.
  2. Censored content is made available within a reasonable time.
  3. Access to censored dynamic content (i.e. web apps) is possible.
  4. The system benefits from the user's participation, and is resistant to participants dropping off and to rogue nodes in the hands of the censor.
  5. Users of the system are anonymous to someone observing their traffic, even if that someone is a participant in the system.
  6. Users' devices don't reveal the content that they or other users have accessed.
  7. The system is amenable to privacy-preserving analytics to check its impact.

We know that we'll probably need a combination of several tools to achieve these properties, so we're not looking for a silver bullet but rather some advice and suggestions from you that may help us move in the right direction. We will be dedicating at least 2 years solid development to a chosen infrastructure design and hope to contribute to existing models, as part of our (likely hybrid) appraoch to the eventuating infrastructure.

By the way, part of the team will be at the upcoming Internet Freedom Festival in Valencia (6-10 March). If you plan to be there we'd love to chat with you face to face.:)

Thank you very much for your help!

CENO team https://lists.equalit.ie/mailman/listinfo/ceno

@Mithgol
Copy link

Mithgol commented Mar 9, 2017

  1. The availability of IPFS content is supported by its “P2P-based file exchange” nature: like most “P2P file exchange” systems do, the content is locally cached and each reader is a potential source for further readers of the same content. IPFS-hosted content survives if a region is cut from the outer Internet (as long as inner connectivity remains and also as long as the content was read, and thus cached, by some intraregional IPFS users). IPFS-hosted content should be able to survive mild censorship that forces Web providers to make centain Web sites unavailable (by blacklisting them; example: Russian Federation): the content would be delivered by IPFS P2P instead of the Web. However, IPFS-hosted content's distribution might suffer in any of the following cases:
  • serious intraregional Internet blackout (caused by anti-Internet government policies, or a great solar flare similar to the Carrington Event, or an EMP caused by thermonuclear warfare),
  • prosecution of end users hosting IPFS nodes or specific IPFS content (if such prosecution is not countered by numerous satyagraha-type participants “willing to undergo suffering, loss of property, and to endure the suffering that might be inflicted on family and friends”),
  • a legislative effort that make the price of Internet connectivity tremendous (example: Yarovaya Law is likely to make end users shoulder the price of total collection and 6 month long storage of their traffic; the amount of equipment that is needed to store all the collected data is nonexistent not only in Russia, but in the world) and thus becomes an economic “barrier to entry” (while not having a form of a direct ban) for the majority of former Internet users.
  1. Censored Web content might be made available within a reasonable time by people willing to re-publish such content in IPFS. Of course, they would also need to disseminate its IPFS URI. For example, they might make a dedicated IPNS name for their Web site.

  2. Client-side JavaScript is definitely possible, server-side accepting user-generated content is can users POST things to the Permanent Web? ipfs-inactive/faq#73.

  3. The system benefits from the user's participation because of the system's “P2P-based file exchange” nature: more users → more sources. The distribution of any given file ceases when all nodes delete it, that makes the system less resistant to participants dropping off (in the future you would be able to use some Filecoin cryptocurrency to pay the nodes to keep files you need online). Rogue nodes in the hands of the censor won't harm the content (the received content is checked against its hash, available from the address) and also won't easily harm the DHT (IPFS DHT is somewhat protected against Sybil attacks).

  4. Participants of IPFS are not anonymous (DHT makes their IP addresses known). It's possible to read and publish IPFS content (using a Web gate) without being a participant, but of course a Web gate's site might then become blacklisted by authorities. (A user of TOR is probably able to bypass blacklisting and to maintain anonymity.)

  5. It is quite possible to reveal all the content from a local IPFS cache once its file is accessible.

@ivilata
Copy link
Author

ivilata commented Mar 20, 2017

Thanks @Mithgol for the detailed information (and sorry for the late answer)! It will be most useful for us.

@jbenet
Copy link
Member

jbenet commented Jul 9, 2018

related to #281

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants