From: Ian BROWN (I.Brown@cs.ucl.ac.uk)
Date: Mon Feb 28 2000 - 07:15:43 PST
>It seems however, that Napster suffers from a few design flaws:
>centralism (there is a central database, right?)
Unfortunately, yes. Each client logs on to a server, hands over a list of the
files it currently is sharing, then uses the server for searches. This seems
bad even for Napster Inc., who seem to be reducing one legal defense they
could have against copyright infringement lawsuits ("we don't distribute the
files, just the software used to access them...")
Even worse, the server then returns the IP addresses of clients where a
searched-for file can be retrieved. That really exposes Napster users! This
would be fixed if clients ran something like Freedom, but I don't think that
currently allow anonymous server addresses, so the Napster server couldn't
point a client to another anonymised IP address.
>An obvious problem is how to avoid collision with vanilla https
>(other than intercepting/redirecting https://aaa.bbb.ccc.ddd/napster/
>traffic. Perhaps just using https on a different port would be a
>smarter idea, though usage of a nonstandard port is bound to draw
>closer scrutiny).
It would be nice if Napster flows could be made completely indistinguishable
from standard https connections, including port numbers. You could always just
use vanilla https to transfer files between clients. The Napster protocol
includes lots of other functionality like chatrooms that isn't needed for this
application.
Alternatively, you could just mandate that tunnel-mode IPSEC or Freedom's
Anonymous IP be used on flows between clients.
>It would seem to be necessary to limit the scope of visibility to
>direct neighbours only, to prevent malicious users from obtaining
>extensive lists of other Napster users' addresses. To increase
>obfuscation, introducing some traffic mixing should be contemplated,
>injecting pseudorandom garbage traffic between direct neighbours to
>foil statistical traffic attacks.
The consensus on the eternity@internexus.net Majordomo list (set up to discuss
this kind of anonymous publishing) was that publishing on its own is a
difficult task without needing to handle anonymising clients as well. As we
already have tools to perform the second function, it would be nice to
leverage them here.
There's a link farm of projects of this type at http://www.cypherspace.org/
Ian :)
This archive was generated by hypermail 2b29 : Mon Feb 28 2000 - 07:18:48 PST