[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Eternity Services


Adam Back <[email protected]> writes:
> Tim May <[email protected]> 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 
though.  Would usenet simply ignore the additional, and potentially highly 
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 
motivation would the overt owners of the server have to upgrade to handle the 
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 
upon USENET rather than just using it as one of many potential transport 
is unable to scale.  Certainly the performance of your Eternity implementation 
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 
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 
- -- 
Ryan Lackey
[email protected]

Version: 2.6.2