Integrations with I2P/TOR

[DonaldTsang]

• [ ] Orion setup guide for use with I2P/TOR (bare minimum)
• [ ] Automatic I2P/TOR installer option after IPFS install
• [ ] Automatic IPFS + TOR/I2P default setup
• [ ] "Send To" option similar to https://github.com/marcin212/ipfs-gui

[6543]

IPFS Sould get mor anon too ... but ist this more a topic for the main ipfs devs ?

Send To integration would be very nice, but this is os dependent :(

[DonaldTsang]

@6543 The IPFS devs are really acting slow on this one. @OpenBazaar already has a working implementation but it is not going upstream

[lidel]

Adding Tor support to IPFS Desktop is blocked by https://github.com/ipfs/notes/issues/37:

We have no plans on integrating TOR into go-ipfs officially until there has been full security audit.

Then another security audit of ipfs-desktop itself needs to happen to ensure app-specific defaults don't cause leakage of private/identifiable information.

I would love to see Tor integration today, but this is too serious to ignore. On the upside, this will happen. It just need to be done with proper opsec.

[david415]

It is not correct to say that a security audit is needed before merging in the Tor integration code; please allow me to break down the reasoning behind my opinion in a way that is accessible to everyone and without using any meaningless vocabulary like opsec:

consideration 1: Traffic analysis resistance mechanisms such as Tor can under certain conditions prevent murders.

consideration 2: Traffic analysis resistance DOES NOT necessarily imply anonymity or reducing the leakages of personal data. Privileged white men may not understand the value of "location hiding properties" but at risk peoples will immediately grasp the importance.

consideration 3: By preventing the integration of Tor it is almost as if you are contributing to the murders mentioned in consideration 1. This is of course an overly dramatic statement but there is also some truth to it which may serve as food for thought if thinking is an activity you enjoy with forthright honesty and political consciousness.

All that is not to say that I do not value security audits. I do think they are valuable but this really has nothing to do with being able to add a feature like this. You are conflating the issue of the reduction of metadata leakage via using Tor with the totally different issue of application level reduction of metadata leakage. It's true that both of these are good to have but they do not depend on each other.

On the other hand IPFS may not be a very privacy preserving for systemic design reasons and this is not something that will be changed by merely using a privacy preserving transport. And again another opposing view is that Tor and I2p are not even close to being good enough for message oriented applications where a little latency is OK; whereas a mix network may well be a much better choice as they certainly have a much more powerful threat model than Tor or I2p in that they can resist attacks from global adversaries whereas Tor and I2p are trivially broken by a sufficiently global adversary. We have over 37 years of academic literature on this topic and not one of them mentions opsec; opsec is a fancy why of saying "shut the fuck up". It is so malleable of a term that it means almost nothing.

[lidel]

@david415 My intention was not to shut this discussion down, but to redirect it to the upstream issue (https://github.com/ipfs/notes/issues/37), where it could reach more people from go-ipfs team. If you read it the wrong way, I apologize (my English lacks finesse and I am guilty of using shortcut words).

To keep this on topic (desktop), and provide some missing context on this project:

IPFS Desktop is just a thin UI on top of go-ipfs daemon with ambition to reach regular (non-technical) users. It may be used by early adopters right now, but the goal is to bring IPFS features to "civilians". I feel it is safe to say most of that demographic won't know how "traffic analysis resistance" differs from "anonymity" and if they know "Tor" they equal it with their own interpretation of what "anonymity" means.

This introduces "consideration 4": by shipping Tor transport [with easy-to-use GUI app] without getting it audited end-to-end and with no UI for communicating risks in a comprehensible way, we could put those high risk people in harm's way just by giving them false/misguided sense of anonymity. This is just as scary as 3rd one, but additionally makes IPFS GUI directly responsible.

That being said, I wonder if we could move forward before audit happens. For example add Tor transport as an opt-in experiment (behind a config or cli flag) to go-ipfs, so if technical user knows what they are doing (including risks), they could use it unofficially.
I asked about that possibility in upstream issue.

[david415]

Please take note that I can go back and forth like this forever. I have infinite patience for describing anonymity systems and having read and understood the academic literature. I might just be one of those rare individuals who can accurately describe how each traffic analysis resistance property is achieved.

It is not clear to me that you acknowledge that Tor integration immediately provides location hiding properties and this is inherently useful to people who understand that this is not the same thing as anonymity. You can do without the security audit by telling people exactly which properties to expect from the system and in particular by telling them that you make no anonymity guarantees but that by using Tor, some amount of location hiding properties are achieved.

By all means, move foward without the security audit. I will make myself available to give advice. Although, let it be known that I shall not write anymore code for free because IPFS/Juan has burned that bridge.

Furthermore, the larger issue here which I have tried to raise already: Tor integration isn't good enough because Tor's threat model isn't good enough. NSA collaborates with various intelligence agencies and can very likely break Tor with a number of different attacks. In the academic literature it is known that Tor is trivially broken by a sufficiently global adversary, passive timing correlation is possible. There are also many active attacks which can be performed by a much weaker adversary than a "sufficiently global adversary". In order words, please continue your work. It will not be good enough but it's a step in the right direction.

[IngwiePhoenix]

This is quite an old issue ticket now - apologies for poking at it.

I was trying to learn more about IPFS with i2p and Tor. Has there been any movement on this thus far?

Thanks!

[SgtPooki]

There has not been any movement on this and most likely won't be unless some kind of TOR support is added in Kubo/boxo directly.

In order to achieve our maintenance goals with a small team, IPFS-desktop is taking the stance of a UI for Kubo, where we're only supporting features that enhance the use of Kubo features via a GUI.

I'm going to close this issue, please feel free to bring up in discuss.ipfs.tech, or ipfs/kubo or ipfs/boxo repos.

[marek22k]

If at some point there is interest again: I2P has an extra API for applications.