User Anonymity
hal@finney.org
hal@finney.org
Sat, 17 Feb 2001 23:56:28 -0800
Wei writes:
> Entanglement is not really a viable defense since the censor can
> always require you to remove the data regardless of whether it's
> entangled.
Another possible defense is that the material being stored is not
the copyrighted data, but scrambled bits. Mojo Nation appeared to
be considering a similar approach, according to the Oct 28 article at
http://www.thetimes.co.uk/article/0,,26347,00.html:
The companyŐs defence lies in the Digital Millennium Copyright Act,
which states that Internet service providers cannot be held liable
for their usersŐ activities as well as the way the software works.
Instead of carrying whole files at a time, Mojo NationŐs software
breaks down files into encrypted bite-size pieces which, like
flat-pack furniture, are only reassembled once they reach their
destination. Transporting files in this way not only makes it easier
for users with less powerful computers to download big files, but
also means the company is distributing encrypted data rather than
content which can be subject to copyright laws.
I doubt that this would hold up in court though. The copyright holder
would argue that the information is there and can be recovered by end
users; the details of how it is stored should not matter. You'd have
to look at the specifics of how the laws are worded to be sure.
Hal
From Ted Anderson <ota@transarc.com> Sun Feb 18 17:59:48 2001
Message-ID: <3A9053D8.8C8A172A@transarc.com>
Date: Sun, 18 Feb 2001 17:59:36 -0500
From: Ted Anderson <ota@transarc.com>
Organization: Transarc Corporation
X-Mailer: Lyris List Manager Newsgroup Interface
MIME-Version: 1.0
Newsgroups: bluesky
Subject: Re: the three-services model
References: <LYRIS-126359-19739-2001.02.17-12.27.41--weidai#eskimo.com@ibiblio.org> <95285@bluesky>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: bluesky
I think Wei Dai's separation of components is a good one.
We need to be clear exactly what trust each component provides. As Hal
said there are various types of trust; it is easy to get confused.
Using content hashes as ids provides a trusted name for a bunch of data.
It is a shorthand for the data itself. The space and time distribution
system doesn't have to be trusted not to mangle the data it is shipping
and storing. So the trust that content hashes provide is only that the
distribution system is not corrupting the data.
There is still the matter of attaching human readable names to content
hashes. Both a file system directory and an HTML web page provide
mappings between names and URIs and could be linked into a namespace
that could be used to attach useful names to content hashes.
Ultimately, I don't think there is any avoiding the need to use digital
signatures to investing trust in this mapping.
You can think of these mappings (e.g. directory entries or web links) as
statements. Namely, principal A *says* name N *means* content C. A
signature connects "N -> C" to "A", it is essentially a certificate. To
decide whether this mapping is useful we need to evaluate our trust in
"A". This problem has been much studied in connection with public key
systems (such as SDSI[1] and SPKI[2]) and we can use some of their ideas
in designing the namespace of the storage system.
Separating the naming from the distribution systems this way has an
interesting effect on the permission model. Instead of having the file
server control read and write access to data, two radically different
mechanisms are needed. Read permission is controlled using encryption
and carefully handing out the keys. Write permission devolves to
control of the namespace. The read case is pretty easy to understand
and giving users (forcing them to accept) real control over the data
they produce may be a "killer-app" for end-user PKI. The write case is
more subtle: what does it mean to write a file? In this model a write
changes the "meaning" of a name and hence the mapping between a file's
name and some content.
This goes directly to the issue of following links and revising history.
Sometimes you want the old, original contents that a name mapped to and
other times you want the latest mapping of the name to its current
contents. In practice, the namespace probably can't keep track of all
meanings a name ever had, but it certainly can keep an interesting
subset if the owner of the (relevant portion of the) namespace wants to.
To support both cases the distribution system should just use content
hashes and let users decided, when, whether and how much they trust
namespace owners.
Ted
[1] http://theory.lcs.mit.edu/~cis/sdsi.html
[2] http://www.pobox.com/~cme/html/spki.html