|The Free Network Project|
Frequently Asked Questions About Freenet
The “Freenet” project aims to create an information publication system similar to the World Wide Web (but with several major advantages over it) based on the protocol described in Ian Clarke's paper A Distributed Decentralised Information Storage and Retrieval System. Information can be inserted into the system associated with a "key" (normally some form of description of the information such as "/text/philosophy/sun tzu/the art of war"). Later anyone else can retrieve the information using the appropriate key. In this respect it is a little like the World Wide Web which requires a URL to retrieve a particular document.
Unlike the Web, information on Freenet is not stored at fixed locations or subject to any kind of centralized control. Freenet is a single world-wide information store that stores, caches, and distributes the information based on demand. This allows Freenet to be more efficient at some functions than the Web, and also allows information to be published and read without fear of censorship because individual documents cannot be traced to their source or even to where they are physically stored. To participate in this system users will simply need to run a piece of server software on their computer, and optionally use a client program to insert and remove information from the system. Anyone can write a client (or indeed a server) program for Freenet, which is based on an open protocol. Reference implementations of these programs are being written in the Java programming language.
Ian Clarke is the project coordinator. Other developers are listed on the front page of the Freenet web site, and will change from time to time as volunteers join and leave the project.
Take a look on the Freenet homepage at http://freenet.sourceforge.net/. From there you will be able to view other documents about Freenet, view or join the discussion groups, download software, and more.
Freenet implements free speech, nothing more. It won't encourage or enable criminal behavior that wouldn't have happened without it, and it might actually help us better understand and deal with criminals. While our hope is that people under oppressive governments can use Freenet to describe their plight without retribution, it is also possible for a terrorist to publish on Freenet why he chose to bomb a building or hijack a plane. But that terrorist could have used other means anyway: a document on Freenet is like an anonymous letter to the New York Times — but one that always gets published. The public may learn more about such people and their motivations when these activities are more open. Remember that Ted Kaczynski was identified as the "Unabomber" only after he anonymously published his manifesto.
Sharing of copyrighted information is a similar issue: the network doesn't know the difference between public domain documents like a Shakespeare sonnet or Bach fugue, and copyrighted works like a Stephen King novel or Carlos Santana song. Because it makes sharing the former easier, it also makes sharing latter easier. This is perceived as a threat to traditional publishing and recording industries just as radio was, and the mimeograph, and television, and the photocopier, and magnetic tape, and the compact disc, and the videocassette recorder, and many other technologies that made sharing information easier. Freenet doesn't do anything different from what can already be done with those technologies, it just does it more efficiently. Artists and publishers all adapted to those new technologies and learned how to use them and profit from them; they will adapt to Freenet as well.
Freenet is a medium for freely broadcasting information to the world. Terrorists already have their own means of secret communication and are unlikely to want to tell the world their private plans. Similarly, pornographers are in the business of selling images. They gain no benefit from distributing them for free. If they want to post hot tips about their child abuse activities, that will just help the police catch them faster.
Libellous statements are no different on Freenet than in any other medium. Information cannot be deleted once posted, but the same might be said of a newspaper. If you can make someone publish a retraction in a newspaper, you can equally make her post a retraction to Freenet. Freenet does permit anonymous libel, but anonymous statements generally have only minor impact on reputation as compared to attributed statements. In any case, the subject is free to respond on an equal footing with the accuser, which is not the case in most other media. Furthermore, a libellous document which is not requested by any readers will eventually disappear like any other Freenet document.
While Freenet has the potential to assist copyright infringement, this battle has already been lost. Millions of copyrighted audio and video files are already being traded on the web each day — the absence of Freenet will not change that. Besides, by far the vast majority of copying activity does not take place online, but via old-fashioned, industrial-scale physical CD pressing.
Finally, Freenet does not exist in a vacuum. It is only as effective as the number of people who run nodes. If most people decide that Freenet is unsavory and not something they wish to be a part of, then it will be small and insignificant. (We hope this won't happen!) There are also proposals to allow "self-censorship" by node owners to remove content from their own machines. Of course, you will not be able to enforce your personal views on anyone else's node.
It isn't. Numerous proposals for managing the namespace have been examined; however the problem is that allowing the namespace to be "managed" implies some form of centralized control. Forcing keys to be hashes of the data solves this issue, but at the same time creates other problems. For the moment the current mechanism handles names on a first-come-first-served basis but with a little bit of democracy to prevent DNS-style abuse of the mechanism. This is one of the big issues that will be discussed and hopefully addressed in the next version.
No search mechanism has yet been implemented. One of the design goals was to make it impossible to locate the exact place where any piece of information is stored. Even a server operator cannot determine what is stored at his own node. This naturally makes searching very difficult. Information is currently retrieved by "keys" which should be guessable, or communicated by some other means.
Proposals for adding safe searching and indexing capabilities to Freenet are being discussed for the future. For example, Freenet documents can contain hyperlinks which could be spidered in the same way as the web. Alternately, lists of keywords or other metadata could be circulated through the network.
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.
Proposals for a more useful mechanism are being evaluated, and one of them will probably be implemented in an upcoming version of the protocol. For example, documents could optionally be inserted with public keys attached, and only updates signed by the corresponding private keys would be accepted. Unsigned documents would be immutable. Alternately, some type of versioning system could keep track of all previous versions of documents.
Each server operator specifies a maximum amount of storage which Freenet will use on his system. This will either be on disk or (for the paranoid) only in RAM. When the storage limit is reached, the least popular document (measured by some function of number of requests) is discarded to make room.
Freenet is not intended to be an eternal archive. Because the system is completely democratic, it does not inherently distinguish between the U.N. Universal Declaration of Human Rights and my kindergarten drawings — documents are scored solely by requests. It is anticipated, however, that the current low cost of storage will make enough storage available to Freenet that documents will only rarely have to be discarded.
The current implementation of Freenet does not take the size of documents into account, so a single large file might displace many small files. The scoring system is being modified to address this issue.
There is already one program called FCRC (available in the Freenet source tree) that acts as a gateway allowing Freenet data to ba accessed from the Web, and there are likely to be others. There is not at this time (March, 2000) any facility for Freenet nodes to distribute information currently stored on the Web. Freenet documents, of course, may contain URLs or other references to data stored elsewhere.
Superficially, Freenet will operate similarly to other information sharing systems like Napster and Gnutella. But since Freenet was designed for different goals, the underlying structure and behavior will be different. Napster, for example, relies on a single centralized server.
Freenet's decentralized, adaptive nature makes it more efficient than similar systems, more scalable, and less vulnerable to attack.
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.
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:
No, but it is preferred. You can run the software and test it from a "transient" connection (such as provided by typical modem/ISP setups), but for the network as a whole to be most useful, we will need as many permanent nodes as possible (most cable modem or DLS setups are suffiently "permanent" for this). A later version of Freenet may take better advantage of transient nodes.
The Freenet project is hosted at SourceForge. You will have to create an account for yourself there, then send email to the project coordinator asking him to add you to the group. Further details are available on the Freenet and SourceForge web sites.
To build and deploy the Freenet server, you will need Java tools compatible with Sun's JDK 1.1 or later. To retrieve and update the code at SourceForge you will need a network version of CVS, (This is not necessary if you only want to download, compile, and run the server without contributing to its code). To do web development you will need SSH. Further instructions for building and deploying the server are included with the code itself.
Yes. Currently, for example, there is a client program called Liberator (available in the Freenet source tree) written in Perl. Nothing in the protocol requires or expects Java programs, so as long as you follow the protocol you will be compatible.
Unfortunately at this time (March, 2000) the protocol is not yet well documented. This will be fixed soon.
Short answer: Probably yes.
Freenet does not offer true anonymity in the way that the Mixmaster and cypherpunk remailers do. Most of the non-trivial attacks (advanced traffic analysis, compromising any given majority of the nodes, etc.) that these were designed to counter would probably be successful in identifying someone making requests on Freenet.
On Freenet, whatever you do, your identity is still revealed to the first Freenet Node you talk to, and even if you limit yourself to talk only to trusted nodes (a feature that will be implemented in the future), they will have to talk to the rest of the network at some time or another. The anonymity that Freenet offers is really just obscurity in the fact that it is hard to prove that your node wasn't proxying the request for or insert of data on behalf of somebody else (who might also just have been proxying it).
The problem is that the only way that you can offer true anonymity is if the client can directly control the routing of data, and thus encrypt it with a series of keys of the nodes it will pass through (à la Mixmaster). Freenet's dynamic routing cannot offer that, so to attain true anonymity you have to send the message through an external network of anonymous remailers first (a future SMTP->Freenet bridge would make this possible).
It is our intention that Freenet's node-to-node communications should be encrypted, but that has not been implemented either (with the current state of the network we are more interested in testing if the theoretical ideas regarding the routing carry over into reality; you have to have a house before you can lock the door).
Short answer: no.
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.
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.
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 (for example allowing clients to vote on the validity of the information returned on requests, and enforcing that all information be indexed by a hash of the contents at the lowest level) have been on the table and discussed for some time now.
No. Freenet nodes only serve information that has been deliberately inserted by someone who wanted the information to be shared. Since the code for the project is all open, you can examine it yourself to verify this. Of course, if you or someone else does deliberately insert information that you would rather keep private, you have little recourse.
It is likely that the damage caused by leaks of personal information to Freenet will be small in any case. When the source of such information is identifiable, traditional legal remedies can be applied. When the source is anonymous, such information will have no credibility.
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 (like anonymity, discussed above) that Freenet, by it's nature, will never 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.
Some web browsers mistakenly save .tgz files (such as the daily CVS snapshots) with a .tar extension after downloading. Rename the file to .tgz so WinZip will know how to deal with it properly.
WinZip may then tell you that the archive contains a single .tar file, and ask if you want to decompress it to a temporary file and open it. This is actually correct — the .tgz is a compressed version of a single .tar file, which is what you want to open. Answer yes and it will do the right thing.
Most likely the setting of your CLASSPATH. Under Java VMs based
on Sun's JDK 1.1, every directory, JAR, or ZIP file from which
classes might be loaded (including the standard ones) must be
specified in the
Note in particular that the
Usage under Java VMs based on Sun's JDK 1.2 or later (the "Java
2 Platform") is simpler, because you can use the
A more user-friendly installation system is one of the project's current priorities.
In order to bootstrap your connection into the Freenet network, you must discover the address of at least one other node through out-of-band means. This might be word-of-mouth, email, websites, even advertising. Once you have an initial connection your node will automatically start to learn about other nodes that your initial neighbor knows about, which will then tell you about other nodes, and so on.
To make things simple in the testing phase, we have a temporary webpage which lists some of the nodes that are currently running. This page is located at:
By default, your node will automatically add itself to the list
when it starts up, and read the list to get an initial set of nodes
to connect to. If you wish to disable either of these behaviors,
and you will be removed.
Again, we envision that Freenet keys will ultimately be spread through means such as word-of-mouth, email, or (perhaps most importantly) links in other Freenet documents. Analogously, you need to be told an initial URL through out-of-band means to begin surfing the web, but once you have a few starting points you can navigate links to anywhere you like. External sources may even index Freenet in the same way that Yahoo and Altavista index the web. We are also working on adding search capabilities within Freenet itself, to avoid reliance on such central servers. See the FAQ question "Is Freenet searchable?" for information on this.
During the testing phase, to make things easier, we have set up a couple of key indexes where you can find existing keys and submit new ones if you like. The list of indexes can be found at:
You can either look at this page in a web browser, or use the
There is also an IRC keyserver bot which lives in channel
Note that the key lists are in no way exhaustive or even accurate — the files they refer to might not be available if too many nodes are down, or the keys may have been mistyped (they are not submitted automatically, for security reasons). If you would like to automatically submit keys to the index when inserting into Freenet, do something like:
It means that your client is not recognizing the messages it's getting back from the node. At the moment, this seems to be mostly caused by the node being overwhelmed with stuck connections and not responding to new ones. Kill your node, wait a minute or two for the connections to get flushed out, and restart it. Another possible cause is that the node is speaking a different protocol version from you and one of you needs to be upgraded.
It means that a newer node version has been committed — please check the Freenet home page to see if there are any announcements on whether the change breaks backwards compatibility with older versions. Even if it doesn't, please upgrade to the latest CVS snapshot if you can.