How can users maintain anonymity while serving files on an ipfs node? If you are publishing a file, then it is associated with your unique IP address. You could establish a Virtual Private Network first, but is there much else that could help?
IPFS leaks a fair amount of information:
- Your peer ID is persistent, by default.
- IPFS discovers and advertise your addresses. You’d want to run your IPFS node inside a container (or, even better, a VM) that only knows about the VPN interface.
- The content stored by a node can be used to fingerprint it.
- DHT records stored by a node can definitely be used to fingerprint it.
If you just want pseudonymity (fine with a consistent identity as long as it can’t be easily linked), a VPN plus a VM/container should be enough if you just want basic privacy. If you’re trying to hide from governments, the current IPFS protocols likely aren’t sufficient no matter what you do.
You can use the Addresses.Announce feature to only show the addresses you want known (you don’t have to use a container or VM to achieve that). I actually use that feature for a different reason (the auto-discovery doesn’t work in my setup, probably a bug there when things are complicated, like double NAT), it works as advertised.
However, IPFS won’t provide the anonymity you desire, it’s just not designed to do that. What you are looking for is:
They’ve been around for a lot longer than IPFS and are designed to provide anonymity in both directions. I used to write code for it, a long time ago (over a decade ago). I stopped because it was overrun by … undesirable elements, like TOR has become. Now, I use IPFS and I love it!
I am awed to find you in this thread! Thank you for all your work.
I wonder whether it might be possible for IPFS to offer some sort of anonymity or deniability by the use of something like neighbourhoods, formed by nodes, and a sort of double-bind, like is used in clinical trials.
A neighbourhood, perhaps ephemeral, would be formed by a group of 128 nodes, for example, which are publishing files. The neighbourhood would broadcast its files, but it might be possible to mask which nodes comprised the neighbourhood. Or it might be possible to contain knowledge of which node is hosting which file to the participating neighbourhood nodes themselves. So, if you wished to retrieve a file, you would go to the neighbourhood “greeter” which would in turn ask within, retrieve and deliver the content.
You were very far sighted, working on FreeNet way back then. Thank you for helping get the project going.
Since we are on the topic of anonymity (which is important for Free Expression, so that people can avoid persecution), and to jog your memory to look in from time-to-time, here are a few more worthy projects which help support anonymity:
This project isn’t yet ready for public, but uses IPFS and is nearly there. It could be seen as an alternative to Telegram
Session is respectful of Freedom and the developers there are working on Lokinet. It is a strong alternative to Telegram which you can use now.
Uses i2p between clients. Easy to use when you get the swing of it. Good for file sharing.
Began as GNU Ring, and a strong alternative to Skype like tools.
Similar to FreeNet in many ways
Using a fork of the client allows you to opt-out of Lbry Inc.'s blacklist system. If you upload using a client instead of the Odysee front-end, it announces that the content is available from sources on the LBRY blockchain other than the Odysee front-end.
Well, you’d probably want to just use IPFS as a distribution network for freenode (or some other form of “mixed” data). But even then, current IPFS implementations are pretty noisy. Unfortunately, real anonymity systems need to be designed with anonymity as the primary goal from the very beginning.
I’m hoping that someday IPFS will provide better privacy, but users will likely need to build applications on-top-of the underlying protocols if they want anonymity.