RE: PGP and offline-readers
I am getting involved in networking some local BBS' and message bases.
I'm beta testing a privacy-oriented BBS right now that I just finished programming, called CryptoBBS and what better place to introduce/ask questions on it than among the cypherpunks! It is geared towards the hobbyist sysop with an old XT clone or something lying around as it is a mere 80K (for the floppy-sysops!) There is no logon prompt asking for name, birthdate, SSAN, and who knows what else, it goes directly onto the board. Callers wishing to post messages, are asked for an alias name to fill in the FROM: block, but real names or call-back verifiers are not supported. My hope is to offer sysop's a choice, between *choosing* to preserve privacy, rather than the current practice of obtaining personal information because the questionnaire's are preprogrammed that way. The unique feature about CryptoBBS is it's "Post Office." The P.O. allows callers to set up a p.o. box from which they can up/download any file (pgp encrypted files for instance) to any other user on the board without the sysop's approval/knowledge. It encourages and nurtures an anonymous "mail drop" community while protecting the caller's privacy. The question is, should I throw away the virtues of a lean 'n mean app at 80K by adding a dolphin or pgp to it that automatically encrypts the message base, uploaded messages, etc? Should we give the BBS caller a little credit and assume he knows to encrypt at his own machine before uploading the text? Or is the temptation to make everyone *lick and seal their message envelopes* too invasive? I know the issue of encouraging pgp use by making it as painless as possible on the end-user is nothing new around here, but as far as I know no one has ever discussed whether or not BBS's should handle the job for the caller.
According to James Still:
I am getting involved in networking some local BBS' and message bases.
The unique feature about CryptoBBS is it's "Post Office." The P.O. allows callers to set up a p.o. box from which they can up/download any file (pgp encrypted files for instance) to any other user on the board without the sysop's approval/knowledge. It encourages and nurtures an anonymous "mail drop" community while protecting the caller's privacy.
Be carefull! Remember that you may be held accountable for ANYTHING found on your BBS. If someone uses your board to trade credit card numbers..... See ya!
The question is, should I throw away the virtues of a lean 'n mean app at 80K by adding a dolphin or pgp to it that automatically encrypts the message base, uploaded messages, etc? Should we give the BBS caller a little credit and assume he knows to encrypt at his own machine before uploading the text? Or is the temptation to make everyone *lick and seal their message envelopes* too invasive?
Typically, you want to assume that user knows NOTHING! You design your user- interface accordingly..... I know it sounds insulting but if this attitude makes your stuff easier to use....what do you care? +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl@triton.unm.edu | But, I was mistaken. |available| | mike.diehl@fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" <Me> | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+
I think a good idea for offline readers would be to build ontop of currently implemented protocols. One protocol worth mentioning is IMAP2. Right now IMAP2 usually runs over TCP but there is no reason why it couldn't run over a serial channel instead (SIMAP :) It allows for remote access to mailboxes from a mail server, and also remote access to builitin-board messages (ie. USENET). There are several packages in development or already in use that use IMAP. PINE for unix's and soon to be available for DOS machines supports IMAP access. PINE also supports MIME and could be extended nicely to handle automatic PGP encryption/decryption of mail (or en/de- cryption with other crypto-systems). Macintosh already has a mailer supporting IMAP, the name eludes me at the moment. The mailers in existence are written for TCP and would have to be modified for use over the serial line, perhaps with a pseudo-packet driver in the dos case. I think this type of solution would be much cheaper and much more feature filled than starting from scratch. Tim N.
According to Timothy Newsham:
I think a good idea for offline readers would be to build ontop of currently implemented protocols. One protocol worth mentioning is
This is fine if you are using a *nix machine. But if you are trying to enforce your privacy over CI$ or genie or a bbs, well, you can't rely on one common protocol. This is why I advocate communications program scripts. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl@triton.unm.edu | But, I was mistaken. |available| | mike.diehl@fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" <Me> | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+
According to Timothy Newsham:
I think a good idea for offline readers would be to build ontop of currently implemented protocols. One protocol worth mentioning is
This is fine if you are using a *nix machine. But if you are trying to enforce your privacy over CI$ or genie or a bbs, well, you can't rely on one common protocol. This is why I advocate communications program scripts.
We need to get people to use common protocols! CI$ will respond to what its users want. If we got alot of BBS's to use IMAP then the users would want CI$ to use the same. If we made IMAP easy to use and helped BBS authors get IMAP code running in their systems then BBS users would use it PINE is very easy to use. It will be available soon for personal computers to use. That part of the solution is almost there. How do we get BBS's to use IMAP? they could support IMAP in a similar way that they support Zmodem. What needs to be done is to write some code that does IMAPD functions that could easily be incorporated into a BBS program, and figure out a way for end users to run PINE from their favorite bbs program. (and get PINE people to allow for a serial-line connection *or* write a false-packet driver that just strips off TCP/IP headers sends the data over the line and sends back ACK's to the TCP/IP process). Tim
PINE is very easy to use. It will be available soon for personal computers to use. That part of the solution is almost there.
That part of the solution is already done. There are already several very good POP/IMAP clients for Macs and PCs (Eudora, NuPOP, etc). Why the fixation on a particular mail agent? There is no way that you are going to get people to agree on a single MUA, therefore it seems that the comm channel is the beastie that one should focus on for encryption.
How do we get BBS's to use IMAP? they could support IMAP in a similar way that they support Zmodem. What needs to be done is to write some code that does IMAPD functions that could easily be incorporated into a BBS program, and figure out a way for end users to run PINE from their favorite bbs program.
I hate to break it to you, but there already exists a protocol for off-line reading of mail and news over serial connections: QWK. While a noble effort, I sincerely doubt that the BBSers and CI$ users are going to jump over to a completely new protocol for transport of information for off-line reading unless it offers them something that they do not already have, and IMAP/POP just doesn't do that. If one were to be able to offer encrypted TCP/IP connectivity though, then you would be offering people the additional functionality of this comm channel (telnet, ftp, gopher/www, etc) to entice them to switch over.
(and get PINE people to allow for a serial-line connection *or* write a false-packet driver that just strips off TCP/IP headers sends the data over the line and sends back ACK's to the TCP/IP process).
Why not just get them to support IP? Probably easier... All they need is a slip/ppp driver on the host, then you can do the encryption over comm channel and avoid wasting time encrypting something that doesn't need to be encrypted. Many BBS systems are beginning to wade through the shallow water of the Internet, if we had the ability to offer them modifications to provide encryption to thier IP connectivity while they are still new to the game it would be much easier to get them accostomed to the idea that such traffic should offer encryption; not that I think this will happen, but in an ideal world... jim
PINE is very easy to use. It will be available soon for personal computers to use. That part of the solution is almost there.
That part of the solution is already done. There are already several very good POP/IMAP clients for Macs and PCs (Eudora, NuPOP, etc). Why the fixation on a particular mail agent? There is no way that you are going to get people to agree on a single MUA, therefore it seems that the comm channel is the beastie that one should focus on for encryption.
No fixation. Just that IMAP is the best protocol for remote mail reading and pine is already available and supporting IMAP. And as a bonus it supports MIME. This *is* something that BBS'ers dont already have.. multi-media mail.
I hate to break it to you, but there already exists a protocol for off-line reading of mail and news over serial connections: QWK. While a noble effort, I sincerely doubt that the BBSers and CI$ users are going to jump over to a completely new protocol for transport of information for off-line reading unless it offers them something that they do not already have, and IMAP/POP just doesn't do that. If one were to be able to offer encrypted TCP/IP connectivity though, then you would be offering people the additional functionality of this comm channel (telnet, ftp, gopher/www, etc) to entice them to switch over.
You dont need encrypted TCP/IP! A good mail reader supporting MIME could handle encryption packages automatically! MIME also supports many other things that "they do not already have".
(and get PINE people to allow for a serial-line connection *or* write a false-packet driver that just strips off TCP/IP headers sends the data over the line and sends back ACK's to the TCP/IP process).
Why not just get them to support IP? Probably easier... All they need is a slip/ppp driver on the host, then you can do the encryption over comm channel and avoid wasting time encrypting something that doesn't need to be encrypted. Many BBS systems are beginning to wade through the shallow water of the Internet, if we had the ability to offer them modifications to provide encryption to thier IP connectivity while they are still new to the game it would be much easier to get them accostomed to the idea that such traffic should offer encryption; not that I think this will happen, but in an ideal world...
I dont think its easier. I think something like SLIMAP (serial line imap) would be the easist thing to implement. IMAP runs over a network stream and there is no reason it couldnt run over a serial line stream. The code written for imapd already runs on stdin/stdout... It wouldnt be hard to port to run on a serial line connection.
jim
I dont think offering IP to the masses is the right solution right now. Its not appropriate for the BBS world. Getting people to use remote mail clients is something that the masses could take to alot easier. I think this would be the prefered way to read mail since the user interface could be made more friendly, sorta the 'prodigy thang'. I dont think it matters what protocol is used in the end but I think its something that should happen, and something that we as cypherpunks have an interest in seeing happen.
participants (4)
-
J. Michael Diehl -
James Still -
Jim McCoy -
Timothy Newsham