[2020 Theme Proposal] Privacy

[ianopolous]

Note, this is part of the 2020 Theme Proposals Process - feel free to create additional/alternate proposals, or discuss this one in the comments!

Theme description

Privacy is more critical than ever online and will only become more so. If ipfs ever wants mainstream personal use, I believe it needs to solve the privacy problem. E.g. even if the web was already on ipfs, naively browsing it using a normal web browser would put lots of people at risk because you're essentially broadcasting your browser history to the world. Think Cambridge Analytica, but without the central control to cut off their access to everyone's data. There is some good background here

Core needs & gaps

Start modifying the core APIs and protocols to support privacy focused applications and letting them control the granularity and strength of reader and writer privacy. This likely means something like onion routing with controllable IPFS identities per stream. Hashmatter, in particular @gpestana, have done some great work here with p3lib. it would be great to incorporate that.

Why focus this year

Privacy, like security, can't be layered on at the end, it has to be built in and a core part of the design process from very early on.

Milestones & rough roadmap

1. Define relevant threat models
2. Add an api for creating an ipfs identity + anonymity set
3. Add optional anonymity set parameter to core apis like block, and pin which decides which ipfs identity to make the call over.
4. A privacy focussed build of ipfs incorporating some of p3lib's work, or a config parameter in standard ipfs to enable it.

Desired / expected impact

1. Downloads of the privacy focused version.
2. Number of privacy focussed identities presented to the network.
3. Add super powers to privacy focussed apps like Peergos
4. Unlocking a whole generation of safe social network apps on IPFS.

[momack2]

Thanks @ianopolous!! Totally agree this is a big need for the increasing amount of app and user data being put on ipfs. Reader/writer privacy in ipfs is actually one of the open problems we’ve documented in the https://github.com/ipfs/notes/blob/master/OPEN_PROBLEMS/ repo for more research and design work. These are really hard problems and getting them partly right is actually worse than not having them at all. 😬

I believe OpenBazaar already contributed an OSS onion transport for ipfs, are there other core features or functionality that would unlock really valuable use cases on ipfs next year in particular while we are still investigating how to do this right?

[ianopolous]

Hi Molly, that link 404s. At Peergos, we spend most of our time thinking about privacy in the context of IPFS and have been involved with IPFS since 2014 and core contributors since 2016. We are aware of all the issues and have concrete proposals.

By onion transport I don't mean Tor, but generic layered encryption ala p3lib. Open bazaar have done some great work, but there is no way of using it without building from their fork of IPFS and then you still need a separate installation of Tor. What apps need is a way to use privacy preserving primitives via ipfs itself, possibly via a plugin if ipfs are reluctant to integrate anything yet. Also with Tor you are limited to the anonymity set of the Tor network (~ 10,000), which ipfs should be able to easily eclipse with it's 100s of thousands of nodes. (NB: there are clearly other potential issues with the quality of nodes - in particular who is running them)

Even having an onion transport is not a magic bullet, but in my proposal I suggest building upon the underlying privacy preserving transport. There are some relatively simple api additions that would satisfy even paranoid people like us at Peergos. ;-) At that point it's up to app developers to decide what to use based on their threat model.

[ianopolous]

You probably meant https://github.com/ipfs/research/blob/master/OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md

[npfoss]

GNUnet has some interesting ideas about tuneable levels of privacy, so you can choose based on the context how much speed vs privacy matters to you. Unfortunately I think their version depends on connecting only to a list of "friends", or nodes you trust, which seems impractical for end users (imagine running a node on mobile...). Either way, maybe some of those ideas will be useful if you don't want to always go for complete anonymity at the cost of a huge slowdown.

[gpestana]

Thanks for opening up this theme proposal @ianopolous! Some thoughts about the proposal and discussion:

Start modifying the core APIs and protocols to support privacy focused applications and letting them control the granularity and strength of reader and writer privacy.

Giving the user/developer the option to control privacy is the goal of p3lib and it'd be great to include that feature as part of core IPFS implementation. On the other hand, I do agree with @momack2 's comment on the fact that getting the solutions partly right is actually worse than not having them at all. The efficacy of privacy preserving mechanisms depends a lot on the context, threat model and external factors (e.g. protocols that work relatively well in a public DHT with millions of users may work completely different on private networks). Communicating the those nuances to the user (and developers) can be pretty hard.

For example, it would be relatively easy to harden the privacy of lookup initiators by slightly modifying the kademlia protocol: requesting the whole routing table instead of a particular CID would make it harder for adversaries to learn what CIDs other network peers are looking for. However, by no means this is enough to claim "privacy" (just privacy against a certain type of passive adversaries, with a network of size at least X, etc..).

I still think that building 3rd party libraries that play well with libp2p/IPFS, that are well documented with regards to threat models, and have proper benchmarks would be a better solution. But I'm happy to change my mind on this.

I'd probably take a step back and try to answer first: "how do mechanisms X,Y,Z improve the privacy of IPFS under different contexts and threat models?"

A very practical plan could be to measure and formally define the impact of different privacy preserving primitives and protocols on IPFS, under different network topologies, adversaries, etc.. (e.g. using the onion routing for DHT lookups, using libp2p nodes as relayers, as @ianopolous mentioned). And based on that study, decide if any of the solutions would be 1) good enough and 2) easy enough to communicate the tradeoffs to include in IPFS core. Worst case scenario we learn a lot and get clarity on the current threat models, tradeoffs, etc.

1. Define relevant threat models

I really think this is crucial!

Since this is a proposal still, I 👍 it :) I see a lot of interesting work to be done which is in line with research/open_problems, with a lot of potential for learning about and improving IPFS privacy in the future.

[Gozala]

This is the thing that comes up with-in the browser realm when you start talking about distributed protocols. Increased privacy and tracking protection seems to be an area that most web browsers seem to invest into, so it’s no wonder to see reluctance towards new protocols that seem like a step backwards. This is to say I think that IPFS by default should provide limited privacy guarantees to be on par with HTTPS. Note that this does not necessarily means figuring out privacy preserving DHTs (even though that would be great) it could be something like routing through trusted nodes (and delegated trust through web of trust might provide some interesting model) or maybe something entirely different e.g. DNS records that provide address book of trusted nodes replicating data associated with a record.

I’m sure by focusing on privacy some compromise could be found that while not addressing problem fundamentally can still get IPFS at least where conventional web is.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.