From: Eugene Leitl (eugene.leitl@lrz.uni-muenchen.de)
Date: Thu Mar 02 2000 - 20:19:06 MST
Lee Daniel Crocker writes:
> We've already discussed ways to prevent namespace pollution and
> usurpation, but implementing those will have to wait for version 2.
You're part of the effort? Cool. Wonder why you never plugged the
project here. It's certainly worth it. (People please don't try to put
it on /., because it's recently already made memepool despite being
early beta. Please please don't try to rush things at this stage).
> Specifically, if you store data keyed on content hash, and store
> "names" as cryptographically signed references to content-hash-keyed
> data, you can have any number of namespaces, each secure and reliable,
> which users can choose among.
Providing unconstrained number of namespaces is great, but it invites
namespace inflation. Figaro.here, figaro.there,
figaro.friggin.everywhere. (Sounds familiar, huh?). Then things
become hard to find, unless you can do global name searches, which
makes you once again susceptible to the attack via namespace
clobbering. If lock on names persists as long as there are references
to it (how to prevent graph loops? or do only actual document accesses
count as reference? they have to be. references can be fabricated by
robots, however, which you can't tell apart from humans), then you can
fill up the sensible stringspace with garbage, and keep them locked by
running a lot of robots. Ugh.
Of course user communities can rendezvous at secret points in
namespace. Which is only good as it stays a secret.
One needs anonymous cryptographic authentication, and some
infrastructure allowing content ranking, which can't be defeated by
distributed robots generating thousands of hits. Robots cannot build
reputation, and if they can, they should enjoy the same rights,
anyway.
Building communities, with quantitative trust metrics. Good thing you
can't trace a virtual reputation to a warm body, somewhere...
If there is a means of revoking content, a trusted person could fill
up a local namespace with lightweight dummies, which can get
substituted by real content when contacted by the author. But this
means you have to use nym remailers, which exposes you to spam. And
even dummies take up resources, if there are a lot of them. Hmm.
The whole thing is obviously impossible to be made waterproof. As long
as it keeps the most glaring holes patched, and is usable, however...
This archive was generated by hypermail 2.1.5 : Fri Nov 01 2002 - 15:27:09 MST