December 2003 - cypherpunks-legacy

Re: Can't block caller ID in Massachusetts?
by jim bell 17 Dec '03

17 Dec '03

At 10:25 PM 7/13/96 -0500, Roger Williams wrote: >Certainly, though, if I was calling the BATF toll-free to rat on my >neighbourhood Uzi dealer, I'd never call from my own phone, anonymous >re-phoner or not. A question to ponder: If (anonymous) pay telephones didn't already exist, would they be allowed today? Jim Bell jimbell(a)pacifier.com

1 0

Re: Crypto-activism
by Arun Mehta 17 Dec '03

17 Dec '03

At 00:43 13/07/96 +0000, Deranged Mutant wrote: >My point is that a lot of people in those countries are aware of PGP >etc. than make it out to be. Certainly many activists are. They >focus on the human rights issues at hand, to which PGP etc. may be a >tool... but isn't the central focus. I agree. But many such people, who need PGP but don't want to make it their central focus, have a hard time acquiring the necessary skills. When even people on this list, for whom by and large crypto is the central focus, complain about how cumbersome PGP is to use in practice, what about everyone else? > >It would be condescending to email to many people in a domain saying >"hey, have you heard of PGP?..." Chances are they'll think it's a >strange commercial spam anyway. You are right, and it wasn't my suggestion to ask in this way. What one could do is: 1) Prepare a writeup in simple English, on exactly how to use the appropriate software. 2) Try to get it translated into Chinese, Korean, and whatever other language we can find volunteers or sponsorship for. 3) Post on appropriate newsgroups that such translations exist, with urls. 4) Suggest that since people living under authoritarian regimes may not have access to the appropriate Usenet newsgroups, to please spread the word. No need to suggest that any particular country is being targetted, in fact enough people living in the US and using the office computer for communications would benefit. >> the question is, are >> *you* in a position to share your knowledge? > >Yep. But there's a proper way to share knowledge. Would you agree that steps 1-4 above would constitute the proper way? In that case, would you help prepare such a document (any other volunteers equally welcome)? >You also have to know what you're talking about: if you're not familiar >with the nitty -gritty of politics in such countries, you'll come off as the >"cypherpunk bearing gifts of crypto for the natives"... the politics >going on in places like Cuba, China, Iraq, Russia are a bit more >complex than what comes off through the media (to some extent no >matter where you are and what media you watch). Undoubtedly. But I see no problem in cypherpunks bearing gifts of crypto to people who are fighting difficult battles for human rights -- ultimately for all of us. If anyone is bearing gifts here, it is them. On the Internet, everyone does what s/he is good at, and cypherpunks just happen to be good at crypto. > >For example... there are many anti-Castro 'democratic' socialists in Cuba. >If you approach them as if they were anti-Communists you'll be seen >as a clueless kook. Some Chinese I have spoken to are suspicious of >the Tiennamen Sq. activists, claiming they were more 'reformists' >than true democratizers who were unknown before Tiennamen. Clearly, in our document we will take no political positions whatsoever. We merely point out that if you wish to communicate securely such that only the recipient(s) can decipher, this is how you go about it. They'll know how to use it, this is a problem they face daily, with phone tappings, bugs, etc. a routine. > >One more important issue: people have to trust you. You can't go >into a strange environment and expect trust if you come off as a >tourist. You are selling yourself short. People who have (successfully?) fought the US government are likely to get a trust bonus among activists anywhere they go ;-) You asked about me, I've put up a little information on http://www.cerfnet.com/~amehta/ I'd be happy to fill in the blanks. Arun Mehta Phone +91-11-6841172, 6849103 amehta(a)cpsr.org http://www.cerfnet.com/~amehta/ The protestors of Tiananmen Square will be back. Next time, the battle will be fought in cyberspace, where the students have the more powerful tanks...

1 0

Chicago Physcial Meet?
by snow 17 Dec '03

17 Dec '03

I was exchanging email with another member of the list late last week, and they brought up the possibility of a physcial meet for the greater Chicago Area Cyhperpunks. Would there be interest in such an event? Petro, Christopher C. petro(a)suba.com <prefered for any non-list stuff> snow(a)crash.suba.com

1 0

Re: Crypto-activism
by Deranged Mutant 17 Dec '03

17 Dec '03

