December 2003 - cypherpunks-legacy

Exon in WSJ
by frissell＠panix.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Today's WSJ - Page B1 - Above the fold Government Tackles a Surge of Smut on the Internet "On-line computer services are bracing for a government crackdown against smut on the Internet -- even though nobody's sure if the Net *can* be regulated." Accompanying article on how demand for porno overwhelms sites that try to supply it. DCF -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzjPtIVO4r4sgSPhAQF9IgP/Rv8haetVjaFqbd4j3QMSqAw7J219jej1 ZQTBujNlgFMb94TZSUy/X7oReAutJyaiWDvSyS7Nmnxx0xGAWMgR/8K9SlfJleia Kja7H+cC7DODhGNMo3AUkn+shqKzz/idVZb3EiF1gtP3Xsm5DA5r9vqZyVZlFHxR 1IkGmN76Ax0= =5UtC -----END PGP SIGNATURE-----

1 0

WSJ Article on Sen. Exon's Legislation
by daleh＠ix.netcom.com 17 Dec '03

17 Dec '03

"Government Tackles a Surge of Smut on the Internet" Wall Street Journal Wednesday, February 8, 1995 page B1 ----------Begin Quote---------- Instead, the services would prefer to be treated like phone companies, which claim no responsibility for telephone conversations. With millions of messages passing through each day, the services say couldn't possibly monitor everything even if they tried. Sen. Exon is unconvinced. "If I were against this <the legislation>, if I didn't want to be bothered with it, if I felt it might complicate my ability to make money on the superhighway, that's the argument I would make," he says, adding that a failure by the government to act would be "an open invitation to some of the hardcore pornography getting into our homes." -----------End Quote----------- Dale H.

2 1

USPO & Digital Postage/E-Cash Project
by daleh＠ix.netcom.com 17 Dec '03

17 Dec '03

The US Post Office just killed a project that would have created a digital postage/e-cash system. This would have been a digital replacement for the Pitney-Bose style Postage Metering machines. To use a PM machine one has to take the entire machine physically to a Postal Station and purchase some fixed dollar amount of postage. The Postal clerk unseals and unlocks the machine, dials in the amount of postage purchased and then relocks and reseals the machine. This mechanical system would have been replaced by a serial-port dongle and a piece of software. The dongle would contain an EEPROM in a replacable button (made by Dallas Semiconductor) into which would be loaded data indicating the amount of postage that had been purchased and not yet used. The software package would be able to print the address, postage seal, routing codes, etc directly on the envelope via a laser printer and decrement the amount of available postage left in the dongle. In the original test, customers would have to take the dongle to a Postal Station to purchase additional postage, but the ultimate goal was to have been to have a commerical dial-up service available that one could dial into and purchase additional postage directly. A proof-of-concept prototype was developed in VB and a production prototype was then developed in VC++. Unfortunately the crypto wasn't very strong. The USPO contracted with Carnege-Mellon to try and break the system and they were able to within a couple of weeks. USPO then killed the project. Dale H.

2 1

Re: Cooperation
by Hal 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- From: Nathan Zook <nzook(a)bga.com> > I agree that it is to our advantage to minimize the cooperation between > remailers, for the following reasons: > [...] > But there is a major difference between active cooperation and agreeing to > a standard. Active cooperation is just that--something which cannot be > automated, or which involves automated judgement decisions. I claim that > my ideas are merely standards. A standard which might even be extendable > into the dominions of a hostile government. I see your point. I tend to have something of a knee-jerk reaction against proposals which put more responsibility into the hands of the remailer operators, but as you say the mere promulgation of a standard does not in itself require cooperation. We have de-facto standards right now, which is what makes chaining possible. And from the technical point of view, the idea of remailers encrypting between themselves seems to do no harm and could possibly make the attacker's job potentially more difficult by reducing the amount of information he has available. One problem is that one remailer may not know about all of the others. So to the extent that your proposal requires a registry of remailers, a centralized service which keeps track of all remailers, I still have a problem. This is where my vision departs from those who see the "remailer net" as an entity, and for whom the notion that remailers would treat messages to each other specially is a natural assumption. If you would suggest that at each stage the message included not only the address of the next remailer, along with the "payload" which was already encrypted (by the sender) for that remailer, but in addition a key for that remailer and a request to encrypt under that key, then I would feel much better about it. This way there is no need for the remailer to know anything about whom it is sending to. Likewise if we wanted to specify in the standard that messages could be signed, that also would not imply collusion. However to specify that signatures must be checked would have some implications about acquiring the necessary public keys through some means, and I don't think that should be done. I do like the idea of standards. In fact I wonder if the current "mark 1" remailer command set shouldn't be documented as an Internet RFC. It has been in use for a couple of years now, evolving somewhat over that time, and some twenty or thirty remailers have operated for some part of that time following that spec. It would also give a certain amount of (undeserved, perhaps) respectability to remailer operators if there were an actual numbered RFC which they were following. And it does seem to me that this kind of thing is exactly what the RFC's are for. Certainly there are a great many "minor" RFC's which are less followed than our remailer standards. Hal -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLzZTfBnMLJtOy9MBAQFsRwIA4A5EzFZwJdEmSvcfMmnu+RCAEGYK56dg y2LBawLdYn5FNcnvH6YkfCMHIcWURm1b6emEsw32FVH2m6ScAAH/iQ== =F2+s -----END PGP SIGNATURE-----

