🚀 go-pugleaf

In article <pzvnw7+.abell@netcom.com> abell@netcom.com (Steven T. Abell) writes:
>[lots of stuff deleted about why encryption didn't make it into 3.0]
>
>I think it's time that the U.S. Government got real about encryption
>software. I have to laugh whenever I see shrinkwrapped software with
>a little sticker that says it can't be exported because it contain a
>DES function. Who do they think they're kidding?

Give an encription API to NeXTMail, and NeXT should ship without any
encryption module.  Let Canon in Japan or an European subsidiary develop
an encription module which then will be distributed to the world
free via net.  We just get it and pop it into our NeXTMail.

US doesn't allow export, but it seems that there is no restrictions on
importing.  This seems like the most effective approach to deal with
the laughable situation than fighting NSA on their turf.

The only thing NeXT has to do is to design/publish a good API for external
encryption modules.

Come to think of it, this is a good opportunity for non-US developers to
deliver a NeXTMail-compatible GUI mail program, but with DES or any other
public key encryption built-in.  They have a clear advantage over NeXT and
US developers.  Make a free demo version which can decrypt messages, but cannot
send out encrypted messages.

--
Izumi Ohzawa             [ $BBg_78^=;(J ]
USMail: University of California, 360 Minor Hall, Berkeley, CA 94720
Telephone: (510) 642-6440     Fax:  (510) 642-3323
Internet: izumi@pinoko.berkeley.edu (NeXT Mail OK)