IMHO Freenet's long-term survival, and that of the internet as we know it, depends on one thing: Cover traffic. Large scale, peer to peer, largely legal traffic flows involving the 99% of internetizens who don't know or care about anonymity. I will outline my vision of what this might be below, but the bigger question is how much of this exists already? OneSwarm and FreedomBox spring to mind, but I haven't looked at them in detail.
Ideal Freenet cover traffic, or: How to make P2P a permanent fixture. Basic motivation: - The internet is way too centralised. We are rapidly moving to a situation where everything is in "the cloud", and everything in the cloud is 1) subject to arbitrary deletion by corporates; 2) will disappear if the corporate in question goes bust or changes ownership; 3) isaccessible by governments without a warrant. Blocking p2p traffic is technically feasible, and is likely to happen in many countries if p2p is only used by a few 0.1%'s of the population, for mostly illegal purposes. - For Freenet and disruptive p2p in general to survive, we need substantial legitimate "cover traffic". I doubt that this will come from Freenet itself. It doesn't really matter whether this is FNP; it matters that it's encrypted, robust traffic, and that it happens in significant volumes between domestic IP addresses, often with one node sending to several nodes simultaneously. - We need something usable by the 99% of people who don't want the ideological baggage, performance impacts and cognitive overheads of Freenet. What functionality do people want that can be provided by P2P, without ideological baggage? - It needs to be free as in beer! - It's okay to use some disk space. - It's okay to use some bandwidth; internet is improving all the time. - It should only store and relay what people want to store. - It needs to be reliable. - It needs to not require 100% uptime. - It is NOT anonymous. - It must be zero maintenance. - It must be minimal system overhead. (No, encryption is not an obstacle to this. Encryption is fast enough on modern systems) - It must get through local network obstacles, e.g. blocking UDP on mobile networks, nested NATs, that the users can't deal with manually. (Skype does well on this). - It must be EASY TO USE. Functions: - Distributed backup, including what-happens-if-my-house-burns-down. Encrypt, replicate the data to your friends' computers (with some support for deduping in files that are not sensitive). Monitor which systems are up so we know the health status. House-burns-down-escape-with-nothing scenario: Either 1) the data is purely encrypted with a password and you can just decrypt it, OR for the paranoid 2) password plus involvement of N of the M friends (shared secret). - CCTV/burglar alarm data off-site archiving. Similar problem to the above, some points are different. Different rules for archiving; more paranoid users can disable deleting content without manual intervention involving multiple friends. Internet Eyes style system - users can allow friends to watch their CCTV if they want, e.g. if on holiday, with motion detection to speed things up. - Encrypted instant messaging, voice and email. Skype's encryption is rumoured to be centralised, not PKI, and Skype is vulnerable - e.g. Saudi recently threatened to block Skype and other systems if they don't backdoor it. - Hamachi style easy to use tunneling, but fully decentralised. - WASTE style filesharing. No ideological issues and anyway less of a threat. - Firewall evasion via tunnels. E.g. Saudi again - tunneling to a VoIP service outside the country. - Web hosting e.g. of photos. Now, what existing products implement the above? Do we need to implement something new? What chance do they have of breaking through into the mainstream? - OneSwarm? Used extensively for filesharing, somewhat close to the above, has some anonymity, darknet... - What is the state of the art in distributed backups? How much of the above should be combined? Arguably the first two are the sweet spot ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20130330/ecf8afdb/attachment.pgp>
