Below is an updated version of the old English faq...
It still contains some old things.
Feel free to update or modify this faq.
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 (see here). Information can be inserted into the system
associated with a "key" (normally some form of description of the
information such as "KSK@gpl.txt").
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.
- Freenet does not have any form of centralized control or
administration.
- It will be virtually impossible to forcibly remove a piece of
information from Freenet.
- Both authors and readers of information stored on this system
may remain anonymous if they wish.
- Information will be distributed throughout the Freenet network
in such a way that it is difficult to determine where information
is being stored.
- Anyone can publish information. They don't need to buy a domain
name or even a permanent Internet connection.
- Availability of information will increase in proportion to the
demand for that information.
- Information will move from parts of the Internet where it is in
low demand to areas where demand is greater.
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 <a href=
"http://freenet.sourceforge.net/">
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.
Cryptographic signing of information allows people to prove
authorship, this technique is frequently used to authenticate
authorship of emails. Moreover, you could actually sign information
while remaining anonymous, thus having an anonymous persona. You
could prove that you wrote different pieces of information on
Freenet, without revealing your identity. In this way you could
build up an anonymous reputation for reliability.
What are these "key types" I keep hearing about? KSK, CHK, SSK, whatnot ...
Freenet keys come in different varieties called ''key types''. Typically this type is included at the beginning of a key, delimited by an at-sign (@). The types are:
* '''CHK''': The ''content hash key'' is the workhorse on which other key types build. Every document has a corresponding ''hash'' value that serves as it's key. Two equal documents have equal hashes, so if different people insert the same document, this yields the same CHK. At the same time the hash function is built so that two different documents are very very unlikely to have the same hash (and therefore CHK). For all practical purposes, there is a one-to-one correspondence of CHKs to documents. Example: CHK@wQYjaBkpulyIBq4sbvyDL2NZ7ToPAwI,qW4hMEc6NWsx-T-etpfPAg
All the other key types usually redirect to a CHK. So fundamentally, all real content is behind a CHK.
* '''KSK''' These are fully free-form, so can be used to tag nice, descriptive names to content. By loose convention they are seen as a hierarchic system, with levels seperated by dashes. Example: KSK@plays/Shakespeare/Coriolanus
* '''SSK''' A ''secure subspace key'' consists of a prefix specifying the subspace, followed by a free-form name placing the key inside the subspace. Actually each subspace has two prefixes associated with it, one used for inserting, the other for retrieval of keys. The insert prefix is normally kept secret, while the retrieval prefix is given out freely. This achieves that only the holder(s) of the secret prefix may put content into the subspace, while everybody may get content out.
(See previous question for more on CHK, KSK, SSK.) Central management (and therefore control) of the namespace is one of the things Freenet was designed to avoid.
CHKs don't need to be managed, every document has its CHK and can't have another one (without changing the document itself).
KSKs can be freely choosen on a first-come-first-serve basis. This may become problematic, when someone thinks it worthwhile to "squat" on all the possible combinations of eight characters. Unlike with http-URLs, though, when KSK@freenet is taken, all keys beginning with that (e.g. KSK@freenet/two) are still available.
SSKs offer everyone a private part of the namespace. The prefix is randomly generated, and of equal length, so competition for the nicest should be scarce. Somewhat like a DNS domain, the holder of a subspace has sovereignity over it.
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.
One may employ a ''date-based redirect'' (DBR), though -- these are evaluated according to the current time and date. A DBR with a frequency of a day will point at a new target key every 24 hours. If this new target is always inserted before the DBR rolls over, the illusion of having the "same" document that is still updatable is achieved. If nothing resides at the current target, it appears as if the content were "deleted".
It should be noted, though, that by not going through the DBR one can access the target corresponding to any time in the past (as long as the content has not been "pushed out" to make room) or future (as long as the content has been already inserted).
Each server operator specifies an amount of storage which
Freenet will reserve on his system. When Freenet's store is full, the
least popular document (measured by some function of number of
requests) is discarded to make room.
! What prevents important documents from being discarded?
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
Freenet distributions) that acts as a gateway allowing Freenet
data to be accessed from the Web, and there are likely to be
others. Fproxy, included with Freenet makes Freenet available to browsers, and therefore integrates it into the Web for some people (per default, only local access is allowed).
There is not at this time (October, 2001) any facility for
Freenet nodes to distribute information currently stored on the
Web. Of course mirroring inserting a copy of a web page or even a whole site into Freenet is easy enough and has been done before. Documents that are stored in Freenet may also contain URLs or other references to data stored elsewhere. When viewing an in-Freenet HTML document through Fproxy links outside Freenet work transparently except for an anonymity warning.
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. In ''Gnutella'' searching is somewhat anonymous, but neither the publishing nor the retrieval of information is.
Freenet's decentralized, adaptive nature will make it more efficient
than similar systems, more scalable, and less vulnerable to
attack.
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 this FAQ).
- Contribute your ideas to the discussion lists.
- If you are a developer, you can also help by designing and
developing other applications to run on Freenet.
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.
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.
- Java is one of the most cross-platform languages currently
available.
- There are free Java implementations available such as Kaffe. We will ensure that
Freenet is always compatible with these versions even if Sun
attempts to make it more difficult for free Java implementations to
keep up with their proprietary versions.
- Java has excellent network support.
- Java is easier to debug than other languages such as C++. This
lets us get on with the business of implementing Freenet quickly
and reliably!
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.
Short answer: Probably yes.
Long answer:
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).
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.
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.
The initial Freenet server code is written in Java, so it will
theorectically run on any platform with a Java runtime. The core
developers mostly run on Linux, and there are many Windows users as
well. It has been reported that it can be made to work on the
Macintosh, but the Java implementations available there are limited
and buggy, and we have little expertise there.
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 -classpath argument on the
java command line. For example, if your JDK 1.1 is in the
directory /usr/jdk11 , and you have built
Node.class in /home/lee/Freenet , then your
(Unix) command line should look like:
java -classpath
/usr/jdk11/lib/classes.zip:/home/lee Freenet.node.Node
&
Note in particular that the Freenet directory
should not itself appear in the path, only the directory above it.
A similar command line can be used to start the Node under JDK 1.1
for Windows, but omit the "& " and use
"; " between classpath parts rather than
": ".
Usage under Java VMs based on Sun's JDK 1.2 or later (the "Java
2 Platform") is simpler, because you can use the -cp
option to add a directory to the standard CLASSPATH:
java -cp /home/lee Freenet.node.Node
&
A more user-friendly installation system is one of the
project's current priorities.
If you are using the latest code, and having issues with FproxyServlet and NodeStatusServlet being missing, it is because some things have changed in recent CVS. The Freenet class was lowercased, so you need to change the lines in your configuration file from:
fproxy.class=Freenet.client.http.FproxyServlet
nodestatus.class=Freenet.client.http.NodeStatusServlet
to
fproxy.class=freenet.client.http.FproxyServlet
nodestatus.class=freenet.client.http.NodeStatusServlet
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 <a href=
"http://freenet.sourceforge.net/snapshots/">latest CVS snapshot
if you can.
|