BTW, Sent this message to you the other day. It was bounced back... ----- Unsent message follows ----- Received: from unix.asb.com by giasdl01.vsnl.net.in; (5.65v3.2/1.1.8.2/23Apr96-0134AM) id AA09399; Sat, 13 Jul 1996 10:32:46 +0500 Received: from magneto (sls17.asb.com [165.254.128.27]) by unix.asb.com (8.6.12/8.6.9) with SMTP id BAA16194 for <amehta(a)giasdl01.vsnl.net.in>; Sat, 13 Jul 1996 01:20:32 -0400 Message-Id: <199607130520.BAA16194(a)unix.asb.com> Comments: Authenticated sender is <wlkngowl(a)unix.asb.com> From: "Deranged Mutant" <WlkngOwl(a)unix.asb.com> Organization: What organization? To: Arun Mehta <amehta(a)giasdl01.vsnl.net.in> Date: Sat, 13 Jul 1996 01:03:41 +0000 Subject: PGP Key Priority: normal X-Mailer: Pegasus Mail for Win32 (v2.32a) Arun, No offense is meant at my posts, BTW. Just that I've seen seen some crazy schemes by activists who ignored the subtlety of some issues and do more harm than good. (Old pat phrase about road to hell being paved with good intentions...). Particularly with activists from "out-of-town" who claim to know what's better for the locals. Took a look at your home page,BTW. No public key on it, checked the servers. Also saw you graduated from SUNY in '76. Which school? (I've got a BA from SUNY Stony Brook recently, though not in comp-sci...) Peace, Rob -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQENAzF7Ci0AAAEH/2FiCb1r6C7QxMuExNo695h2qhiqkuS2EHrGyQ4gh+K1/4ha fXbXkHzeC0ifQSCTHPEknG/vCZP3ihkxTlwNaHE3GsSgu3e0o4uDDrz8mFWTEcTW mwjVGcDA2y0XBEc3Veh3hpVSTaKgYA12EcpQMzEAaICD/v8iezeDIRvAY8Jah/Wj 4dn1VF3RTYOm7ypTMLWDJQU2/cMk+TralJkMrSIhCE0GPU0JRAfjH/J2bl+5vxjF cC1JMSsY+LfgB8et3rSktdZzuudq08XQkPO79BL6U1ZqYjKwXWFKRNwP5XARDc+f 2pKBaCu0MN8kBoXOSvk4vJQpU6ATBM2VLF0/LpkABRG0JHdsa25nb3dsQHVuaXgu YXNiLmNvbSAocm9vdEBtYWduZXRvKYkAlQMFEDF7I67bHFCnqx9IMQEBJ3IEAJjp jcO91LnEGpQBWSR5liEHiAtkMH1kEVTOHFQsDQYF1Hb+ZIdbioIS6h4Il4NuHRZ5 ThtfCBs/jdNi2dtzVP6Isd1AsSSuRcyejeZblp1Ope71yrhV6uR7izHUGTK0GgHm xprq/E078oZdVB/73RNLM1qZdKW//4FoRLIZMOUBiQEVAwUQMXsSEwTNlSxdPy6Z AQEmrwf9FHSkUB+sTOIJhiLHfoJTETmEhKqFAjTs+4gRCCNiNSarLRyxF6lLRZDq lii02exIEgqzsiTlAta9nJ/ivnrtzcvhGxfXoOnbluuXa55HrosCXGjPt/XhZw++ p3iHKIox26M1cfe4WxAfD0HByvEn/uvNByTAh8aAqGqDxkDppZ6BnhMBlwXyAPaS bxGXzohOnKbg4oRTgO0932DUWU0uGX05Ab4jE+ZIGPT/w3cirHIRI+8vuNNrvuzE fG2RuI4Ns3hy0X9ZgP7hF+pRCWCQP/ak/HL38qegU90OlPFN8sdzS+qIaJROcT91 oMmPkUMgxdNcwhmqMqH2cQIj8pJhEJkAjQIr7lFeAAABBAC6rQ3ND8whLABFsDGN wYlIy9T4mqykqRT23hT1QIS9p+dSP8Zg3m8F5W4WsFfPBUqI0MsPGinYFzefq83V dEruPtFbnqKcbu1bjMAtjuFF6LSdEdOUlUdHE6YWOCZpcK6OmSrZKfrzlnmjaQ88 njTyqTwUsZAFfA3bHFCnqx9IMQAFEbQnRGVyYW5nZWQgTXV0YW50IDx3bGtuZ293 bEB1bml4LmFzYi5jb20+iQCVAwUQMMpQXdscUKerH0gxAQFNvAQAme7BCMGVUQCW CrdbnttRfZwSj6ryvhkIVYMcht2wtlpbEF/y2PxAbewWIBcPUCvJeyq1pViDcsbl 6gFLqKkaNA9okk0bAW0xZ5/qGIHmkkLkSnwOysdIExsrJykpKT/9Nrd11VKbrMXX tyMBDZR2c7GpyCVaud9XMS+Auuzb8vC0K1JvYmVydCBXYWxraW5nLU93bCA8cnJv dGhlbmJAaWMuc3VueXNiLmVkdT6JARUDBRAu/eFMbr6/n5nWRf0BAe1+B/9AePkd mJJVqb2XlX6uDC1/kGrSlRJlZp6Xy5NmKMcZG4KBI48MwWbGqxkr4iYTv0ep9+PV Jcd0mDuGTke3HSBffmpVEWHi/oBc1BpPBAVJPP8EX147yQXfn2SiyWQunDVZeFRy Ss1GLxgPR0JjaysmwoNcPL1RS3hpgPY81G+f+A35/q9vwC4i8+CnF4z0Rda3CUbg u1O9RngkbOAM6sJzEDJDJIonjEuKRtjOQShayR8sZbqVn09cOqXFRJ8T+1XLetW9 gtmKQNg4nQpm6xorqal7uZiHlksaKh1BweXm/iTwpNw2s0H53SbE6mX5IJo1r8/e +lUYvX/ygC/suAx1tDFOb3RlOiA8cnJvdGhlbmJAaWMuc3VueXNiLmVkdT4gZXhw aXJlcyBBdWd1c3QgJzk2iQCVAwUQMcT5OtscUKerH0gxAQFYZgQAo6LLlDLSuBF6 TlQjSH3yVuEh5hv8BZ0Jc6EcLlnC8brZD9k+sH0y0NknPcIVTzl5j3V+WCS0M2Pz bE4uZDEi7arfK3plhsU2JtGM9thl1LyaTvUyVR1ycvskJh3AMHvG+EhhfgLyngtE JLpKdFJSOoKPDRGTYyZ3jmtpN7p2vP60JlAuTy5Cb3ggMTMyNyBTdG9ueSBCcm9v aywgTlkgMTE3OTAgVVNB =aX7r -----END PGP PUBLIC KEY BLOCK----- --- No-frills sig. Befriend my mail filter by sending a message with the subject "send help" Key-ID: 5D3F2E99 1996/04/22 wlkngowl(a)unix.asb.com (root@magneto) AB1F4831 1993/05/10 Deranged Mutant <wlkngowl(a)unix.asb.com> Send a message with the subject "send pgp-key" for a copy of my key.

