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
At 03:43 PM 1/29/97 -0500, Mark Rogaski wrote: 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""