5 5

Re: Effects of S.314 (Communications Decency Act)
by jpp＠markv.com 17 Dec '03

17 Dec '03

For my congresional 'representatives'. S.314 is not a moral bill. Making the owner of a computer (or computer network) responsible for what its users store (or transmit) is like making the owners of a parking lot responsible for what is stored in the cars parked there. It just isn't moraly reasonable. S.314 is un-American. America has always been a place where speach is freeest. We have consistently held the expression of ideas to be one of the very most important rights. To hold the owner of a buliten board responsible for the illegal messages posted to it, is to force the buliten board owner to become a government censor in all but name (and wages). It effectively ends the bulliten board's use as a venue of free speach. S.314 is harmfull to America. The kind of 'chilling effect' this bill wil place on the computer (networking) industry would put american companies at a serious disadvantage. Could I really operate an airline reservtion system for a large airline if I could be held liable for illegal information transmitted using my equipment? No. Could I operate the masive software and hardware networks that the phone system requires? No. But, I bet the company I own in Mexico, or in Canada could. They aren't burdened with such (artificially created) liabilities. Or perhaps I could get a special waiver from my friends in Washington. Hmmm. How much will these sorts of 'work arounds' cost american bussiness? S.314 is not enforceable. There is no certain way to tell if a file of data is an illegal one. Stegnography and cryptography, along with the fact that what a bit means depends on which programs are used to interpret it, mean that even this message could be porno, terrorist threats, or arangements for drug trafficing. Imagin searching all the cars in your parking lot for drugs. Very expensive, and not very reliable. Tons of drugs travel past just such inspection sites each year. Now imagine how tough it would be if the drugs could be turned into perfectly normal steal in the body panels of the vehicles! That is what stegnography and cryptography do to data. Turn perfectly 'awfull' data into data perfectly indistinguishable from noise, and then hide the noise as indistinguishable-from-inocent 'errors' in other data. Concider the spelling in this message -- convert each word into a bit -- 1 if it is speled right, 0 if not. Or how about spacing, or, punctuation -- Hmmm. Now supose we add otras idiomas, aux eble muchos languages en cxiu mesagxon. Will computer (network) owners be responsible for the spelling, punctuation, language, word choice, and grammer of all the electronic mail sent, received, and stored? S.314 is bad for *your* career. If you vote to support it, I will vote against you in upcoming elections. I will work to impeach you. I will never employ you, I will not read your memoirs, I will not do business with you in any way what so ever. I urge you to think twice, and then vote no on S.314. j'

2 2

URL for Crypto Hearing Transcript
by John Young 17 Dec '03

17 Dec '03

We've put the dox at: http://site108240.primehost.com/hir-hear.htm (97K hearing transcript) http://site108240.primehost.com/crypto-law8.htm (11K Reno letter)

1 0

(DBWORLD) Massive Digital Data Systems
by nwosuck＠harpo.wh.att.com 17 Dec '03

17 Dec '03

Birds of a Feather Session on the Intelligence Community Initiative in Massive Digital Data Systems To be held in Conjunction with the 1995 ACM SIGMOD International Conference on Management of Data in the Crystal Room at The Fairmont Hotel, San Jose, California on Tuesday, 23 May 1995 from 7 pm to 9 pm ******************************* Massive Digital Data Systems (MDDS) will require effective management, retrieval, and integration of databases that may be heterogeneous. Achieving this concept of massive intelligence information systems will require new technologies and novel approaches for data management. While several advances have been made in database management technology, the complexity and the size of the database coupled with the unique needs of the Intelligence Community (IC) require the development of novel approaches. The MDDS Initiative has been started by the Community Management Staff (CMS) of the IC to identify the data management issues and challenges as well as to develop possible solutions for managing massive databases., The purpose of the Birds of a Feather Session is to provide an overview of the MDDS program, solicit input toward developing a testbed /framework for the initiative, and to have technical discussions on novel methods for managing massive databases. Tentative agenda for the session is as follows: 1. Overview of MDDS Initiative 2. Overview of MDDS Research Projects 3. Discussion on testbed/framework 4. Discussion on techniques for massive database management Information on the MDDS Initiative can be obtained from : http://www.nml.org/other_programs/mdds/mdds.html For more information contact: Dr. Bhavani Thuraisingham K329, The MITRE Corporation, Burlington Road, Bedford, MA 01730 email: thura(a)mitre.org; Phone: 617-271-8873; Fax: 617-271-2352 ------------------------------------------------------------------------------- The dbworld alias reaches many people, and should only be used for messages of general interest to the database community. Requests to get on or off dbworld should go to listproc(a)cs.wisc.edu. to subscribe send subscribe dbworld Your Full Name to unsubscribe send unsubscribe dbworld to change your address send an unsubscribe request from the old address send a subscribe request from the new address to find out more options send help ------------------------------------------------------------------------FOOTER-

