Freenet Frequently Asked Questions

Or even (find your IP address from ipconfig/ifconfig/winipcfg and substitute it for 192.168.1.1):

And if you want to grant full access (i.e. change config settings, restart, etc) to the node (WARNING: Be very careful who you give full fproxy access to!): fproxy.allowedHostsFullAccess=127.0.0.1,192.168.1.0/24


Problems installing with OpenJDK

Some versions of OpenJDK, particularly the one included with Ubuntu 8.04, have some problems with SSL which cause the installer to fail. Please install the Sun JRE, at least version 5. On Ubuntu or Debian, open a root terminal and type:

	apt-get install sun-java6-jre
	update-java-alternatives -s java-6-sun
	

Why are there so many messages in my logfile with a backtrace attached?
Fred (and freenet in general) are still very much in development, and if something goes wrong it's worthwhile to know exactly what went wrong.

How can I change from stable to unstable?
There is no unstable network anymore.

What's new? Is there a changelog?
On every new build, a brief summary of all the main changes is posted to the support and devl lists and the en.freenet board on Freetalk. This is usually relayed to FMS and Frost too. Alternatively, for a much more detailed view, check out the git repositories.

Publisher answers

If I publish something in Freenet, how will people find it? Don't they have to know the key I used?
Yes, people will have to know what key you used to publish your information. This means you will have to announce your key in some way.

