[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The problem of playing politics with our constitutional rights



On 23 Sep 1997 09:58:20 -0500, Jonathan Wienke <[email protected]>
wrote:

>At 11:28 AM 9/22/97 GMT, [email protected] wrote:
>>remailers handle the increased load?  Are there enough remailers?
>>People will not tolerate more than a 24 hour delay for getting their
>>messages delivers.  What about spamming?  
>>
>>Another Question:  Since such a plugin uses (has the hooks for) encryption,
>>would it be covered by ITAR?  (i'm asking because I'm seriously considering
>>making the eudora plugin)
>
>The Eudora plugin should support remailer chaining and PGP encryption for
>personal messages, as well as give the user the opportunity to BE a
>remailing service.

Would people want to use eudora (their main email program) as a remailer,
and have to wait for it to process all those messages each time they read
their mail?  Is there a demand for users with dial-up accounts to be
remailers?

(I'm not being critical, I'm just asking.  I never thought about using
eudora as a remailer server)

>>Anyway, the remailer 'network' needs to be strengthened.  Right now,
>>Raph's pinging service (or whatever private idaho uses) is the only way
>>private idaho can tell which servers are up.  Attack this point, and
>>reliability when chaining remailers becomes uncertain.    Imagine a TLA
>>co-opting this service and altering the list to favor government friendly
>>remailers.
>>
>>It also needs to be easier to set up a remailer.  I'd like to see the
>>software distributed in .deb and .rpm packages for Linux.  Once set up, the
>>remailer could automatically announce itself to the world (perhaps via a
>>newsgroup post).  The various listing services would pick up on this.  The
>>more automated it is, the better.
>
>How about posting availability notices alt.remailer-availability.announce
>(create it if necessary) or alt.anonymous.messages?

Yes, I was thinking along these lines, though right now I'm concentrating
on the client end of things.

>
>>>I am sure that people can think of all sorts of other ideas for needed
>>>apps.  But to make them usable for the "general public", the apps will be
>>>needed to be written for Windows.  (As much as I hate to think about it...)
>>
>>Private idaho needs to be rewritten (in Java possibly) to be simpler to
>>operate.  There should be one button to press to send a message without
>>messing with what type and which remailers to use; the program could choose
>>these things randomly (ok, it's not the best thing to do, but at least it's
>>easy to use).  It also should be updated to use pgp 5.0 (not exclusively,
>>of course).  If possible, also add support for the Eternity Service.
>

>The remailer plugin should be able to:
>1. Scan all available sources of remailer availability / reliability.
>2. Allow the user to select a pool of trusted remailers.
>3. Allow the user to select the number of remailers in the chain.
>4. Randomly select remailers from the pool.
>5. Encrypt / add headers to the outgoing message to match the selected
>remailers.

Good Idea.  Are people comfortable with not choosing the exact order of the
remailers used?

>
>>Stenography Plugin for mail/news readers.  It's our one (and possibly only)
>>defense against GAK.  You can't decrypt what you can't see.  (watch for
>>Stenography to be classified as encryption and be similarly restricted.)
>

>Look for AOL and other ISP's to automatically run a "noise reduction"
>filter (as in CoolEdit 96) on .wav / .jpg files if GAK becomes mandatory.
>CoolEdit's noise reduction filter is great for removing tape hiss and other
>constant background noise from sound files, (it can make a cheap tape deck
>sound like a cheap CD player) but it would obviously destroy any stegoed
>data. The noise reduction algorithm is very processor intensive--it takes
>my 586/133 about an hour to NR a 3 minute stereo 44 KHz recording, but I'm
>sure you could set up a "light" version of the filter that would destroy
>stego data without taking as long.
>

And how does one tell the difference between a JPEG image and a executable
program after they're uuencoded (assuming one does not follow MIME
conventions)?  Will we be required by law to identify, in clear plaintext,
the nature and contents of all our messages?

One more  thing:  I can't seem to find any reference to an API for pgp 5.0.
Anyone have any pointers?