Are sting operations possible against IPFS→WWW gates?

[Mithgol]

Imagine the following sting operation: an agent provocateur (or the ignorant public) uses ipfs add to publish some significant amount of illegal numbers that digitally represent child abuse images, racially charged hate speech, trade secrets, designer drug formulae, classified information such as elements of cyberwarfare, detailed instructions for producing weapons of mass destruction of nuclear, radiological, chemical and biological nature, etc.

The authorities are then greatly angered when each and every IPFS→WWW gate is repeatedly demonstrated to “voluntarily provide hosting in the Internet” for each and every piece of that illegal information.

A global witch hunt arises, gatemasters and developers around the globe are arrested, charged for posession and transmittion, treated as members of terrorist organizations, held without trial, tortured, raped, mutilated, their families and homes are officially or unoficcially targeted for air strikes by military-class unmanned combat drones and cruise missiles respectively.

(Or woundn't they?)

[jbenet]

No, we are developing "denylists" explicitly for this purpose. IPFS networks can maintain lists of "bad bits/illegal numbers" that they will not download/serve/etc. These lists can be maintained per jurisdiction.

We (the IPFS team) will maintain many hash lists, including some denylists, like a DMCA denylist. Of course, it is up to the people running IPFS nodes to decide whether to follow these denylists, but the default will be opt-in in to follow our denylists for the distributions that we put out. (other builds or ipfs implementations may differ). Thus we can handle DMCA notices and so on, and then get everyone who follows our lists to comply with them altogether. If people choose to opt out, and do not comply with the laws of their jurisdiction, that is their choice and thus are responsible for their action. Most IPFS distributions will not use an oblivious routing protocol, so users won't be anonymous. it is highly encouraged that users follow our denylists. we won't put stuff on there lightly, we hate censorship. Also, by default, HTTP gateways are private, not public. Running a public gateway is a decision too, and those who make it should definitely follow our lists.

[Mithgol]

A good solution. (Though not ideal because one person's denylist might quickly become another person's list of bookmarks, favourites, ipfs pin sources. But that's inevitable.)

[geebotron]

I really think you are on a hiding to nothing as soon as you start pandering to anyone who wants to block content from IPFS: a globally distributed, publicly accessible (and publicly write-able) file system. Every single file that could exist on IPFS has the potential to offend someone.

I don't know whether the originator of a file (or the file's down-loaders) are permanently identifiable in IPFS, but if they are, why would anyone take the risk of transferring anything at all, onto or out of IPFS?

A library analogy:

1. If there is the mechanism so that one book can be censored in the library, the mechanism exists to censor all books in the library. Then (potentially) there is no library.
2. If books cannot appear in the library that are published under pseudonyms (i.e. anonymously) this is effectively censorship: Some people do not want their ideas attributed to them, for a variety of reasons - Then see point (1).

I noticed in another thread there was discussion about deletion of files (FAQ #9) This ought to be impossible (as it appears to be) and remain impossible.
As I said, if a deletion mechanism becomes available in IPFS, every censorious whinger on the planet will be in the face of the developers (the public face of IPFS) demanding they remove content for them. The developers will (quite rightly) soon be sick of this, then implement a mechanism of identifying the originator and down-loaders of a particular file so the censorious whinger can pester those people instead of the devs.

In my opinion the only way a system like IPFS can work is if it can be make to work anonymously and without censorship. Any other way will prove to be unworkable. Everyone who uses IPFS would need to understand and accept this, or else not use it.

• If you accidentally publish something private - hard luck: don't use IPFS.
• If you download something that offends you - hard luck: don't use IPFS.

As devs you're going to have to have the balls to publicly say (maybe not in these exact words :-) : Screw Tipper Gore, Kim Jong Ill, Vladimir Putin, the MPAA, President Erdoğan, Islamic State, The Southern Baptist Church etc etc. Or ... you may as well jack the whole think in right now as you will end up as puppets to that collection of assholes.

Sorry to put this in such stark terms but ... am I right?

Most IPFS distributions will not use an oblivious routing protocol, so users won't be anonymous.

I'm not sure what you are saying in this statement ...

I would like to see a clear and unequivocal support for IPFS users who want freedom from censorship and anonymity in their use of the IPFS tools. By that I mean that those who would request these features are respected users of IPFS, rather than simply tolerated, and implicitly under suspicion etc. If I get the whiff of the "Nothing to hide, nothing to fear" bullshit you always hear from the political class from the project leaders, I would suggest that one steers well clear of this whole project, as it is either (a) misleading in what it claims to do / be , or (b) it is doomed to fail as it can't do what it claims to do / be. i.e Is this actually The Semi-Permanent, heavily censored Web ... which is exactly what we already have.

[enkiv2]

@jbenet is there a current spec file for how denylists are likely to work?

While the obvious implementation is a list of "illegal" hashes, I'm interested in at what level this filtering would occur (i.e., do denylists essentially just apply to what gateways and individual daemons are willing to download/serve/pin? Do they also apply to which requests nodes are willing to pass along to peers during request routing?). The way in which denylists might be distributed & enabled or disabled by users is also interesting.

These questions have impact in various ways. For instance, if 'illegal' hashes are denied during routing, they are unlikely to be accessible to users who have explicitly removed them from their denylist if they are on a default denylist (i.e., widespread denylists -- or even denylists that are widespread among specific peer groups -- are essentially totally effective), whereas if they are not excluded from routing then denylists are essentially wholly ineffective except for the purpose of public gateway DMCA compliance. (Even if this is implementation-dependent or a flag, the dominant behavior or default behavior has pretty extreme consequences.)

(I say this from the perspective of somebody concerned about censorship who is also looking at IPFS from the perspective of whether or not denylist support will essentially allow his public-facing applications to avoid any kind of DMCA safe harbor related complications.)

[starrychloe]

FYI adding a null byte to the end of the file will completely change its hash, and will unlikely affect the file.

$ echo -ne \\x00 >> illegal_file

[knupfer]

@geebotron While I can appreciate your support for anonymity, I think what you say is quite nonsensical. IPFS is global, censorship not. So you can publish in Land A file X which is illegal in Land B, this will happen and is not avoidable. IPFS is working actively on tor integration, which would allow to download this file in Land B or even to seed this file in Land B. IPFS nodes and client which run on tor will probably ignore the deny list. As @Mithgol stated, there will be for sure tor nodes which will pin everything which is in the deny list.

[dimitarvp]

I feel that if IPFS only strives to become a better WWW, that's not really a big progress; you're gonna transform the internet into one huge CDN which is only gonna benefit the corporations (less hosting and traffic costs for them).

There are social issues with WWW which are becoming more and more apparent with time -- for example the fact that its original intent was decentralization and everyone hosting their things which is NOT true as of today; we have N huge vendors that control 90+ percent of the internet. For those of us who read history, this is a huge red flag.

I fully understand the huge time and effort commitments that need to be made for such a big project like IPFS and I am not trying to reduce the importance of the work of the contributors. I am not saying you're doing a bad job. Nothing like that.

What I am saying however is for your network to start even gaining critical mass, you need something that makes you really different. I don't think decentralization is enough. IMO you should work really hard on anonymity. There are a lot of rich people out there who love telling everyone else what to think and do and they are very happy with the current state of the WWW.

Let's make the internet as sir Tim Berners-Lee imagined it. Even he gave several cautionary talks addressing the increasing centralization of the internet.

In my not extremely informed opinion, a blend between the current IPFS and Freenet is gonna be a real progress.

[lidel]

Taking a step back and thinking about "inventing on principle"^[0], @dimitarvp raises some good points. If we do not keep privacy in mind while developing new features, history will repeat itself.

Think about the web we live in now: there are parts of TCP/IP, HTTP and HTML5/JS stack that leak private information by default (eg. malicious use of <canvas> object for fingerprinting^[1], IP info leak via WebRTC APIs^[2] etc). Some of recently added features are so bad from privacy perspective that Mozilla removed them AFTER they were shipped (eg. last year's failure of Battery API^[3]).
Don't even get me started on the lower OSI levels..

Because privacy was "an afterthought" we have a "normal" browsers with all features enabled and "privacy-first" Tor Browser which has a lot of standard stuff blocked/turned off by default.

This creates (IMO) false dichotomy where people think they can either have "features" OR "privacy". Sometimes the narrative gets even worse, ending up with Orwellian "security" OR "privacy".

TL;DR
We are still in early days of IPFS. If we "invent on principle" that includes privacy by default, we will avoid past mistakes and build better tools and features.

PS. If anyone is interested in Tor support status, relevant issues are:

• Play nice with Tor onion services: play nice with Tor onion services ipfs/kubo#1118 (closed, but a good read about IP leakage)
• Tor onion integration: Tor onion integration ipfs/notes#37 (ongoing, with status updates)

---

[0]: Bret Victor - Inventing on Principle (talk on YouTube)
[1]: https://en.wikipedia.org/wiki/Canvas_fingerprinting
[2]: https://browserleaks.com/webrtc
[3]: https://www.theguardian.com/technology/2016/nov/01/firefox-disable-battery-status-api-tracking

[madavieb]

This issue has been moved to https://discuss.ipfs.io/t/are-sting-operations-possible-against-ipfs-www-gates/412.