From: Sean Roach <roach_s@alph.swosu.edu>
Date: Thu, 30 Jan 1997 21:42:21 -0800 (PST)
To: cypherpunks@toad.com
Subject: Re: Workaround for filtering/cybersitter
Message-ID: <199701310542.VAA05173@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


At 03:43 PM 1/29/97 -0500, Mark Rogaski wrote:
>If I had experience with Netscape plugins and spare time, I'd
>try it myself.  But here's my proposed solution.  
>
>A plugin in Netscape intercepts all requests,  encrypt the URL
>with a pubkey algorithm, encode the string base64, send it as GET input to
>a proxy server.
>
>The proxy server decodes and decrypts the URL, gets the requested page,
>and returns it.  This beats out URL-based filtering.
>
>Still need to figure out the specifics of key-exchange.  If we use
>40-bit encryption, it's exportable, and it still works in our threat
>model (ie. we don't care if the watchers figure out the URL a few hours
>later).
>
>To beat out dropping packets with unacceptable pattern in them, we
>could use an SSL-based server as the proxy.
>
>The plugin could even have a nice little on/off switch and a list
>list of available proxies.
...
The above paragraph would be a problem, unless you wanted to update the
program with a great regualrity.  Each time the offending government got the
software and blocked all of those sites, the software would be worthless.
This would be no big deal if you could guarantee some means of someone
getting the software, which would certainly be illegal, again and again.
Better to have the user key in the proxy that h[is/er] cousin/uncle/best
friend/boss/client/guest told h[im/er] about.

Here is a similar idea.  Have your plug-in replace the part of Netscape that
checks the URL with INTERNIC or similar.  Have the system accept your
address for the proxy and send the requested URL to it, the server then
FTP's the contents of the page (and if server time is readily available, its
sub-pages), places them in a temporary directory on itself and allows your
computer to see it there thinking that it is on a totally different machine.
This way the proxy owner would not have to stay on top of the latest
restricted material.
The main problem would be that the system would absorb twice as much time,
once for the download to itself, and once to show it to you.
This is not terribly different to Netscape's caching of recently visited
pages in memory on the off-chance that you will return.
If you changed passwords at the same time that you changed addresses, and
reported them together, the government wouldn't be able to keep up.
When the government did its sweep of objectionable words, it would come to
this site that would have no such data.  Only by having the access password,
would they be able to reveal that site as a proxy.  If they knew the
password then they would already know that that was a proxy site because
they would have been given both the password and the address at the same time.
You then try to maintain several different addressess at a time, each with a
different password.  As the Government blocks one, change its password and
its address.
The software would be either two-piece, assuming a dedicated client plug-in,
or one-piece.
The pieces would be as follows.
The proxy, this software would be as small as possible and would only be a
front end.  Ideally this software should fit on one 3.5" disk.  The address
to this machine would be the address handed out.  In the one-part scenario,
this would be implemented as a web-page with a CGI script for the address.
The user types in the request and this bot fetches it, placing it in a
special directory for the use of this script, this directory would probably
be erased after the allotted space was filled, though not before, (you don't
stay logged in to the remote machine when using Netscape so erasing on
hang-up would mean continually reloading the data.)  The proxy would then
refresh your client with the requested information.  In the two piece
scenario, this proxy would interact with the plug-in in much the same way,
forgoing the CGI script.
The client, the plug-in, if present, would take over the Location field and
have a set up menu to type in the proxy's URL and password.  In that way the
user would see h[im/er]self as accessing the web page directly.  Certainly
more user friendly, once the client were configured, though not quite as
flexible.  In this system the government could make both accessing the proxy
and possession of the client illegal.  It would also be a problem for
persons who use a machine to which they have no control.  If the setup were
un changeable or reset after power-down, this system would require the user
to continually re set up the client.

The proxy could be as simple as an opening screen with a field for the
password and the URL.  The proxy should re-link all external links into its
own system so that the system can be transparent after the initial page.  In
other words, the links should be replaced with a second HTML document with
the password and search-criteria inside in much the same way that
search-engines relay your request to itself, in the URL.  This would be a
simple script that changed all occurances of "A
HREF="HTTP://This.is.the/real/site.html"" to "A
HREF="internal/directory.html
Query?=HTTP://This.is.the/real/site.html+password""