The most common way to do this is to send a message, containing your key and brief description of your information, to the author of one of the existing Freenet sites. Most of the "portal" sites which are linked from the Freenet web interface (fproxy) have a submission form which lets you send them messages anonymously. You could also send your key to people by using the Freenet mailing lists, in the IRC channel (irc.freenode.net #freenet), by private e-mail, or by advertising your Freenet site on your World Wide Web site. If you're feeling extravagant, you could even try skywriting it. (Graffiti is not recommended, for legal reasons.)

How do I publish a Content Hash Key (CHK)?
A Content Hash Key is based on the actual content contained within it - and as such, the key will only be known after it has been inserted into Freenet. To insert a CHK, simply insert it as "CHK@", Freenet will tell you what the actual CHK is once the insertion completes.

Can Freenet documents be updated / deleted?
Currently, a document posted to Freenet with the same name as one already present may actually serve to propagate the existing document. There is also currently no means of deleting a document from Freenet. Documents that are never requested are eventually removed through disuse.

However, you can use an Updatable Subspace Key (USK) to provide a form of updatable freesite: your node will automatically look for later editions of the site (after you visit it, or always if you bookmark it), and show you the latest version.

Contribution answers

I have this great idea....
Good! First step: read the mailing list archives. Odds are good that someone else had the same idea and discussed it with the group. Either a flaw was found in the idea, or perhaps it was decided to postpone implementing the idea until later. Some examples of ideas already discussed are storing information by content hash, key redirection, signed keys/data, use of UDP, server discovery, URLs, document versioning, and others. If you don't see the idea discussed in the archives, by all means bring it up in the appropriate mailing list.

Can I contribute to the Freenet Project?
Absolutely. Even if you don't have the time or skills to become a co-developer of the project, you can contribute in other ways:

• Help test Freenet by installing and configuring the server software on your machine.
• Install the client software on your machine to test retrieving information and publishing your own.
• Work on the Freenet web site (including the FAQ).
• Contribute your ideas to the discussion lists.
• Translate the user interface into your local language.

If you are a developer, you can also help by designing and developing other applications to run on Freenet.

People that want to contribute to Freenet in any way, by contributing artwork, new ideas, or even correcting spelling/grammar mistakes or ideas for adding new pages/paragraphs on this site, are also welcome to email.

How can I access the code and website?
We are using a subversion server : Freenet's subversion repository.

What tools do I need to help develop?
To build and deploy the Freenet server, you will need Java tools compatible with Sun's JDK 1.5 or later. To retrieve and update the code at http://freenet.googlecode.com/svn/trunk/freenet/using subversion, (This is not necessary if you only want to download, compile, and run the server without contributing to its code). Further instructions for building and deploying the server are included with the code itself. Generally speaking, joining our IRC channel is a good idea: #freenet on irc.freenode.net

Is there a Help Site that goes deeper into the questions newbies may have about Freenet, and where people can contribute too?
You could have a look at our wiki. There is also an older, largely unmaintained Freenet Help Site wiki. You can contribute to both, since they are wiki's so most pages are editable.

Where can I report bugs?
You can use our bug tracking system or send a mail to our development mailing list.

Security answers

Can I use my regular browser to browse Freenet?
Freenet has a web interface: much of the content on Freenet is in the form of "freesites", downloads, configuration and friend connections can be managed from the web interface. However, because of weaknesses in current browsers, we strongly recommend that you use a separate browser for Freenet. Specifically, browser history stealing, in all its forms, is a major threat if you share a browser between Freenet and the WWW at large: malicious web pages will be able to probe which freesites you have visited, and report this information to their owners.

Won't attack X break Freenet's anonymity?

Short answer: Probably yes.

Long answer:

Freenet has a different threat model to Tor and the Mixmaster remailers. Freenet is designed to resist censorship: The network must therefore be robust, and content must be distributed without requiring a central server, whether anonymous or not. Anonymity is important for requesters and especially for those who upload content in the first place. The typical example is a corporate or government whistleblower. Generally to find the originator of some content, the attacker must be able to predict the data in advance, must be able to move across the network relatively quickly, and must be able to perform the attack while the data is being inserted; after that, it is distributed across the network and is much harder to trace, and the originator may have left the network. However, if by chance or by overwhelming force the attacker is connected to the whistleblower (or e.g. seizes the computers of everyone on the network), he may be able to identify this much more quickly. All of this is vastly more difficult on a darknet, where everyone connects only to their friends, where it is very hard for an attacker to find nodes, and where to connect to a given node he must social engineer its operator! Freenet does support opennet mode (plug and play), but darknet is far more secure, and additionally is far more difficult to block on a national firewall.

Tor on the other hand is designed to anonymise real-time data streams, on the assumption that the list of nodes can be public, that there is a free world where nodes can be operated safely, that the authors of controversial content will be able to either host (hidden) web servers themselves or upload it to other (hidden, but usually centralised) storage systems, and so on. And Tor has a concept of a "client", which is somebody who uses the service without providing any value to it; on Freenet, every node relays data for its neighbours. Hence the attacks on Freenet are completely different to the attacks on Tor. Both compromise to some degree to enable more or less real-time performance.

If you can use the darknet, trust your friends, don't reinsert files or insert easily predictable data (this requirement will be relaxed in 0.9), and change your anonymous identity after some volume of inserts, you should be relatively safe using Freenet. If you can connect, build up some trust in your anonymous persona, insert your controversial content, and then disappear, again, you are better off with Freenet, especially if the content is a website (but if you are connecting on opennet, beware of seednode compromises). In some other cases, Tor is better.

In Freenet 0.9, we will add a form of cryptographic tunnels, somewhat similar to Tor's onion routing; this should greatly reduce the impact of many of the below attacks.
Major known attacks:
In the interests of giving would-be users as much information as possible, and on the assumption that any serious attacker would do their homework, here are the major classes of attack on Freenet we are presently aware of:

• Harvesting: Simply by running some powerful Freenet nodes, an attacker can identify most of the opennet (Strangers network) relatively easily. These nodes can then be attacked one by one (subject to resources), their traffic analysed, or simply be blocked on a national firewall. Connecting only to friends largely solves this problem. It is still possible for ISPs to identify nodes with traffic flow analysis. Obviously a large network will make this harder. And this attack is trivial on Tor, although they provide a means to work around it.
• Datastore attacks: This is largely solved as of build 1224, we don't cache our local requests or inserts, and neither do the nodes immediately connected to us, to a depth of at least 2 hops (3 on inserts). However, if your node is older than that, seizing the store might give a bad guy some interesting information. Also note that the client-cache caches local requests (but not inserts), so it should be encrypted and passworded by setting the physical security level to HIGH, or turned off.
• Correlation attacks: If you are connected to a node, and can recognise the keys being requested (probably because it was posted publicly), you can show statistically that the node in question probably requested it, based on the proportion of the keys requested from that node, the locations of nearby nodes, the HTL on the requests and so on. This will be largely eliminated by tunnels.
• Adaptive search: If you want to find the author of some content, and you can predict the content or the keys to be inserted, you can listen out for their inserts. Each request gives you a data point suggesting roughly where the originator might be (on the location space), and on each insert you intercept you can move slightly closer to the originator, by obtaining connections to nodes which are closer to your current guesstimate of the target's location. If you are right these new connections will yield more of the target's requests/inserts, and you can rapidly close in on the originator. The best defense right now is darknet (connecting to friends only): Darknet makes it very difficult for an attacker to obtain new connections closer to his guess of where the target is. The tunnels proposal will likely make this attack considerably more difficult. Also, if the attacker cannot guess the content to be inserted in advance, this is very much more difficult (hence reinserting big files is bad); we will randomize the insertion keys in 0.9 to give additional protection for inserters. And of course this is of no use for tracing the author if the author has finished the insert and left the network: you have to intercept the insert while it is in progress.
• Traffic analysis: Freenet provides minimal protection against global traffic analysis (basic message padding etc); if the attacker also has nodes on the network, the extra data will likely be helpful. We certainly do not guarantee that it is impossible to trace data transfers from one node to the next with detailed traffic data, however it is hoped that this will fall down on the busier nodes. One day we will implement steganographic transports and/or constant bitrate links as an option for more paranoid users. Note that on Tor-style networks, global traffic analysis will defeat the network completely: all that is needed is to observe both the entry and exit points.
• Swapping attacks: It is possible to attack the location swapping algorithm, and thereby disrupt routing. This has been demonstrated by the authors of the Pitch Black paper. We are working on a solution, but this only affects the darknet (Friends network), which presently is a small proportion of the overall Freenet.

More information on the current practical state of Freenet security is available here.

Is Freenet vulnerable to flooding attacks?
Short answer: no.

Long answer:
We don't think so. Aside from protecting freedom of speech, Freenet is also designed to be an efficient dynamic caching system. If information is requested a lot from a limited number of nodes, the nodes that the requests pass through will cache the information, lowering the load on the network. If information is inserted on a limited set of nodes and then subsequently requested a lot from a separate set of nodes, with repetition, the sets will close in on one another in the network topology until they are "neighbors" and only the originally targeted nodes are suffering from the attack.

In other words, in order to harm Freenet with a flood you need to consistently change your point of entry into the network and continually insert and request new data, and you will still only increase the workload for the network that is linear to your own. Given an immense will and capacity greater than the total of the entire network, it is possible to cripple any public network (including the Internet itself) with floods, but it is our intention to always keep Freenet as resistant to this as theoretically possible.

Curiously enough, the above analysis only applies to Opennet. On Darknet, you might have a little more success, although it would be much harder to change your entry point in any significant way. Nonetheless, you have a reasonably low bandwidth multiplier (the total number of nodes visited, around 20 on average), and you are severely limited by the number of nodes you can connect to, which will be low on a darknet.

Why hash keys and encrypt data when a node operator could identify them (the data) anyway if he tried?
Hashing the key and encrypting the data is not meant a method to keep Freenet Node operators from being able to figure out what type of information is in their nodes if they really want to (after all, they can just find the key in the same way as someone who requests the information would) but rather to keep operators from having to know what information is in their nodes if they don't want to. This distinction is more a legal one than a technical one. It is not realistic to expect a node operator to try to continually collect and/ or guess possible keys and then check them against the information in his node (even if such an attack is viable from a security perspective), so a sane society is less likely to hold an operator liable for such information on the network.

What about hostile "cancer" nodes within the network?
The existence of malicious nodes within the network is the most difficult problem that a distributed network must face, and has been the bane of many previous ideas. Many systems (such as multiplayer gaming networks) try to avoid malicious nodes by keeping the protocol and code closed, but we have yet to see an example of that working in the long run. And anyway it is opposed to Freenet's philosophy.

Freenet is based on a balance of positive and negative feedback loops that bring requests for information to a node when it is functioning well, and keep requests away from it when it is not. The key to avoiding "cancers" is (as in the body) to make sure these loops can correctly identify even the most carefully designed malicious node and not keep sending requests to it. This issue is not fully dealt with by the current test code, but you can rest assured that a number of possible solutions have been on the table and discussed for some time now. Several have been implemented (enforcing hashes or signatures on content, per node failure tables, backing off from a node that causes timeouts ...)

What about attack Y?
Freenet is still in testing and there are bound to be attacks found that we have not dealt with yet. So if you do manage to figure out a truly new kind of attack, we are interested in hearing about it. Please keep in mind what Freenet is and what it is not, however. No single network can offer everybody everything, and there are security issues that Freenet, by it's nature, may not deal with to extent you might wish. If this upsets you, all of our code is freely available, so you are free to take as much of it as you like and write your own distributed network that suits your desires.

Where can I get a high quality copy of the rabbit icon?
Here.