From: Ryan Lackey <rdl@mit.edu>
To: Adam Back <aba@dcs.ex.ac.uk>
Message Hash: 2a6fcc2cccc20d2041ab891afaa81959b4dc7c20b666437add490a8c6339b4e2
Message ID: <199801120405.XAA12512@the-great-machine.mit.edu>
Reply To: <199801112306.XAA00525@server.eternity.org>
UTC Datetime: 1998-01-12 04:11:11 UTC
Raw Date: Mon, 12 Jan 1998 12:11:11 +0800
From: Ryan Lackey <rdl@mit.edu>
Date: Mon, 12 Jan 1998 12:11:11 +0800
To: Adam Back <aba@dcs.ex.ac.uk>
Subject: Re: Eternity Services
In-Reply-To: <199801112306.XAA00525@server.eternity.org>
Message-ID: <199801120405.XAA12512@the-great-machine.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain
-----BEGIN PGP SIGNED MESSAGE-----
Adam Back <aba@dcs.ex.ac.uk> writes:
>
> Tim May <tcmay@got.net> writes:
>
> > Any file system which can be identified as to *location in some legal
> > jurisdiction*, espeically in the U.S. but also probably in any
> > OECD/Interpol-compliant non-U.S. locations, will be subject to COMPLETE
> > SEIZURE under many circumstances:
> >
> > * if any "child porn" is found by zealous prosecutors to be on the system(s)
>
> I think child porn is pretty much the canonical example -- the spooks
> / feds have a history of posting their own child porn if none is
> available to seize. (eg The Amateur Action BBS case which Tim cites
> classic case -- the Thomases had not had any dealings with child porn,
> but a US postal inspector mailed some to them, and busted them for it
> before they had even opened the package. They are still in jail
> now.)
>
> I agree with Tim that actually building distributed file systems where
> data can be traced back to the server serving it will cause problems
> for the operators. I think even if there are many operators, and even
> if the data is secret split, the operators would likely be held
> liable.
I agree as well.
>
> Ross's paper describes some techniques for building a distributed
> database which makes it difficult for a server to discover what it is
> serving. (Necessary because an attacker will become a server operator
> if this helps him).
>
> The threat of seizure is the reason that I focussed on using USENET as
> a distributed distribution mechanism. All sorts of yucky stuff gets
> posted to USENET every day, and USENET seems to weather it just fine.
>
> The idea of using new protocols, and new services as Ross's paper
> describes is difficult to acheive a) because the protocols are more
> complex and need to be realised, and b) because you then face
> deployment problems with an unpopular service and supporting protocols
> who's only function is to facilitate publishing of unpopular
> materials.
Solved, I think a) someone drops out of MIT and works on Eternity DDS to
the point where people want to dump money into it, assuming it is
a fundamentally good idea, and b) by using market based protocols which give
a financial incentive to people running stuff, there is a rush to set up
eternity servers.
In my system, no one knows (ideally) who is actually storing the data, only
those on the edges of the system (who will hopefully only be known by
a logical address).
>
> The solution I am using is to keep reposting articles via remailers.
> Have agents which you pay to repost. This presents the illusion of
> persistance, because the eternity server will fetch the most recent
> version currently available in the news spool. This avoids
> centralised servers which would become subject to attack, all that is
> left is a local proxy version of an eternity server which reads news
> from an ordinary news spool.
That sounds like an interesting idea. It is certainly far simpler to
implement than my suite of protocols.
> > - purely cyberspatial locations, with no know nexus
> >
> > (I point to my own "BlackNet" experiment as one approach.)
You may have solved the problems of persistence in Eternity, and if users
are intelligent about picking addresses, you may have solved the persistent
and logical URN problem. Cool!
I'm not sure the problems of scaling to a full production system have been
addressed,
though. Would usenet simply ignore the additional, and potentially highly
illegal,
and non-readable traffic? alt.binaries.warez got punted pretty quickly.
Also, your
scheme does not include any provisions for people to post active objects of
any kind, or market-based load balancing, both of which I consider critical
features -- people will overload any Eternity server they can find -- what
financial
motivation would the overt owners of the server have to upgrade to handle the
traffic?
USENET is also not quite as resilient as it used to be.
I may have an unreasonable bias against usenet, but I think any protocol which
depends
upon USENET rather than just using it as one of many potential transport
mechanisms
is unable to scale. Certainly the performance of your Eternity implementation
will
be far from real time. Coupled with not providing dynamic objects of any
kind, I think
there are a large number of services which could not function in your system.
It's still has a lot of potential, and is actually highly feasible to
implement, which is
good. And you seem to be evolving it, which leads me to think any potential
problems
will eventually be solved. It would be interesting if we could share
components which
were common to both designs, such as a payment arbitrator or whatever.
Having multiple interoperable Eternity implementations would actually be
really interesting.
They could store data in each other, in something of a recursive auction
market (the
data taken from a user commands a premium price immediately because it's
"hot", once
it gets buried a bunch of times it is a bit more shielded), share payment
protocols, etc.
Letting the market decide where it wants to put its data seems like the best
plan.
- --
Ryan Lackey
rdl@mit.edu
http://mit.edu/rdl/
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQEVAwUBNLmWnqwefxtEUY69AQGdzAf+PAbPSbO202uPSBJImJ9JDryHvWRvMA5H
QSdh+nsAq2dvXUkLm+ReJfYs4PDTimhBPYLxiAo/ooMeAsWwzCMNjFHeqS6V5VCV
dM4mJ37SsNTauVtcvWTTBJELlq4kzOjV2Lyn/eDvWwdnhvIv24mWclUZy8EC+0b6
+KEFktcK25SIIO0VH/fezHixawl+AiM1LATxMm8chmc4FTiHUc6swTSulOap0zeT
te21+zPuq0N5stzRPDfTePrjhneR3Zku9hq0sxK0Nbzaz790Jb4jh+q2XsFK0ow+
JiQZ59dj4bGHjq2H1u4TVcHQ/B16LZDxUz1nyvfw2uPBldmIQ0XSYw==
=AfMI
-----END PGP SIGNATURE-----
Return to January 1998
Return to “Tim May <tcmay@got.net>”