Comment by csande17
2 years ago
This sounds a lot like IPFS's strategy regarding anonymity, and AFAIK it resulted in basically no one being able to use IPFS anonymously. When anonymity requires building your own separate sub-community and maintaining your own custom plugin/patchset/configuration for the client, it's really hard to achieve that because the default non-anonymous project sucks all the oxygen out of the room.
Do you at least plan to provide some level of baseline consideration for privacy/anonymity in the main project, like making sure core protocols/libraries don't expose fingerprinting surfaces or leak information?
IPFS and Freenet employ fundamentally different approaches, so comparing them isn't quite valid. With Freenet, there is no need to build separate sub-communities or worry about plugins, patches, etc.
Freenet is designed to facilitate the creation of various decentralized tools that are fully interoperable. Among these tools, some can provide anonymity, allowing application builders to choose the appropriate tools for their specific needs.
This approach is better than imposing a one-size-fits-all solution as the previous Freenet did.
> Do you at least plan to provide some level of baseline consideration for privacy/anonymity in the main project, like making sure core protocols/libraries don't expose fingerprinting surfaces or leak information?
Freenet incorporates several novel approaches to enhance data privacy. For example, delegates[1] allow users to manage private information without leaking it to other software components, unlike how browser local storage can. There are other precautions like Freenet's protocol being encrypted from the first byte making it more difficult to fingerprint.
Mitigating things like correlation attacks is more complicated since they normally require introducing delays and low-latency is an important design goal - so that will be handled by specific anonymity systems.
[1] https://docs.freenet.org/components/delegates.html