1 0

Stuffs used for detection
by Jerome Tan 17 Dec '03

17 Dec '03

In our school library, there is a depository area wherein you deposit your things and get the tag. Since the library doesn't allow those tags to be brought out from the library, everytime you brought it out and pass by the door, it will alarm. Does anyone know what stuff is that? How come it is alarmed? I brought some metals but it wouldn't alarm... Why those tag would alarm them???

1 0

Cybank breaks new ground; rejects public-key encryption
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text Sender: e$(a)thumper.vmeng.com Reply-To: Ian Grigg <iang(a)systemics.com> MIME-Version: 1.0 Precedence: Bulk Date: Sat, 13 Jul 1996 22:55:43 +0200 From: Ian Grigg <iang(a)systemics.com> To: Multiple recipients of <e$(a)thumper.vmeng.com> Subject: Cybank breaks new ground; rejects public-key encryption This taken from their pages (http://www.cybank.net/cb-encr.htm) --------------------------------- Security and Encryption Cybank software is protected by multiple encryption and identification systems, some can be seen, others are invisible. Cybank cash can be traced back to the original account it belongs to. Cash Keys cannot effectively be modified with disabling them. Because cash keys are also password protected, they can only be created and spent by the authorised account holder. Cybank uses an encryption matrix of 380 characters. Cybank can safely transfer any Cash Key or message from point A to point B via the Internet. Cybank DOES NOT use Public Key Encryption (which has proven to be insecure). Here is a sample encrypted code, see if you can understand it: 193404158201838932119642777371870823541340764 [...] ------------------------------- I wonder if they intend to publish the protocols :-) -- iang iang(a)systemics.com --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "'Bart Bucks' are not legal tender." -- Punishment, 100 times on a chalkboard, for Bart Simpson The e$ Home Page: http://www.vmeng.com/rah/

3 2

Re: Execution of signed scripts received by e-mail
by Matt Carpenter 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Steffen Zahn <zahn(a)berlin.snafu.de> writes: > Matt> Get one input line at a time, and look for Reply-To: and > att> From: headers to get a reply address. As we are slurping up > Matt> lines, watch for '-----BEGIN PGP' lines. If it is for > >I suggest ignoring Reply-To: etc and requiring a return address inside >the signed region of the mail, otherwise someone could intercept the mail >(suppressing the original) and resend it from his account and the results >would get sent to the interceptor. This is a very good suggestion. I'll change emscrypt to use this. > Another idea would be to extract the return address from the PGP userid >which signed the script. I see that Mark M. has already commented on this, but I'll also add that I didn't want to limit the reply to the address attached to the key. For example, I have several accounts spread around, and I might want the replies to go to anyone of them. >Regards > Steffen Thanks for the input. - --Matt - -- mcarpent(a)mailhost.tcs.tulane.edu -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMejLASjtJAMyBnp9AQEWyAf+IgmEApjh7CGo+sdCueH9BPQKLb9Dk7Qj 1HK7HoR8Dz/TnDPLicJgiaYj9z8gDfGLYWu2L4UIDIgQukb3o1JWOshTQAgyoCe9 gYxTYHvroNqMvq3ptPeeY73NVGsyTZnlcYJ/dlhWT90jReCZmIcrbpJNt+TIgGcm /s57Nw2zJzM8RrIWsCqs7gM0qogR2e71Gn4M+UFz9BfmMEw4X8qwZcD5M1//9VSi TqDjWnVucuUoWVZk+Bb6lKcxPwlAx6BxUZLaNaZrPlqvrSYJS4l451vgWkpcixSy Uuj+LU0cPd6qA3CHRHF4nllf3JcMP3uJeeWbmFjOZ+ItKkyQTSIVwQ== =JIXQ -----END PGP SIGNATURE-----

1 0

Execution of signed scripts received by e-mail
by Matt Carpenter 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This is a rough description of a perl script I'm working on to allow the automated execution of PGP signed scripts received by e-mail. I call it emscrypt. Right now it is in the volatile-ware stage. Hopefully I'll have it tested enough to post here shortly, if I feel i can pull myself away from my research for a few hours. But I thought I would post a description now to see if anyone can find any problems with the way I'm going about this or has any suggestions. I apologize for the possibly inscrutable descriptions; it's been a while since I last slept. Let me know if anything needs clarification. First, a basic description of the idea: 1. Write a script (perl, sh, etc.) to be executed on a remote machine. 2. Sign the script with PGP. It can also be encrypted using the public key for the emscrypt installation on the remote machine. 3. Mail the signed/encrypted script (a.k.a. emscrypted mail) to the address where emscrypt is installed. 4. The script is received and piped to emscrypt (using procmail or something similar). 5. Emscrypt checks the PGP signature on the message, and checks for replay attacks based on the time stamp from the signature. 6. Emscrypt executes the script, gets the results, encrypts them, and sends them back to you. The install procedure: Create a directory to hold the PGP keyrings and the emscript temporary files. Generate a secret/public key pair for the emscrypt software and place in the emscrypt directory. These need to be DIFFERENT for each installation of emscrypt. Otherwise you are subject to a "same play" attack. I suppose you could create two or more installations with the same key if you will ALWAYS be sending all the same scripts to every installation. Generate a public keyring in the emscrypt directory which has only the keys with which you want to be able to validate incoming scripts. Make them "trusted" by the emscrypt key. Update the PGPPASS, PGPPATH, and emscryptPath variables in the emscrypt script. This is very important since if the PGPPATH is pointing to your normal pubring ANYONE with a key in that ring would be able to run scripts on your system. Actually only the keys which are "trusted", but there may be lots of "trusted" keys which you wouldn't trust to run arbitrary scripts on your computer. Test the script to make sure it seems to work alright on your system. After that, you can set it up to be automatically called when you receive e-mail with the magic subject line of your choosing (or in some other way I suppose). I've been using something resembling the following procmail recipe: :0: * ^Subject.*SQUEAMISH OSSIFRAGE |/MY_PATH/emscrypt How emscrypt works: * Get input Get one input line at a time, and look for Reply-To: and From: headers to get a reply address. As we are slurping up lines, watch for '-----BEGIN PGP' lines. If it is for encryption or a signed message (i.e. as long as it is not for a key block), get all the lines up to and including the appropriate '-----END PGP' line, and save them to a temp file. Note that several scripts can be batched together in a single input file. Just generate the scripts and sign them separately and the combine all the PGP messages into a single file. Also, they may be signed with different keys. * Verify signature Run PGP on the temp file to verify/decrypt it. Save the stderr results from the PGP process in another temporary file. Get the verified(?)/decrypted output from a pipe, and save in memory. (QUESTION: is it possible to have stderr redirected to a separate input pipe and avoid writing to disk? How? (This is in Perl.) I was combining the the stderr and stdout from the PGP process into a single input pipe, but that may allow for leakage of PGP stderr output into the script we are verifying/decrypting if we aren't careful.) Search through the PGP process stderr output to look for important stuff like whether the signature was good, what the time stamp was, and what the key user string is. I'm not real happy with this method. Probably doesn't work well with versions other than 2.6.2 or non english language versions. I'm waiting for the signature code and such in the PGP library from Systemics (an announcement showed up here a couple days ago, http://www.systemics.com/software/ ) which will allow this to be much cleaner. (QUESTION: Any other ideas for handling this?) * Check for replay If the signature is good then we need to check for the dreaded replay attack. This is how I have it working: there is a separate file for each PGP public key which keeps track of the time stamp for the last executed script which was signed by that key. Right now the file names are generated from the key ID string for the pgp key. Mainly because we get that for free when we check the signature. Will probably run 'pgp -kv "ID string"' so that I can get the hex key ID, since that would probably make a more reasonable file name. Besides the value saved to disk, we store a separate time stamp for this "batch" of messages in an associative array by key ID. Each separate mail message is a batch, but we may have more than a single PGP signed script in each message. So the batch time stamp is the stamp we read from a time stamp file for a key ID when we process the first message in a batch for that specific key ID. The batch time stamp is then constant for the remainder of this run of the script. Anyway, we generate a file name based on the key ID, save it in an associative array by key ID for later use, and see if the file actually exists. If the file doesn't exist, create it and save the time stamp from the current signature to the file. Put a timestamp of 100000000000 in an associative array by key ID for later use (this is the batch time stamp: the time stamp is formatted as YYYYMMDDHHmm. I use 100000000000 here since I explicitly check the time stamp format each time to make sure it is composed of exactly 12 digits. Also, if the file doesn't exist, we need to use a batch time stamp that will be lower than that of any of the messages in the current batch for this key ID. I suppose it might be better to generate a time stamp something like (CURRENT_TIME - (some reasonable amount of time)) to limit what is accepted. I also plan to allow a limit for the amount of time which can elapse between the script being signed and being received by emscrypt for cases where the file does exist. If the file did exist on disk, read the time stamp from the file and save in the batch time stamp associative array by key ID. So now we have a replay prevention time stamp to compare to the time stamp from this PGP signed script. If the script stamp is more recent, then we can execute the script. But first, check to see if the script stamp is more recent then the stamp saved in the file. If it is, then replace the file time stamp with the script stamp, and update the associative array which keeps track of these values (this is the "most recent stamp" array, not the "batch stamp" array). * Execute the script Check the variable status to make sure that both the signature and time stamp were acceptable. If not, then generate an appropriate error message explaining why the script was rejected, include a copy of the script, encrypt the message using the submitter's public key, and mail it back. Then go back to the top of the loop to deal with the rest of the input. If it everything checks out, then prepare a file to receive the stderr output, save the script to a file, set the script to executable, and open (execute) it as an input pipe. Get the results from stdout. Open the stderr file, and get the stderr results. Combine the stdout, stderr, and the script (with separators so we can tell what is what), encrypt the whole bundle with the submitter's public key and mail it off. Repeat loop for rest of input. Problems? Suggestions? Let me know. Thanks, - --Matt - -- mcarpent(a)mailhost.tcs.tulane.edu Finger for PGP public key. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMedc/SjtJAMyBnp9AQF83wf+J9P1Lmr8sca12R89LUYcFxRms1gJro/9 E5Ni1kqivWKYJ+JP9geP+k7VLWbq5miby8RMfKemuz77BuK9UIQG1pd6bGNjlSg9 O+XkiB5dbHX6+hZ23wPABzeuu6+3klLfNnzQEuNZ4/jxeNwFIIY3ifYglhWIPoeG a3kpd2DXY1HVjO674TQNGBYn6bnDPi5wMzYSTxJLukKHBzlgaLt4nssv/8N2jhcg XHWqEEvHc2lY0UvBk+wuqJHigzI03NzpFkh7mgF6ll5gEuG0qGgvLIKb+ir4vF1Q k46mNHq03M+Vc5/loLjFfQzcuu24GdjlFY2pHEpHz7rhYG25ONJeDg== =Lm22 -----END PGP SIGNATURE-----

3 3

Call for Papers
by weffross＠counsel.com 17 Dec '03

17 Dec '03

The American University Law Review encourages submissions for possible publication in its upcoming Symposium Issue on The Electronic Future of Cash. American University's Washington College of Law is now planning a full-day conference to accompany the publication of this issue in the Spring of 1997. Topics of interest include, but are not limited to: -- Consumer Protection. The relative advantages and disadvantages to consumers of debit cards, smart cards, on-line cash accounts, electronic checks, digital scrip, and other forms of electronic payment for "cash" transactions ("Electronic Cash"), especially as contrasted with payment by cash, paper checks, and credit cards. The current or potential application of consumer protection statutes and regulations to forms of Electronic Cash. -- Uniform Commercial Code. The extent to which the UCC and associated regulations already cover, or should be extended or modified to cover, Electronic Cash. -- "E-Bank" Regulation. The regulation of issuers of Electronic Cash. -- Criminality. The applicability and creation of laws concerning crimes (counterfeiting, money-laundering, electronic ransom payments, etc.) involving Electronic Cash. -- Privacy, Encryption, and Anonymity. The extent to which the privacy of merchants and consumers engaging in transactions with Electronic Cash can and should be legally protected. -- Security Concerns. Legal issues involving the protection of Electronic Cash systems from hackers, fraudulent participants, and other security threats. -- Microtransactions. Legal issues concerning the implementation and regulation of on-line systems that involve payments of small amounts of Electronic Cash by consumers to service or content providers. -- Interstate and International Aspects. (e.g., Jurisdiction, Choice of Law, Taxation). -- Role of the Federal Government. Should the Government be setting the ground rules for competition among systems and varieties of Electronic Cash? Selecting one or more systems for national implementation? Or just allowing the market to decide? Submissions should be approximately 100 double-spaced pages in length, written in traditional law review format with sufficient footnotes and documentation. Citations should conform to The Bluebook: A Uniform System of Citation (15th ed.1991). Papers should be received by The Law Review by October 1, 1996, and will be selected within two weeks of this deadline. Authors of papers accepted for publication will be expected to confirm within seven days after acceptance their agreement to contribute these papers to the Symposium Issue. Submissions should be made in hard copy to: The American University Law Review/Electronic Cash Symposium, Heather J. Russell/Senior Articles Editor, Washington College of Law, 4801 Massachusetts Avenue, N.W., Suite 617, Washington, DC 20016. Questions can be addressed to Professor Walter A. Effross, [voice] (202) 274-4210, [fax] (202) 274-4130, [e-mail] weffross(a)counsel.com.

1 0

[LONG,FUNNY,NOISE] Cypherpunk wannabe threatens a lawsuit :-)
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

Cypherpunks, I offer these two Usenet articles for your amusement. In article 1, I follow up on Bruce Bough's article, and, among many other things, defend his right to vote (questioned by the orthodox Jewish homophobe Dan Hartung). (It's very long and technical, so you can skip it.) In article 2, Bruce Bough follows up on my article and threatens to prosecute me under the Americans with Disability Act for misspelling his name. This is almost as funny as his litanies about his dementia and memory loss. Have fun. Article 1: =============================================================================== From: dlv(a)bwalk.dm.com (Dr. Dimitri Vulis) Newsgroups: news.admin.net-abuse.misc,news.admin.censorship,news.admin.policy,alt.config,news.groups,alt.journalism,atl.general,alt.culture.usenet,alt.internet.media-coverage,alt.wired,alt.cyberspace,talk.politics.misc,news.admin.net-abuse.misc,ga.general,misc.news.internet.discuss,soc.culture.russian,alt.flame.jan-isley,talk.forgery,alt.usenet.kooks,alt.grelb Subject: Re: Towards A Usenet Social Contract References: <4rpvfi$smg(a)doc.jmu.edu> <4rv6m7$3ns_002(a)mycroft.kenosis.com> Message-ID: <i6a1qD209w165w(a)bwalk.dm.com> Date: Sat, 13 Jul 96 09:25:41 EDT In article <4rv6m7$3ns_002(a)mycroft.kenosis.com>, bruce(a)kenosis.com (Bruce Baugh) wrote: >In article <4rpvfi$smg(a)doc.jmu.edu>, bumgarls(a)falcon.jmu.edu (Lee S. Bumgarner) wrote: > >>Is a little premeditation too much to ask for a smoothly working system? > >Yes. The _only_ info the voting process needs to know is whether the >voter is a unique individual. This is in practical terms not an >achievable task. But processes like serialized authenticated ballots at >least move in that direction. Voter registration that gathers _any_ info >beyond establishing the legitimacy of the address is a step in the wrong >direction. Information not in hand can't be abused, and I see great >potential for abuse of any sort of repository of information about voter >interests, preferences, etc. > >Further, any step toward increasing centralization seems to me counter >to the fundamental paradigm of Usenet, which owes its survival to its >decentralized nature. No system with anything like a real center could >have survived the growth of recent years. One of the last things we need >(in addition to info that can be put to abusive purposes being >collected) is any additional bottleneck. > >>in my opinion, prevents this system from being viable. If we have a >>registration system, then the cabal would be small, say 20 or so people. >>They would not be system admins, simply interested readers. > >I give you...news.groups. All that's necessary of this concept exists. >Further, by functioning in an ungoverned environment, it ensures that >what status people have is _earned_ by virtue of their views and >arguments. The current system is completely open to addition of new >figures to the pantheon. Again, centralization creates the potential for >bottlenecks. > >I don't trust _anyone_ with the power to establish a "cabal" of this >sort. I start with myself. Anyone who holds strong views of matters of >controversy faces the problem of bias, and anyone not informed enough >to hold views on them has no business selecting authority figures. I remember how someone recently argued on news.groups that Bruce Bough's votes should be invalidated because he's dying from AIDS. I strongly disagree with Dan's (?) reasoning, which was, I recall, that someone with only a couple of months left to live shouldn't be telling others how to run Usenet after his death. I think we should consider Bruce's opinions as being representative. After all, a Usenet vote is an interest poll, and the voters are just a sample of a larger population. Not everyone who thinks like Bruce Bough is going to die together with him from AIDS within a few months (sigh). Let him vote. The use of numbered ballots (as proposed by Dr. Grubor and implemented by me), will stop the following kinds of net-abuse: * Cabal supporters such as Russ Allberry (spit) e-mailing pre-filled ballots to their mailing lists, sometimes gathering tens of thousands of votes from people who haven't read the CFV; * Cabal supporters forging cancels to censor Usenet articles they claim contain "unauthorized voting instructions". This pretext has been used to stifle campaigning against the proposals the Cabal wanted to pass, as well as to suppress protests against UVV misconduct by Jan Isley (spit) and his cohorts. The use of a simple randomized question about the CFV - find the line that says this and fill in the missing word on the ballot (as proposed by Dr. Grubor and implemented by me), will stop the following kinds of net-abuses: * Cabal supporters such as Stephanie da Silva (spit) vote YES on every moderated newsgroup without reading the CFV; * Cabal supporters such as Chris Stein (spit) vote NO on every unmoderated newsgroup without reading the CFV. There can be no pre-filled ballots under Dr. Grubor's proposal. But Dr. Grubor's proposals don't address the issue of votetaker fraud. For example, we've exposed Jan Isley (spit) as a liar and a forger, who frivolously "invalidated" or "lost" votes from people he didn't like (including myself), and forged cancels for their protests on news.groups. Emory University called Isley's (spit) forgeries "reprehensible" and pulled his plug for net-abuse. The UVV's refusal to use numbered ballots and to ask (simple) questions about the CFV on the ballot is just a lame excuse. They really want to be able to forge cancels for protests posted to news.groups about votetaker misconduct. For example, of the following dozen votes I've cast, I've only received an ack for my NO vote on soc.culture.israel.moderated (fuck you, Jonathan Kamens). Where are the acks for the following ballots: 1. I e-mailed voting(a)hut.fi and wrote: I vote NO on soc.culture.israel.moderated I received an ack (thank you, Jani). 2. I e-mailed voting(a)hut.fi and wrote (ballot mark skipped): >Voter name: Dr. Dimitri Vulis > >| Insert YES, NO, ABSTAIN, or CANCEL inside the brackets for each >| newsgroup listed below (do not delete the newsgroup name): > > Your Vote Newsgroup > --------- ----------------------------------------------------------- >[ NO ] rec.arts.comics.marketplace.forsale >[ NO ] rec.arts.comics.marketplace.wanted So far, I received no ack. 3. I e-mailed voting(a)hut.fi and wrote: >I vote YES on rec.games.bridge.okbridge So far, I received no ack. 4. I e-mailed voting(a)hut.fi and wrote: >I vote YES on soc.adoption.parenting So far, I received no ack. 5. I e-mailed mtac(a)infobahn.net and wrote: >I vote NO on misc.transport.air-industry.cargo So far, I received no ack. 6. I e-mailed ccmp(a)infobahn.net and wrote: >I vote YES on comp.cad.microstation.programmer So far, I received no ack. 7. I e-mailed ceg(a)infobahn.net and wrote: >I vote YES on comp.emulators.game-consoles So far, I received no ack. 8. I e-mailed smo(a)infobahn.net and wrote: >I vote NO on sci.med.obgyn So far, I received no ack. 9. I e-mailed saf(a)infobahn.net and wrote: >I vote YES on sci.agriculture.net So far, I received no ack. 10. I e-mailed david.bostwick(a)chemistry.gatech.edu and wrote: >Give your real name here: Dr. Dimitri Vulis >If you do not give your real name, your vote may be rejected. > >[Your Vote] Group (Place your vote below in the brackets next to the group) >------------------------------------------------------------------------- >[YES ] comp.lang.dfl So far, I received no ack. 11. I e-mailed david.bostwick(a)chemistry.gatech.edu and wrote: >Give your real name here: Dr. Dimitri Vulis >If you do not give your real name, your vote may be rejected. > >[Your Vote] Group (Place your vote below in the brackets next to the group) >------------------------------------------------------------------------- >[ YES ] misc.invest.misc (renames misc.invest) >[ YES ] misc.invest.mutual-funds (renames misc.invest.funds) >[ YES ] misc.invest.options >[ YES ] misc.invest.marketplace So far, I received no ack. 12. I e-mailed dhartung(a)mcs.com and wrote: >Give your real name here: Dr. Dimitri Vulis >If you do not give a real name on the above line your vote may be rejected. > >[Your Vote] Group >----------------------------------------------------------------------- >[NO ] soc.religion.paganism So far, I received no ack. What's going on? Why are 11 of my ballots not being acknowledged? =============================================================================== Article 2: =============================================================================== Path: ...!newsfeed.internetmci.com!usenet.eel.ufl.edu!psgrain!rainrgnews0!news.aracnet.com!mycroft From: bruce(a)kenosis.com (Bruce Baugh) Newsgroups: news.admin.net-abuse.misc,news.groups,alt.usenet.kooks Subject: Re: Towards A Usenet Social Contract Date: Sun, 14 Jul 96 00:17:16 GMT Organization: Kenosis Design Lines: 29 Message-ID: <4s9eac$1ag_006(a)mycroft.kenosis.com> References: <4rpvfi$smg(a)doc.jmu.edu> <4rv6m7$3ns_002(a)mycroft.kenosis.com> <i6a1qD209w165w(a)bwalk.dm.com> NNTP-Posting-Host: ppp-u11.aracnet.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Newsreader: News Xpress 2.0 Beta #2 In article <i6a1qD209w165w(a)bwalk.dm.com>, dlv(a)bwalk.dm.com (Dr. Dimitri Vulis) wrote: >of a larger population. Not everyone who thinks like Bruce Bough is going to >die together with him from AIDS within a few months (sigh). Let him vote. Dimitri, I invite you to pick a date, not more than twelve months in the future, beyond which you're certain I will die. I will then post the next day. Not, of course, that I expect you to have the honor to admit now that you're deliberately misreading and misunderstanding my posts, nor to admit in the future that you made a claim demonstrably wrong. Nor, I see, can you spell my name correctly, even though you quote it routinely in reply lines and sig files. People who can't read what's in front of them on screen lose credibility when it comes to proposing sweeping changes and radical innovations in software. Further, you might want to read up on the Americans With Disabilities Act. Slanderous and defamatory statements about the handicapped - and my government agrees that I do have a real problem, though it's not AIDS - open you up to interesting liability. Bruce Baugh <*> bruce(a)aracnet.com <*> http://www.aracnet.com/~bruce See my Web pages for New science fiction by Steve Stirling and George Alec Effing er Christlib, the mailing list for Christian and libertarian concerns Daedalus Games, makers of Shadowfist and Feng Shui Unsolicited commercial e-mail will be proofread at $50/hour, min $100. ===============================================================================

1 0