Proposal: PICS Defeater w/ Encryption

Pedersen writes "Here's an idea that I've been tossing around since the info on PICS came about, and I wanted to see some feedback about it. Basically, there is a way to get around PICS, using encryption, and some open source tools. First off, we have GPG now available to us for generation of public/private key pairs. Using GPG, we can set up key servers which are all tied together, which also have the capacity to sign keys (rather like VeriSign will sign keys, so can these). This would have to be a free service to encourage its use. In addition, the service would actually attempt to verify that submitted public keys belong to whom they say they do (ie: You can't create a key, and claim it's mine). You get the idea. The service has to find a way to get as many key servers as possible out there to hold signed public keys.

While this service is getting off the ground, these same keys need to be incorporated into a few other projects. These include S/WAN, Apache, Mozilla, ssh, and several MTAs/MUAs (sendmail, etc). This would allow for these various programs to automatically get public keys for individuals from the keyservers, encrypt the data to them, and send it down the wire to them with a nice innocuous rating. Quite probably, the easiest way to accomplish this is to develop a library which can check against GPG public keys.

Oh, and I'm sure many of you are asking why to get this done to the MTAs as well. A quick configuration option after this is incorporated would be to only allow connections from trusted hosts (ie: Their public key must have been signed by a trusted service). Combine this with a service which verifies the user's identity, and anonymous spam could become a thing of the past. Registered spam is still a problem, but that can at least be filtered out and reported very easily.

I've chosen the tools I mentioned because of the fact that, to the best of my knowledge, they are all true Open Source tools which can be used by us. Furthermore, if they're done right, the tools which interact with the user directly (ie: Mozilla, MUAs, etc), then these same tools can be ported to multiple platforms with a great deal of ease, allowing even Windows users, Mac users, and other OSes users to gain the same benefits.

I'm not sure if this is a feasible idea, though. Can such a project be undertaken in a short enough amount of time to short circuit any of the results of this conference in Munich? Is there enough interest in doing so?

I would suggest the following be done in this order, if so:

1. Get the code out of gpg and into a library which can be easily attached into any program, allowing members of other open source projects to begin planning for their code to use public keys and encrypted connections.
2. Get the code out of ssh to provide encrypted communications over a given socket, and put it into a library in the same fashion as the gpg library. As a side note, it may be desirable to put these two pieces of code into the same library.
3. Get code for key servers going which can accept gpg public keys (and their accompanying signatures), and also has the option of being restricted to accepting keys which have been signed by specific signing services.
4. While the above code is being ironed out, begin the process to set up the trusted services. This will include generation of keys, setting up ultra-secure computers to hold them (ie: Physically disconnected from the internet, etc), and decide what proof of ID will be required from users.

Well, that will about cover my thoughts on what should be done. If this is a desirable thing, then I am quite willing to be the organizer behind it all, though I will need help (for instance, sites which can host keyservers, library code, etc)."

I think Pedersen's idea is interesting, and I'd like to see what others think of it. There were several good suggestions for PICS-defeating systems in the comments on the two PICS articles - perhaps the authors can resurrect them here, and the community can decide what approaches have the best chance of success and are the most feasible to implement. -- michael

Comments

Easier solution (with anonymity)

[Gleef]

As earlier posters have indicated, the solution is both too complex and destroys anonymity. Here's another idea, it's very simple, and it improves anonymity.

Take Squid. Modify it to strip PICS information from any pages read through it. Run it on a decent box with a decent connection in a privacy friendly area. Better yet, have many people each run one or a few. Run some of them on alternate ports.

Anyone, using most existing software, can point their browser to one of these servers as a proxy. Free software can be modified to only bug the server when it gets a page blocked due to PICS restrictions. Some of these proxy servers might be set to only support the friendly browsers.

Your ISP won't see any PICS headers indicating naughty sites, so it won't filter anything from you. It's simple to implement, doesn't require authentication, works with most existing software, and actually improves anonymity, since the target site will see the HTTP requests come from the squid server, not from your machine.

----

Re:Easier solution (with anonymity)

[Gleef]

It is impossible to block all PICS-free data. Even if you can somehow figure out which webpages are missing PICS information, if the info goes over, say, the ftp port, there's absoultely no way of knowing to block the data.

As for the sites, the more sites that are out there, the harder it would be to block them all. Most ISP's wouldn't care enough to bother, they'll be doing the absolute minimum required to stay within the law.

----