[118039] in Cypherpunks
RE: Zipping to BlackNet
daemon@ATHENA.MIT.EDU (Sean Roach)
Sat Sep 18 00:50:26 1999
Message-Id: <3.0.6.32.19990917233043.0084b620@mail.intplsrv.net>
Date: Fri, 17 Sep 1999 23:30:43 -0500
To: cypherpunks@algebra.com
From: Sean Roach <roach_s@mail.intplsrv.net>
In-Reply-To: <NDBBIFGOKODBCKDGJDKLAEHBCGAA.shamrock@cypherpunks.to>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: Sean Roach <roach_s@mail.intplsrv.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've been in Colorado visiting my grandmother and had no access to my
account for a few days. Since this is fairly old, there stands a
chance that it has been discussed to death and that I may be covering
old territory, but I wanted to get my two cents in.
At 03:57 PM 9/12/99 -0700, Lucky Green wrote: >
>
>Anon wrote (re: ZipLip) >>
>> Is this download also SSL protected?
>
>Yes.
>
>> Does ZipLip claim to be anonymous?
>
>No. Which actually made me somewhat respect the guy giving the talk.
>The system by itself provides no security enhancements for
>Cypherpunks-type thread models, but at least the company rep didn't
>claim it did either. Which in itself put him ahead of the vast
>majority of the rest. <Yes, I am being sarcastic>.
>
>> > Combining ZipLip (or other services like it) and Freedom, we now
>> > have anonymous high-bandwidth content distribution. A highly
>> > useful BlackNet enabler.
>>
>> It seem that you are really just using ZipLip as a content server.
>
>Well, of course. A content server that as far as I am concerned is
>welcome to take the heat for the many gigs of warez and other
>goodies that will be distributed from it in short order. Works for
>me. [Before somebody replies "but that can't last". Well, of course
>it can't. But who cares. There are/will be other services like it.
>One could define an API for a shim that interfaces with all the free
>content servers out there. Then all you need to do is add/subtract
>modules as content servers go up and down. I can't see those modules
>being more than one page of perl per server. Replicate the data
>across more than one server at a time and chances are the data will
>remain available to your target audience for a long time. Untracable
>to you and at zero cost to you.
>
>Back in the early days of Cypherpunks, there was a discussion
>regarding soft nodes and hard nodes. Most people at the time
>envisioned the soft nodes to be some cheap boxes that are installed
>without the network administrator's knowledge in a wiring closet or
>the ceiling. If the box gets impounded, there would be no big
>financial loss. But hey, Internet has reached a point where free
>services allow us to use their hardware and fat pipes as soft nodes.
>At zero cost to us. A good thing, IMHO. Well, for us at least...
>
>> What advantages does this have over the many free content servers
>> available on the net today?
>
>As of this very hour, the ZipLip guys offer unlimited https
>accessible drive space to any user. Somebody probably should forward
>this fact to the warez/mp3 lists... Might as well make use of it
>while it lasts.
>
The thing is, with any anonymous upload capability, you can take
advantage of a free web server until their security guys find out its
against policy and take it down. The disadvantage here, with
something on the model of Freedom server, unless I missed something,
is that you will probably only get one or two such shots per server
per nym before they wise up and start blocking habitual abusers by
name. As far as a dirty way to provide a server, why not use
Freedom, tied to an IRC bot. Have the bot whisper the list of files
available for download, and the commands used to do it, when someone
logs in. Have it also do a trace early on to see if the users site
can be found, tell h[im/er] where the bot determines h[im/er] to be
so that that person can refrain from relying on the "anonymity" of
IRC to protect h[is/er] identity. Have the bot download files by DCC
when requested to do so.
In this way, you would have an anonymous content provider. The
provider being anonymous, not the requester. The server "hosting"
the bot would be blameless as it had no idea that this was being done
and would be fully in its power to ban the bot when it was
discovered. The upshot to this is there appear to be a lot more
servers tied into the big three IRC nets then there are readily
visible free web page servers. The customer does not have to hunt
down the new location each time it gets booted because it will
usually just come back to the same channel, having only been booted
by that one server. If it does become common for the channel to be
blocked, or for the channels admins to ban the bot, the bot can be
given a pattern generator component which will randomly create a new
channel when the old one becomes unavailable. This would only
require the clued in to look for the new channel within certain
constraints which may be broad or narrow. If they are too narrow,
the admins may be able to block all potential channels. Alternately,
the channel can be entirely random. The bot can generate a random,
but seemingly human-like nickname from a list of commonly used name
elements, pop onto certain channels, advertize it's new location and
pop out. To avoid the users getting mad at this obvious
advertisement, it should be limited to germane channels which are
pre-selected and with the approval of the regulars. For instance
@warez, or @hack3r for a server distributing the latest
packet-sniffer. Or, in an echo of Lucky Greens example,
@salmon-rushdie, @hotislambabes, or @veiless-beauties.
Again, the anonmity would be for the PROVIDER. The customer would
still have to take measures to hide h[is/er] own identity. Perhaps
using Freedom server h[im/er]self.
Although, in application, this sounds much like usenet. Provisions
possible for anonymous upload, a remailer and a mail2news gateway,
semi-anonymous download, relying on the ISP not to look too closely
at the logs.
Sean Roach
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>
iQA/AwUBN+MVc5HDoiHtqFDZEQJztACcCxmbiNPhertkhblLNorEnM5sWh4AoO9S
fDB/2qBjvfCMvNANEwsTcPkv
=v/4C
-----END PGP SIGNATURE-----