1 0

(DBWORLD) MDDS Session Time Change
by Bhavani Thuraisingham 17 Dec '03

17 Dec '03

5/15/95 5:17 PM MDDS Session Time Change Birds of a Feather Session on the Intelligence Community Initiative in Massive Digital Data Systems Held in Conjunction with the 1995 ACM SIGMOD International Conference on Management of Data in the Crystal Room at The Fairmont Hotel, San Jose, California on Tuesday, 23 May 1995 from 7:30 pm to 9:30 pm ******************************* Massive Digital Data Systems (MDDS) will require effective management, retrieval, and integration of databases that may be heterogeneous. Achieving this concept of massive intelligence information systems will require new technologies and novel approaches for data management. While several advances have been made in database management technology, the complexity and the size of the database coupled with the unique needs of the Intelligence Community (IC) require the development of novel approaches. The MDDS Initiative has been started by the Community Management Staff (CMS) of the IC to identify the data management issues and challenges as well as to develop possible solutions for managing massive databases., The purpose of the Birds of a Feather Session is to provide an overview of the MDDS program, solicit input toward developing a testbed /framework for the initiative, and to have technical discussions on novel methods for managing massive databases. Tentative agenda for the session is as follows: 1. Overview of MDDS Initiative 2. Overview of MDDS Research Projects 3. Discussion on testbed/framework 4. Discussion on techniques for massive database management Information on the MDDS Initiative can be obtained from : http://www.nml.org/other_programs/mdds/mdds.html For more information contact: Dr. Bhavani Thuraisingham K329, The MITRE Corporation, Burlington Road, Bedford, MA 01730 email: thura(a)mitre.org; Phone: 617-271-8873; Fax: 617-271-2352 ------------------------------------------------------------------------------- The dbworld alias reaches many people, and should only be used for messages of general interest to the database community. Requests to get on or off dbworld should go to listproc(a)cs.wisc.edu. to subscribe send subscribe dbworld Your Full Name to unsubscribe send unsubscribe dbworld to change your address send an unsubscribe request from the old address send a subscribe request from the new address to find out more options send help ------------------------------------------------------------------------FOOTER-

1 0

Re: FW: Edupage 7/9/95 (fwd)
by dmandl＠bear.com 17 Dec '03

17 Dec '03

"Perry E. Metzger" <perry(a)imsi.com> said: > Mark Contois writes: > > Would that this were so. There seems to be a burgeoning number of web > > sites spouting neo- (and not-so-neo-) Nazi disinfo. Check out > > > > http://204.181.176.4/stormfront/ > > > > and some of the links provided therein. > > 204.181.176.4 is "stormfront.wat.com". > > I suspect that something is amiss (i.e. faked) about the following, > but wat.com shows up as [etc.] That may be (I wouldn't be surprised if they registered their site with an innocent-sounding name to avoid trouble), but I know that those guys are definitely on the net. I've got their URL at home and I take a look at their stuff now and then, just to keep abreast of what those half-wits are up to. There are at least a few bona fide Nazi/White Power sites out there. --Dave. -- ******************************************************************************* Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *******************************************************************************

1 0

Obscura down for a few days.
by loki＠nately.UCSD.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Obscura is suffering from HD troubles. The backups have failed so I am going to have to rebuild it from scratch. This means that the web page and remailer will be down. All mail to the remailers will be lost. I have changed the name server so I will still get mail sent to loki(a)obscura.com. -Lance -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMALFV1Vkk3dax7hlAQHPvAP6A7IWAczKJ3eimrWUgh0F5DMEr7oSpAXg lJJCC2VV4g9lIDD8C2wob1L6sEZwlDnUt6dMpbKBiT3aksSmBqnvMpe/BlaTd2zk ZRGCYHUZkx3aOSp9iZevRhjI0HEdm+g2+PwjJcMyPn5EUmz5vnPI9exOt9VGyJV1 eSCCC3Ngz9k= =ahD6 -----END PGP SIGNATURE-----

1 0