Hmm... Well, having a program that will auto install segments only if they are signed by trusted public keys is a good one... but then again, most of the non-techies just want to have a program that works and that they're happy with. Many people would rather just keep a stable, working, but older version instead of going to the trouble of trying to always have the latest.
That's actually another reason such a system could be valuable. If multiple signatures could be attached to a particular version of a program, different versions of a program could be distributed simultaneously, each at a different "stability level". New versions would start with only the signature of the author, indicating that the author "thinks it works." Then as the alpha testers test the version, they sign it if they consider it stable. If "enough" signatures are attached to a particular alpha test version, it becomes a beta version and released to the much broaded beta test audience, who then similarly sign it only if they think it's stable, and finally it might become a release version. A particular user might configure the downloading/installation system to accept new versions of the software only after a certain number of signatures are attached to it. In addition, the user would probably specify some number of specific signatures that must be present - the author's, presumably, possibly other well-known beta testers, the maintainer of the primary FTP site it's being distributed from, etc. Essentially, the "specific signatures" check would be for security, while the "number of signatures" check would be only to keep track of the stability of the software. On the author's (distributor's) side, there might have to be some additional security provisions to ensure, as much as possible, a "one tester, one signature" rule, so tons of bogus signatures don't get accepted and added to the main distribution. But only the author/distributor should need to worry about this; normal users/ receivers of the software shouldn't need to be concerned.
I would be wary of an auto-update system because of possible bugs in the software. Even if you only allowed updates from completely trusted public keys, even the best of us make mistakes and screw something up...
The same goes for PGP, anonymous mailers, etc. Any software system like this can only command trust as more and more people scrutinize it and test it and decide it's OK for them.
Perhaps we just need something that would make using encryption easier. Tell me what you all think of this as a project for cypherpunks:
Does anyone want to develop an encrypted term program? On-the-fly encryption over a modem.
This is another good application, but I think it suffers from the same problem as encrypted E-mail messages: as long as it's even a little less convenient than no encryption, most people just won't care enough to use it. The motivation for my suggestion was not so much to present a neat new idea (in fact, I'm sure the idea is not new at all), as to present a _strategy_ for achieving other social and political goals. The strategy I'm proposing is to find a way to make encryption an _enabling_technology_, not just a mostly-unnecessary inconvenience in the eyes of ordinary people. However, with that in consideration, don't let me discourage you from doing some kind of encrypted terminal program. In fact, one common denominator between it and any automated downloading/installation system would be the necessity of interfacing with existing encryption systems, probably more than one. A useful sub-project, whatever the bigger project(s) turn out to be, might be an easy-to-use, standardized "encryption interface library" that could be used in other programs to interface with other encyrption programs and modules. Bryan