Recently the Internet has seen tremendous growth, with the ranks =
of new=20
users swelling at ever-increasing rates. This expansion has catapul=
ted it=20
from the realm of academic research towards new-found mainstream ac=
ceptance=20
and increased social relevance for the everyday individual. Yet wit=
h this=20
suddenly increased reliance on the Internet comes the threat that f=
reedoms=20
previously enjoyed may be overlooked in the online realm.=20
The World Wide Web (WWW) has recently grown in importance to beco=
me perhaps=20
the most important Internet application today. The WWW enables the =
ordinary=20
citizen to reach an audience potentially as large as millions. In s=
hort,=20
this technology gives us an extremely cheap publishing mechanism: p=
rinting=20
presses for the masses.=20
Yet we must not forget that anonymous publishers have played an i=
mportant=20
role throughout the history of publication. Freedom of anonymous sp=
eech=20
is an essential component of free speech, and freedom of speech is =
a critical=20
part of any healthy democracy. For instance, the United States Supr=
eme Court=20
has consistently upheld protection for anonymous publication of pol=
itical=20
speech. As Justice Stevens wrote in the McIntyre v Ohio Election=
Commission=20
majority opinion,=20
Under our Constitution, anonymous pamphleteering is not =
a pernicious,=20
fraudulent practice, but an honorable tradition of advocacy and of =
dissent.=20
Anonymity is a shield from the tyranny of the majority.
![](3D"g1.gif")
We should be careful not to forget the importance o=
f anonymous=20
speech as we move to an increasingly WWW-centric paradigm of commun=
ication.=20
Today the WWW includes little support for anonymou=
s publishing.=20
The current WWW architecture fundamentally includes identity inform=
ation=20
in the URL that is used to locate published documents, and it is ve=
ry hard=20
for a WWW publisher to avoid revealing this information. To address=
these=20
limitations, we would like to build technology to enable anonymous =
publishing=20
on the World Wide Web.=20
![](3D"../../../buttons/quad.gif")
=20
=20
Motivation
We briefly motivate this work with a few potential applications f=
or anonymous=20
WWW publishing. We hope these will help provide some of the general=
flavor=20
for the requirements and illustrate the goals of such a publication=
service.=20
First, we note that anonymous publication is a time-honored tradi=
tion.=20
The Founding Fathers of the United States published the Federali=
st Papers=20
(arguing for the adoption of the Constitution) anonymously under th=
e pseudonym=20
Publius. Before the American Revolution, many had to publish secret=
ly because=20
of the very real danger of English prosecution.=20
Across the world, from medieval times to the current age, governm=
ents=20
have tried to suppress unwanted speech. Political dissidents have o=
ften=20
turned to secret printing and distribution of anonymous leaflets, b=
ooks,=20
and other publications. Moreover, dissidents have frequently taken =
advantage=20
of technology for expression of controversial ideas: the Protestant=
Reformation=20
was greatly aided by the invention of the printing press, which ena=
bled=20
widespread distribution of many copies of the Bible; the French "Vo=
ice of=20
the Resistance" used nightly radio broadcasts from constantly-chang=
ing temporary=20
locations to reach the people during the German occupation; the Uni=
ted States=20
used high-power radio stations such as Radio Free Europe during the=
cold=20
war to combat censorship behind the Iron Curtain; in past years, ba=
nned=20
information was copied through underground channels from person to =
person=20
in the Soviet Union, in a process known as samizdat (which is Russi=
an for=20
"self-publishing"); and when the Serbian government began jamming t=
he Belgrade=20
independent radio station during the Serb-Croat war, Serbian studen=
ts used=20
the World Wide Web to mirror broadcasts and combat the government's=
censorship=20
[1].=20
Our vision combines many key aspects of these historically-succes=
sful=20
approaches. First, we want to take advantage of the highly-favorabl=
e economics=20
and vast potential audience available to WWW publishers. Second, we=
wish=20
to use anonymity to avoid suppression of controversial ideas: when =
the targeted=20
party cannot be identified, it is much harder to bring legal and ot=
her pressure=20
on the author or printer. Third, we aim to gain resilience through =
the grass=20
roots nature of samizdat channels. Fourth, because government burea=
ucracy=20
often limits the speed with which full legal and other pressure can=
be brought=20
to bear on targets to time periods measured in months or years, we =
wish=20
to enable temporary stations to pop up and disappear just as rapidl=
y. Through=20
a combination of these techniques, we hope to build a robust infras=
tructure=20
for anonymous WWW publishing.=20
=20
Background
A few definitions are in order. Anonymity refers to the ability o=
f an=20
individual to prevent others from linking his identity to his actio=
ns. We=20
can divide anonymity into two cases: persistent anonymity (or pseud=
onymity),=20
where the user maintains a persistent online persona ("nym") which =
is not=20
connected with the user's physical identity ("true name"); and one-=
time=20
anonymity, where an online persona lasts for just one use. The key =
concept=20
here is that of linkability: with a nym, one may publish a number o=
f documents=20
that are all linked together but cannot be linked to the author's t=
rue name;=20
by using one-time anonymity for each work, none of the documents ca=
n be=20
linked to each other or to the user's physical identity. Forward se=
crecy=20
refers to the inability of an adversary to recover security-critica=
l information=20
(such as the true name of the writer of a controversial article) "a=
fter=20
the fact" (e.g. after the writing is published); where possible, pr=
oviders=20
of anonymity services should take care to provide forward secrecy, =
which=20
entails (for instance) keeping no logs.=20
We can identify a number of goals for a potential anonymous WWW p=
ublishing=20
infrastructure. First, we should be clear that we only concern ours=
elves=20
with the problem of anonymity for the publisher. In contrast, some =
existing=20
services, such as the Anonymizer proxy [2], aim to provide privacy for the user who is viewing W=
WW pages;=20
we explicitly do not attempt to solve that problem. We note that th=
e client=20
privacy problem is orthogonal to the anonymous publishing problem, =
and that=20
the two problems compose well: if full anonymity is needed (to prot=
ect the=20
identity of both endpoints), techniques to anonymize the client wil=
l work=20
well in tandem with an infrastructure for anonymous WWW publishing.=
=20
We should also point out another problem we explicitly avoid solv=
ing.=20
Our infrastructure may reveal the fact that a particular server hol=
ds anonymous=20
published data, so long as it does not reveal the data itself or al=
low the=20
document to be linked to the author. In short, documents and author=
s may=20
each be individually recognized as anonymous, but we aim to prevent=
the=20
possibility of linking any one document with its author. As long as=
there=20
are sufficiently many anonymous authors (some of whom are respected=
citizens)=20
and sufficiently many anonymous documents (some of which are non-co=
ntroversial=20
and clearly harmless), there will be "safety in numbers": even if A=
lice=20
is identified as an author who has published something ano=
nymously,=20
Alice will retain very strong plausible deniability protections - t=
he infrastructure=20
will give authorities no reason to suspect that she is involved in =
writing=20
anything other than harmless documents.=20
We view anonymous WWW publishing as a problem which can benefit f=
rom the=20
experience, approaches, and perspectives of computer security resea=
rchers.=20
In particular, we attempt to identify the relevant threats, design =
robust=20
countermeasures, take advantage of defense in depth, and apply othe=
r standard=20
security engineering techniques.=20
![](3D"g2.gif")
One important goal is to avoid the existence of a central single p=
oint=20
of failure. Any such single point of failure becomes a very attract=
ive target=20
- a sitting duck for the motivated adversary. Instead, we strongly =
prefer=20
to distribute trust to obtain resilience in the event that a few ne=
twork=20
nodes are compromised or colluding. We wish to see a means by which=
users=20
can protect their privacy, preferably by putting privacy-enhancing =
technology=20
directly into their own hands inasmuch as is possible. Where the co=
operation=20
of others is necessary to ensure personal privacy, the system shoul=
d not=20
be easily subverted by the mere collusion or compromise of a few pa=
rticipants.=20
A corollary is that we should attempt to minimize the length of t=
ime which=20
a node possesses security-critical information. By limiting the exp=
osure=20
of information that would reveal the identity of publishers, we red=
uce the=20
severity of the risk of compromise. In other words, supporting forw=
ard secrecy=20
is prudent security practice.=20
We must recognize that in practice there will be tradeoffs betwee=
n security=20
and other factors such as performance, availability, stability, etc=
. Different=20
publishers will likely require different levels of security, and th=
e only=20
party who can soundly evaluate the appropriate degree of security i=
s the=20
publisher himself. Therefore, an important design goal is a flexibl=
e security=20
strength "knob" under control of the individual publishers: publish=
ers should=20
be able to select the level of security that is appropriate for the=
mselves.=20
At this point, it is probably appropriate to offer a quick summar=
y of=20
some possible threats to an infrastructure for anonymous WWW publis=
hing.=20
A minimal threat model might concern itself primarily with politica=
l, legal,=20
and social attacks, and give less attention to traditional computer=
security=20
attack techniques. For instance, an adversary might obtain a subpoe=
na from=20
a judge of relevant jurisdiction to compromise a targeted node in t=
he distributed=20
infrastructure. Even an adversary with few resources can recruit th=
e power=20
of the government to his advantage with such a tactic. Social press=
ure is=20
a concern as well; carefully-fabricated complaints to a site admini=
strator=20
with power over the targeted node may also suffice.=20
A more cautious threat model will need to take into account the t=
hreat=20
of computer intrusion and attacks on the underlying network. Typica=
lly,=20
individual hosts are rather hard to secure, and in practice motivat=
ed penetration=20
attempts will often succeed in compromising a significant number of=
nodes.=20
Furthermore, unprotected network traffic is well-known to be easy t=
o monitor,=20
redirect, forge, and modify. In cryptographic circles, the adversar=
y is=20
often presumed to have complete control over the network; while tha=
t may=20
seem a rather paranoid assumption, we know that any system that can=
stand=20
up to that level of attack will provide very strong security. Howev=
er, in=20
practice such threat models may lead to unrealistic designs. Theref=
ore,=20
we ought to carefully consider the resources available to likely ad=
versaries,=20
and tailor the countermeasures to the anticipated threat level. It =
is probably=20
realistic to assume that a limited number of nodes will be compromi=
sed,=20
dishonest, or colluding; that the opponent may occasionally be able=
to successfully=20
penetrate targeted nodes of his choosing; that the adversary may be=
eavesdropping=20
on certain segments of the network; and that the opponent can perfo=
rm traffic=20
analysis (statistical analysis using only unencrypted header d=
ata such=20
as source and destination addresses as well as timing coincidences)=
using=20
the eavesdropped information. We will attempt to design an infrastr=
ucture=20
that is flexible enough to admit variations that will work under a =
wide=20
array of threat models.=20
Lest we get caught up in the details of obscure security threats,=
it is=20
important to remember that security systems can only provide securi=
ty if=20
they are used. Therefore, we must take care to ensure that usabilit=
y is=20
not sacrificed without careful consideration. In particular, we wan=
t to=20
preserve the vast potential audience provided by the World Wide Web=
, and=20
so we require that WWW pages published anonymously using our infras=
tructure=20
be accessible from standard WWW browsers without needing any specia=
l client=20
software or anonymity tools. The anonymity services ought to be tra=
nsparent=20
to the browser software and WWW page reader. In short, enabling wid=
espread=20
deployment and use of this infrastructure is a central goal of this=
work.=20
=20
Existing Technology
In this section, we describe some existing privacy-enhancing tech=
nologies=20
for the Internet [3], in order to see what part=
s of the=20
solutions they offer can be carried over to the problem of protecti=
ng the=20
identity of WWW publishers.=20
In past years e-mail was the most important distributed applicati=
on, so=20
it should not be surprising that early efforts at bringing privacy =
to the=20
Internet primarily concentrated on e-mail protection. Today the les=
sons=20
learned from e-mail privacy provide a foundation of practical exper=
ience=20
that is critically relevant to the design of new privacy-enhancing =
technologies.=20
The most primitive way to send e-mail anonymously involves sendin=
g the=20
message to a trusted friend, who deletes the identifying headers an=
d resends=20
the message body under his identity. Another old technique for anon=
ymous=20
e-mail takes advantage of the lack of authentication for e-mail hea=
ders:=20
one connects to a mail server and forges fake headers (with falsifi=
ed identity=20
information) attached to the message body. Both approaches could al=
so be=20
used for anonymous posting to newsgroups. Of course, these techniqu=
es don't=20
scale well, and they offer only very minimal assurance of protectio=
n.=20
The technology for e-mail anonymity took a step forward with the =
introduction=20
of anonymous remailers. An anonymous remailer can be thought of as =
a mail=20
server which combines the previous two techniques, but using a comp=
uter=20
to automate the header-stripping and resending process [4].=20
There are basically three styles of remailers; we classify remailer=
technology=20
into "types" which indicate the level of sophistication and securit=
y.=20
The anon.penet.fi ("type 0") remailer was perhaps the mo=
st famous.=20
It supported anonymous e-mail senders by stripping identifying head=
ers from=20
outbound remailed messages. It also supported recipient anonymity: =
the user=20
was assigned a random pseudonym at anon.penet.fi, the rema=
iler=20
maintained a secret identity table matching up the user's real e-ma=
il address=20
with his anon.penet.fi nym, and incoming e-mail to the nym=
at anon.penet.fi=20
was retransmitted to the user's real e-mail address. Due to its sim=
plicity=20
and relatively simple user interface, the anon.penet.fi re=
mailer=20
was the most widely used remailer; sadly, it was shut down recently=
after=20
being harassed by legal pressure [5].=20
The disadvantage of a anon.penet.fi style (type 0) remai=
ler is=20
that it provides rather weak security. Users must trust it not to r=
eveal=20
their identity when they send e-mail through it. Worse still, pseud=
onymous=20
users must rely on the confidentiality of the secret identity table=
- their=20
anonymity would be compromised if it were disclosed, subpoenaed, or=
bought=20
- and they must rely on the security of the anon.penet.fi =
site=20
to resist intruders who would steal the identity table. Furthermore=
, more=20
powerful attackers who could eavesdrop on Internet traffic traversi=
ng the=20
anon.penet.fi site could match up incoming and outgoing me=
ssages=20
to learn the identity of the nyms. Worst of all, anon.penet.fi<=
/tt>=20
becomes a central single point of failure, and it is very dangerous=
to have=20
such an attractive target.=20
Cypherpunk-style (type I) remailers were designed to address thes=
e types=20
of threats. First of all, support for pseudonyms is dropped; no sec=
ret identity=20
table is maintained, and remailer operators take great care to avoi=
d keeping=20
mail logs that might identify their users. This diminishes the risk=
of "after-the-fact"=20
tracing. Second, type I remailers will accept encrypted e-mail, dec=
rypt=20
it, and remail the resulting message. This prevents the simple eave=
sdropping=20
attack where the adversary matches up incoming and outgoing message=
s. Third,=20
they take advantage of chaining to achieve more robust sec=
urity.=20
Chaining is a technique that involves sending a message through sev=
eral=20
anonymous remailers; we discuss chaining more completely below in <=
a href=3D"#hand">"The=20
Problem at Hand"
![3D"First](3D"../../../img/logo=)
![=3D"TAZ](3D"navn.gif")
![](3D"g3.gif")
![3D"tex2html_=](3D"img3.gif")
. A plot of this value for various values of k =
appears=20
in