Slashdot Mirror
Freenet 0.5.2 Released
FurbyXL writes "With the RIAA roaring to grab peer-to-peer users by their IP addresses, Freenet - fully anonymized production and consumption of content - is gaining renewed attention. Articles in New Scientist, ZDNet UK, Wired and CNET (and here) set a somewhat typical context for Freenets major release 0.52. Significant performance improvements through NIO-based messaging, probabilistic caching etc. should provide increased rest to Chinese dissidents, but may finally wake-up the RIAA's Matt Oppenheim..." The announcement on the Freenet home page lists several improvements found in the new version: "a new NIO technology that brings improved performance using less CPU and system resources," "Individual nodes are now more efficient," "the speed and routing of the entire network have significantly improved," probabilistic caching, user interface improvements, and more.
I've been running the 5000 series builds lately and they're considerably faster and more efficient. Hope everyone has a good experience freeneting.
scott
I have been using Freenet for years but except for the very most popular sites the speed and availability of the sites has made it little more than a toy. In theory, though, it is a great application.
The biggest issue I had with Freenet was not reliability or the fact that I might be sharing kiddy porn, but the fact that THERE WERE NO GOOD KEY INDEXes. Seriously, do a search on Google and the only ones you find are down or haven't been updated in two years. It's the big Catch-22; I won't use it 'til there's something to look at, but there won't be anything to look at until somebody uses it.
When you install Freenet, on the start page (http://127.0.0.1:8888 by default) are several links to index pages. Most people writing freenet sites submit a link to their own site, along with a description. While one cannot directly search for content, most freesites have a definite topic. I consider this "good enough," at least at this size of network.
Uh, no. Freenet wasn't designed to prevent this. Of COURSE Freenet lets you know what machines have connected to you, and what they've requested. Otherwise it couldn't send it to them -- it runs over TCP/IP, not magic! But this information -- the IP of the machine requesting an item from a datastore -- has absolutely no bearing on WHO did the intial request, or who will receive it in the end. Freenet clients make a request for a file, and the clients pass that request on as if it was there own.
So there's no difference between passing on a request, and making one yourself. Requesting a file becomes an anonymous activity, because you don't really have any idea how far this web goes. All you know is the requested "depth" cut off, so requests don't go more than N requests deep. And individual clients can (and do) rewrite this value. SO there's no way to tell if the client you've exploited is the first or a member on a chain of requests.
In fact, the best exploit for freenet would be a "sting," where you control all of the clients except for a handful. Then you know that these clients are doing all the dread. But it'd be really hard to establish this kind of "web of mistrust," considering that most freenet users populate their initial nodes either through the freenet website or through friends of theres. At that point, it's probably easier to get one of those friends to blab on you then it is to get evidence through technical means.
Data insertion works similar. If you have information in your datastore, there's no way to prove that you put it there. In fact, since you can explicitly exclude your own datastore from insertions, it's less likely that you'll have it if you inserted it. So if you have data in your store, it's equally likely that it was "pushed" to you to serve as it is that you downloaded it yourself. In fact, it's probably more likely, as freenet is receiving insert requests (more or less "uploads") all day, but only downloading when you're interacting with it.
Freenet's about PLAUSIBLE DENIABILITY, which in a free (as in, bill of rights and supreme court) society should be enough to keep you out of prison. The difficulty of identifying computers is no different from regular peer to peer...the difficulty lies in IDENTIFYING them.
And as for buffer overflows...you don't know much about Java, do you? Individual applications can't become overfull due to automatic checking by the VM. So the unless the VM has bugs, the client is about as invulnerable as you can hope for. Plus, lots of us have looked at the key code for Freenet. I didn't trust it until I built it myself.
Hey freaks: now you're ju
There are at least half a dozen reliable index sites within Freenet itself, and several of them are linked to from the gateway page.
Why would you want an index outside of freenet anyway? Holding such a thing on a regular web server means your access can be tracked and logged, which defeats the purpose!
There's plenty to look at in Freenet. I'd bet a significant sum that you haven't tried it recently.
For the Freenet newbie: This is NOT your plain jane filesharing program! You don't just point it at files and say "let people leech these". Freenet is a transport layer. Most users access it through a browser, retrieving HTML and images stored within Freenet. It's also possible to use it as a messageboard, file repository, and more.
When you start up Freenet, you give it some disk space to use as a "datastore". This starts empty, and fills itself up over time as your node participates in the network.
When you click a link in Freenet, your web browser requests the key (sort of like a url) from your local node. Assuming your node doesn't have the key, it asks another node for it, which then asks another and another until the key is located. The data is then passed back up the chain to your node, and along the way some of the intermediate nodes keep a copy.
In this manner, popular content propagates in Freenet. By leaving your node running (and making sure it's actively participating in the network, serving requests) you'll allow it to store some of the keys that make up Freenet's content. When you use your node, it's likely that some of the keys you want are already stored there.
Routing is similar. When you first install Freenet, it has knowledge of a few "seed nodes", and that's all it knows about. As your node talks to the seed nodes, they tell it about other nodes, and your routing table grows. This makes you less dependent on the seed nodes (which are probably melting today).
A new system in Freenet called "probabilistic caching" results in a certain amount of specialization, and a significant performance improvement. It's based on keys (which are cryptographic hashes of content) and node IDs (which are crypto keys). Both are fairly randomly distributed, numerically. Here's how PCaching works:
If your node ID ends in 0x3F, then when your node participates in the chain for a piece of data whose key ends in 0x3F, it's very likely to keep a copy. When your node handles other keys, it might still keep a copy but it's not as likely. Likewise when you request a key that ends in 0xD3, that request will be passed, if possible, to a node whose ID also ends in 0xD3. This is a simplified explanation and I'm not a Freenet coder, but that's how it's been explained to me.
Obviously, the larger and more up-to-date your routing table is, the more easily your node can find the pages you request. Being an active part of the network is the best way for your node to keep a healthy routing table and a relevant datastore.
Freenet is unique among p2p apps in that your user experience actually improves if you contribute more bandwidth and space. (Bandwidth is much more important than drive space. 100 nodes with datastores of 1 gig each will make a much bigger impact on the network than 1 node with a 100 gig datastore!)