December 2003 - cypherpunks-legacy

Re: S/MIME and the Future of Netscape
by hal9001＠panix.com 17 Dec '03

17 Dec '03

At 11:27 7/24/95, Timothy C. May wrote: >At 12:54 PM 7/23/95, Bob Snyder wrote: >>tcmay(a)sensemedia.net said: >>> With regard to SSL and Netscape not being open to outside developers, >>> several leading e-mail outfits, including Qualcomm, Netscape, >>> Frontier, etc., are working on an interoperable secure e-mail >>> standard called "Secure/MIME," or "S/MIME." >> >>Do you have sources for this information? MOSS is out there at least as a >>Internet Draft, and possibly further along, and Steve Dorner of Qualcomm, the >>original author of Eudora, is pretty active in the MIME community and I doubt >>he would support a second MIME type to do the same thing... > >Some of you have expressed skepticism about the mention of "S/MIME." [snip] All MOSS does is designate the MIME Headers/etc to support Encrypting and/or Signing MIME Parts. It says nothing as to how you do the Encoding or create Signature - only how to package the two parts into a MIME format once you have them. Thus S/MIME is/could-be an implementation of MOSS (as would be a MUA that used the MOSS formats to package a PGP signature or Encrypted Message). For those who want to read the docs, just send this message: >To: mailserv(a)ds.internic.net >From: YOUR-ADDRESS-GOES-HERE > >ENCODING mime >FILE /internet-drafts/draft-ietf-pem-mime-08.txt >FILE /internet-drafts/draft-ietf-pem-sigenc-03.txt

1 0

Re: Banks on the Net (Was: Re: Questions about Conferences)
by Joel Hames 17 Dec '03

17 Dec '03

In my previous post, I asked about the security of First Security National Bank, which doesn't exist. Enzo is right, I was wondering if anyone had information on the security of Security First National Bank (www.sfnb.com) Thanks Joel Hames jhames(a)deltanet.com

1 0

mailing list
by Christian Lagerberg 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- ANGAENDE mailing list hit me :=) - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMBYbGCoZzwIn1bdtAQGOJwF/bMkdrpPv/62bbIv+mlD4XjS9P5+bgezu RBQLRMZSSUkcL2RYa4kfUGCs5mO3ZVQ/ =KtMP -----END PGP SIGNATURE-----

1 0

Crypto Law Survey
by E.J.Koops＠kub.nl 17 Dec '03

17 Dec '03

In a separate message is my survey of cryptography laws. I welcome comments and corrections, but mail me before 31 July, as I'm going on a six weeks' holiday next week. I shall try and keep an updated version on my homepage, where it will be available in a few weeks. To make the survey as wide and accurate as possible, I greatly appreciate receiving additional information. Regards, Bert-Jaap ---------------------------------------------------------------------- Bert-Jaap Koops tel +31 13 66 8101 Centre for Law and Informatization facs +31 13 66 8102 Tilburg University e-mail E.J.Koops(a)kub.nl -------------------------------------- Postbus 90153 | "We forgot the crackers!" | 5000 LE Tilburg | | The Netherlands | Wallace and Gromit | --------------------------------------------------------------------- http://www.kub.nl:2080/FRW/CRI/people/bertjaap.htm ---------------------------------------------------------------------

1 0

Crypto Law Survey
by E.J.Koops＠kub.nl 17 Dec '03

17 Dec '03

CRYPTO LAW SURVEY Version July 1995 Bert-Jaap Koops (koops(a)kub.nl) Please credit if quoting. This survey of cryptography laws is based on several reports and on replies to a posting on Internet discussion lists. Only for France, The Netherlands, and Russia have I consulted original texts of relevant regulations; for the other countries, the reports listed below served as the only source. These findings, therefore, do not pretend to be exhaustive or fully reliable. I thank all who have provided me with information for this survey. Please send comments, corrections, updates, additional information, and questions to E.J.Koops(a)kub.nl. SOURCES [1] KPMG EDP Auditors, Rapport aan de Ministers van Binnenlandse Zaken, Justitie en Verkeer en Waterstaat inzake de uitkomsten van het Bedrijfseffectenonderzoek Cryptografie (Amstelveen, 7 april 1994), pp. 27-38, 107-114 [2] Moret Ernst & Young EDP Audit Management Services, Eindrapport onderzoek ontwerp-regeling encryptie, (Amsterdam, 1 maart 1994), pp. 21-30 [3] James P. Chandler, Diana C. Arrington, Donna R. Berkelhammer, and William L. Gill, Identification and Analysis of Foreign Laws and Regulations Pertaining to the Use of Commercial Encryption Products for Voice and Data Communications, DOE Project No. 2042-E024-A1, Washington, January 1994 [4] Andr Sylvain, Data Encryption and the Law(s) - Results, posted on talk.politics.crypto, 15 December 1994 [5] various references; personal communications by Adam Back, Peter Gervai, Ulf Moeller, Marc Plumb, and Thomas Quinot. ----------------------------------------------------------------------------------- SURVEY PER COUNTRY 1. Export/ import regulations 2. Other laws/regulations pertaining to encryption 3. Threats/ intentions to regulate encryption 4. Regulations stimulating encryption use ----------------------------------------------------------------------------------- _COCOM_ 1. COCOM (Coordinating Committee for Multilateral Export Controls) is an international organization (Japan, Australia, and all NATO members, Ireland excluded) for the mutual control (and restriction) of strategic arms export. It maintains, among others, the International Industrial List and the International Munitions List. In 1991, COCOM has decided to allow export of mass-market cryptographic software (including public domain software). Some member countries of COCOM follow its regulations, but others, such as Germany and the United States, maintain separate regulations. _Australia_ [1, 3] 1. Written permission is needed for exporting cryptographic equipment designed to ensure the secrecy of communications or stored information. 2. no 3. no _Austria_ [1] 2. no 3. no _Belgium_ [1, 3] 1. no 2. no 3. no _Brazil_ [3] 1. no _Canada_ [1, 3, 4, 5] 1. Canada follows COCOM regulations. The exportation of items from Canada may be subject to restriction if they are included on the Export Control List. All types of cryptography can be transported between Canada and the United States, but cryptography imported from the US remains under US ITAR rules and cannot be exported if the US does not allow export. 2. no 3. no (but Canada is monitoring the debate in the US) _People's Republic of China_ [3] 1.China restricts the importation and exportation of voice-encoding devices. _Denmark_ [1, 4] 2. no 3. no 4. The Danish Teletrust Group has set up an Encryption Group to work on the technical and legal concept of public-key certifying authorities. A Centre Certifying Auhtority (CCA) would coordinate control and certification of key centres to provide secure keys within telecommunications. It would be necessary for such a CCA to have a legal basis. The Danish government has not (yet) implemented the initiative into law. _European Union_ [5] 2. no 3. There are rumours that the EU is working on the establishment of a key escrow system to counter the US Clipper initiative. The EU system would allow member states to choose escrow agents where keys have to be deposited. The European Community's Green Book on the Security of Information Systems (Draft 4.0, 18 October 1993) poses a case for the provision of "Public Confidentiality Services" (which offer some sort of Government Access to Keys). _Finland_ [4, 5] 2. no 3. no _France_ [1, 3, 4] 1. a) For exporting authentication- or integrity-only cryptography, a declaration dossier of export delivery must be deposited. A copy of the receipt of declaration must be presented to customs at each exportation. For temporary exportation, a user declaration will serve as export declaration in the case of cryptography used exclusively for personal use by an individual. A delivery declaration will serve as temporary-export declaration for a sample. b) For exporting any other kind of cryptography, apart from once depositing administrative and technical details needed for user or delivery authorisation, a license is needed for each exportation. 2. Delivery, exportation, and use of cryptography are subjected to: a) previous declaration if the cryptography can have no other object than authenticating communications or assuring the integrity of transmitted messages; b) previous authorisation by the Prime Minister in all other cases. Simplified procedures exist for certain cryptography products or certain user categories. For both declaration and authorisation, a dossier containing technical details and administrative data must be submitted. Authorisation can be subjected to certain conditions in order to reserve the use of certain types of cryptography to defined user or application categories. It is unclear to what extent this regulation is being maintained in practice. It seems impossible for individuals or enterprises to obtain authorisation for "strong" cryptography, such as RSA. Moreover, the office dealing with authorisation renders decisions without motivation. _Germany_ [1, 3, 4, 5] 1. COCOM regulations, but Germany maintains export control of both public domain and mass-market encryption software. 2. no 3. Some politicians have expressed a desire to regulate cryptography, but, on the whole, there seems to be no threat that Germany will prepare a law on cryptography. _Hungary_ [5] 2. no 3. no 4. There is a law that provides an agency with the competence to assess cryptography; the agency can declare that it satisfies a minimum security level. _Iceland_ [1] 2. no 3. no _India_ [3] 1. no _Ireland_ [1] 2. no 3. no _Israel_ [3] 1. Israel imposes restrictions on encryption, but the scope of its restrictions is not clear. _Italy_ [1, 3] 1. COCOM regulations. 2. There is a law that demands accessibility of encrypted records for the treasury. 3. no _Japan_ [1, 3] 1. COCOM regulations. 2. no 3. no _Latvia_ [4] 2. no 3. no _Mexico_ [3] 1. no _The Netherlands_ [3, 4, 5] 1. Public domain and mass-market software generally does not require a validated license. Items capable of file encryption do require a validated license. 2. no 3. In March 1994, a Dutch predraft law on cryptography leaked out, the drift of of which was a prohibition of having, using, or trading strong cryptography. Those with a "legitimate concern" could apply for a user license or a trade authorization. One condition for granting a license was giving information to an administration agency; the text did not state whether this information concerned only the algorithm or also all the keys used. After many protests from those who would be affected by the proposed regulation, it was withdrawn. The Dutch authorities are currently studying on alternatives to handle the issue. Although the draft regulation will not be continued in its present scope, it shows how much the judicial authorities fear wide dissemination of strong cryptography. It is to be expected that the Dutch government will want to regulate encryption in some way. _New Zealand_ [1] 2. no 3. no _Norway_ [1] 2. no. 4. A bill on information security has been proposed, which indicates that cryptography can be used for the storage of passwords. It is not sure if and when this bill will come into force. A bill has been proposed on central medical registries that would use cryptographically pseudonimized entries. _Russia_ [3, 5] 1. A license is required for the importation of encryption facilities manufactured abroad. 2. On 3 April 1995, president Jeltsin issued a decree prohibiting unauthorized encryption. State organizations and enterprises need a license to use encryption (for both authentication and secrecy, for storage as well as transmission). Other enterprises and organizations using uncertified cryptography do not receive state orders. The Central Bank shall take measures against commercial banks that do not use certified cryptography when communicating with divisions of the Central Bank. The development, production, implementation, or operation of cryptography without a license is prohibited. _Saudi Arabia_ [3] 1. no _South Africa_ [1, 3] 1. no 2. The South African situation is unclear. There appears to be legislation prohibiting the encryption of data on public telephone networks, but many companies and banks seem to ignore the legislation and do encrypt their data. _Spain_ [1] 2. no 3. no _Sweden_ [3, 4] 1. no 2. no 3. no _Switzerland_ [1, 3] 1. no 2. no 3. no _Turkey_ [1] 2. no. 3. no _United Kingdom_ [1, 3, 4, 5] 1. COCOM regulations. 2. no 3. In its policy on the information superhighway, Labour states it does not approve of escrowed encryption, but it wishes authorities to have the power to demand decryption under judicial warrant. It seems, then, that Labour intends to penalize a refusal to comply with a demand to decrypt under judicial warrant. _United States of America_ [1, 2, 4] 1. The International Traffic in Arms Regulation restricts export of "dual-use" cryptography (that is, cryptography that can serve both civilian and military purposes) by placing it on the Munitions List. For (relatively strong) products that can encipher information, an export license is usually issued only for use by foreign branches of American enterprises and for use y financial institutions. "Weak" cryptography (e.g., with a certain maximum key-length) can also be exported. Export of cryptography that serves only authentication or integrity purposes is ruled by the Export Administration Regulations. Some types of public domain software have been decontrolled and are now on the Commerce Control List. Several initiatives, as yet unsuccessful, have been taken, both in Congress and by the public, to try to mitigate the cryptography export restrictions. 2. no 3. In 1993, the Clinton Administration announced the Escrowed Encryption Initiative (EEI), usually referred to as the Clipper Initiative, after its first implementation in the Clipper chip. A classified, secret-key algorithm, SKIPJACK, has been implemented in an Escrowed Encryption Standard (EES). The reported basic idea of the EEI is to provide citizens with a safe cryptosysem for securing their communications without threatening law enforcement. The EES procures law enforcement access by means of a Law Enforcement Access Field (LEAF) that is transmitted along with each encrypted message; the field contains information identifying the chip used. Law enforcement agencies wire-tapping communications encrypted with EES can decipher tapped messages by obtaining the two parts of the chip's master key that are deposited with two escrow agencies (National Institute of Standards and Technology and the Treasury Department's Automated Systems Division), provided they have a court order for the tapping. The EES is a voluntary standard to be used in telephone communications. Privacy advocates fear that the government may declare escrowed encryption obligatory once it has captured a sufficient portion of the market. It is doubtful that EES will be widely accepted, though, given the scepticism with which the majority of US citizens presently regard escrowed encryption or government access to keys. On June 27, 1995, Senator Grassley introduced the Anti-Electronic Racketeering Act (S.974), which, if enacted, would virtually ban encryption. Only the use of escrow-like software would be an affirmative defense for those prosecuted for using cryptography. The bill doesn't seem to have much support at present. 4. The Utah Digital Signatures Act of 1995 provides a legal framework for the use of cryptography for authentication and integrity purposes.

2 1

Re: Three strikes you're out! for politicians... yeah we wish!
by Michael Froomkin 17 Dec '03

17 Dec '03

In message <9507251610.AA16331(a)ozymandias.austin.ibm.com> Scott Brickner writes: > Therefore, the only organization which can hold a > senator/representative liable for passing a bad law is the one which > passed the law. :( > and the voters -- Michael Froomkin until Aug 6: michael(a)umlaw.demon.co.uk U.Miami School of Law London, England mfroomki(a)umiami.ir.miami.edu <-- this will still find me PO Box 248087 Coral Gables, FL 33124-8087 "Rain in parts, then dry" --BBC See http://www-swiss.ai.mit.edu/6095/articles/froomkin-metaphor/text.html

1 0

Re: CALLER ID AVOIDANCE (fwd)
by Ray Arachelian 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Tue, 25 Jul 1995 23:19:13 -0400 From: Sal Denaro <Sal(a)panix.com> To: sunder(a)escape.com Newgroups: alt.cypher-punks Subject: Re: CALLER ID AVOIDANCE (fwd) <<<<<< INTERJECTION: I didn't write the message Sal's replying to, Sandy did. Sal's on my 'filtered' cypherpunx list. :-) -- Ray. >>>>>>> In article <Pine.BSD/.3.91.950724140311.25983F-100000(a)escape.com>, Ray Arachelian <sunder(a)escape.com> kept the nurses distracted long enough to write: > SANDY SANDFORT > C'punks, > > While reading the July issue of Soldier of Fortune, I ran across > an ad for yet another telephone anonymity service. It reads: > > CALL 1-900-CUT TRAX > > Secure your most sensitive calls from all forms of > caller I.D. and return-call technologies? > > Now make calls from your own telephone safely and > anonymously. No need to find a public phone to > be discreet. > If they are a Licensed Interchange Carrier they must (by law) provided call records and caller id information on court order. If they fail to answer the court order they could loose the right to operate as a LIC. If they are not a fully licensed carrier, they can have all equipment impounded if they do not honor the court order. Ask anyone who knows telco-law. Let's say you call someone with call-id and do something silly like tell them "I'm going to kill you and your boyfriend, leave my bloody glove at the scene and drive away in my white ford bronco." This scares them. The person calls the cops. The cops call the number on caller id. They track down the service and tell the service- "Give up the call records or get closed down." What do you think the carrier will do? I say this all the time, if you want privacy- Don't use the phone. Here are some things I've heard: (Not responsible for blah blah...) 1) Most caller ID equipment will not display Caller ID from calls made at IDSN phones. 2) Most digital cell-phones have the same quirk. 3) Call-id does not work when calls are made from digital PBXs in Japan. 4) Call-id does not work when calls are made from digital PBXs in most parts of east-block Europe. 5) This happens only in Nynex land and will be fixed by 1997. (yes, 1997) -- Salvatore Denaro sal(a)panix.com I waited for the joke/It never did arrive. Yes, I use PGP Words I thought I'd choke/I hardly recognize.

1 0

AP: Load Cash, Cruise Virtual Mall
by rah＠shipwright.com 17 Dec '03

17 Dec '03

>WASHINGTON (AP) A day in the financial life of a future consumer may >begin something like this: Wake up, log in, download some e-cash into >your PCís hard drive, then go cruise the virtual mall. > >Itís on the verge of happening, experts told Congress on Tuesday. But >some caution that, without planning and coordination, the brave new >Internet world of a cashless, checkless society could turn into an >electronic From: listproc(a)mcfeeley.cc.utexas.edu >Date: Sat, 20 May 1995 07:09:01 -0500 >Reply-To: listproc(a)mcfeeley.cc.utexas.edu >Sender: listproc(a)mcfeeley.cc.utexas.edu >To: rah(a)shipwright.com >Cc: grgcombs(a)mail.utexas.edu >Subject: SUBSCRIBE MCIP ROBERT HETTINGA >X-Comment: Unix List Processor, version 6.0c/940712/0 > >You have been added to list mcip(a)mcfeeley.cc.utexas.edu. >The system has recorded your address as > > rah(a)shipwright.com > >and in order for your messages to get posted (if the list accepts postings), >you will have to send them from this address, unless the list does not require >subscription for posting. >If a message is ever rejected, please contact the list's owner: >grgcombs(a)mail.utexas.edu > >Your initial password is 800971739. Please change it as soon as you can >by issuing the following request to listproc(a)mcfeeley.cc.utexas.edu: > > SET MCIP PASSWORD 800971739 new-password > >WARNING: Do not use your login password; you will be breaching security at your >site. > >This system may accept Internet TCP/IP connections for processing of live >requests, and the password will be used to give you subscriber privileges. >For more information, send a 'help live' request to >listproc(a)mcfeeley.cc.utexas.edu. > >For information on this service and how to use it, send the following >request in the body of a mail message to listproc(a)mcfeeley.cc.utexas.edu: > > HELP > >All requests should be addressed to listproc(a)mcfeeley.cc.utexas.edu. >We are currently working on making a better interface for MacPGP, and other >cryptographic programs, for Macintoshes. You can obtain our latest release >of the MacPGP Kit from ftp://duke.bwh.harvard.edu/pub/adam/mcip (The >official MCIP ftp site), or from >http://www.utexas.edu/~grgcombs/htmls/crypto.html (The unofficially >official MCIP home page). Knowledge of programming is not mandatory, but >it would be helpful. Being at least a mild Mac user (either now or in the >past) *is* mandatory. -- Gregory S. Combs <grgcombs(a)mail.utexas.edu> >NOTE: For some reason our list processor doesn't like the version number >in PGP signed messages, so unless you want me to have to forward everything >you write to the MCIP list, please don't sign your mail. (ironic isn't >it? "Tower of Babel." > >"On the Internet ... it is difficult to tell if a transaction has taken >place since there is no central authority to track and report it," said >David M. Van Lear, chief executive of Electronic Payment Services Inc., >a 2 1/2-year-old joint venture of four banks. > >"There are currently no standard operating regulations," he said. "In >addition, there is no central authority to track and report on criminal >activity, including counterfeiting and money laundering." > >It was all a bit mind-boggling for members of the House Banking monetary > policy subcommittee, whose chairman, Rep. Michael Castle, R-Del., >observed, "Some of us can barely read our e-mail." > >But, more than 25,000 merchants in 150 countries are already on the >Internet, selling or advertising products and services to 20 million >users, a figure that will grow to 100 million within five years, >according to MasterCard International. > >So, Castle said, "it is time for lawmakers to start grappling with the >implications of ìan entirely new monetary system in cyberspace, one that > transcends national governments and national boundaries." > >For instance, how will the Federal Reserve Board measure the amount and >velocity of money flowing through the Internet? How will the Internal >Revenue Service audit transactions conducted anonymously without paper >records? What laws apply when a U.S. consumer orders a product from a >business overseas and the goods never arrive? > >The lawmakers received seemingly conflicting advice from a panel of >experts that included Van Lear, executives from MasterCard and Visa >U.S.A. and Scott Cook, the chairman of the personal finance software >company, Intuit Inc. > >They were told that government will be crucial to fostering stability of > the new electronic monetary system and public trust in it but that >premature or too much regulation could stifle innovation. > >The new technology, the experts said, will both open new avenues for >fraud and offer new protections and safeguards. > >The system, some said, needs to be fully auditable so tax and criminal >authorities can reconstruct a series of transactions but it also should >protect Americansí privacy. > >For instance, David Chaum, the pony-tailed chairman of DigiCash Inc., >said his version of electronic cash, or e-cash, would provide the same >privacy protection and anonymity in small transactions as traditional >cash. > >Using encrypted codes and special software that offer much more security > than the current unprotected transfer of credit card information via >the Internet, consumers could download cash into the hard drive of their > personal computers. > >They'd spend it by transferring it to merchants via computer. Or they >could store the cash on "smart cards" equipped with a computer chip >capable of storing far more information than the magnetic strips now on >credit and debit cards. > >The cards then would function like pocket money and could be used in >vending machines, parking meters and subway turnstiles equipped to >receive them. > >MasterCard International and Visa are developing similar smart cards >but, unlike Chaum's, theirs would generate an audit trail that could >help law enforcement officials combatting tax evasion, counterfeiting >and money laundering. > >Rosalind L. Fisher, executive vice president of Visa, a consortium of >financial institutions, urged Congress to maintain public confidence in >new forms of electronic payment by allowing them to be offered only >through institutions to supervision by banking regulators. > >At the same time, she said, ìwe are concerned that additional regulation > in this area will "stifle innovations ... subjecting many of these >products to ... premature death." > >By way of example, she cited a Federal Reserve regulation that, if >applied, could require machines accepting smart cards to issue paper >receipts, ruining the economic viability of the cards for such small >purchases as a 75-cent soda. > >Castle, who plans at least one more hearing on the future of money this >fall, agreed that Congress should hold off on legislating for now but >should be prepared to move quickly if problems develop. > >"I donít think we need regulations now, but we had better be ready to >respond ... if some guy can crack a code and create a million-dollar >account, transfer it around a couple times and end up in the Bahamas," >he said. > ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

Economist on Data Deluge (NewsClip)
by nobody＠valhalla.phoenix.net 17 Dec '03

17 Dec '03

The Economist, July 22, 1995, pp. 77-78. Data communications: Deluged The World Wide Web, as its fans will tell you, lives up to its name. This realm of the Internet lets you visit "home pages" in Bangkok one moment and Bridlington the next. Yet bringing home souvenirs is another matter. To pull all the nice goodies on offer back to his own machine, the home Internaut must squeeze them down a telephone wire. That slows things down, sometimes a lot; this correspondent took two hours to download 100 seconds of the film "Interview with a Vampire". There must be better ways to bring home the data. There are. One is the cables that deliver television to two out of three American homes. Companies such as Intel, General Instruments and Zenith Electronics have been rushing to perfect "cable modems" that squirt data into a personal computer at speeds up to 4m bits per second -- 140 times faster than the speediest telephone modems (28,800 bits per second) used with PCs. But cable modems must wait for the cable-TV companies to rewire their networks with two-way connections; at the moment, cable TV is largely one way. Cable companies such as Tele-Communications Inc, Viacom and Cox expect to offer data connections with TV services within a year. Some Internet surfers are not prepared to wait that long. For the past three months, some data-junkies in America have been downloading from the sky. Hughes, having laid down a challenge to the cable companies with its DirecTV satellite broadcasting system, which is currently providing 150 channels to 500,000 subscribers, is now laying down another. Hughes Network Systems of Germantown, Maryland, is offering a satellite service called Direcrc that can beam down data to a subscriber at a rate of 400,000 bits a second -- enough to transmit a 400-page document in less than a minute. With moderate compression techniques, that would easily allow real-time video. For $995, the DirecPC customer gets a 61-centimetre (24-inch) satellite dish, a coaxial cable, an adapter that fits inside an IBM-type PC and the relevant software. Once installed, subscribers pay $15.95 to download up to 30 megabytes of data a month (which is a lot of text, but not much video). The speed is many times faster than a special digital ISDN line from the telephone company, and the initial cost less (though with the ISDN line time is the only limit on the amount of data downloaded). For an extra $24 a DirecPC customer can get up to 130 megabytes a month. The cable-TV companies are spending $7,000 or more a mile (over $4,000 a kilometre) to make their cables funnel data out as well as television in. Hughes has sidestepped this problem. Subscribers send data out -- generally small bursts to request information, transmit messages and the like -- through a normal telephone modem. These few bytes can trigger a torrent of returned data, taking the fast route to a Hughes ground station, which beams it to a Galaxy IV communications satellite in geosynchronous orbit. From there it is retransmitted to the subscriber's mini-dish. Apart from reaching the Internet and other online services such as news, electronic shopping, stockmarket prices and sports results, Hughes plans to use DirecPC and its successors to distribute large packages of data on behalf of commercial customers -- acting, in effect, as the Federal Express of the digital world. The company has already signed a deal with IBM to deliver software by satellite direct to shops, where it will be replicated on disks or CD-ROMS at the customer's request. Using better equipment, Hughes reckons it should have no difficulty delivering digital packages at up to 2m bits a second. Sooner or later, the cable-TV companies will lick the "back haul" problem. Then, one-way satellite systems such as DirecPC may find themselves squeezed out of the business -- unless they, too, offer subscribers the chance to talk back with a mouth as big as their ears. Hughes has plans to allow such interchanges through a system called Spaceway. Satellites with huge antennae would pick up messages from little dishes and relay them to other little dishes, allowing high data-transmission rates all over the world. The company, with a touch of hype, calls it an "information super skyway". -----

1 0

Re: Three strikes you're out! for politicians... yeah we wish!
by Scott Brickner 17 Dec '03

17 Dec '03

In message <2751(a)umlaw.demon.co.uk> Michael Froomkin writes: >> Therefore, the only organization which can hold a >> senator/representative liable for passing a bad law is the one which >> passed the law. :( >and the voters Not in the sense of being able to punish him. The voters may only withold their support in the next election. Not nearly enough to deter morons like Exon.

1 0

Re: Crypto Law Survey
by Michael＠umlaw.demon.co.uk 17 Dec '03

17 Dec '03

Thank you for your useful survey. May I make two comments about the US section? First, many lawyers believe the ITAR to be unconstitutional as applied to some or all cryptographic algorithims and software; a court test is likely within the next few years. Second, the American Bar Association Section on Science and Technology's Information Security Committee is drafting Guidelines and Model Legislation which, if they are ever completed, will improve upon the Utah initiative. Meanwhile, other states, including California, are considering bills that are similar to Utah's. -- Michael Froomkin until Aug 6: michael(a)umlaw.demon.co.uk U.Miami School of Law London, England mfroomki(a)umiami.ir.miami.edu <-- this will still find me PO Box 248087 Coral Gables, FL 33124-8087 "Rain in parts, then dry" --BBC See http://www-swiss.ai.mit.edu/6095/articles/froomkin-metaphor/text.html

2 1

Encrypting block driver for Linux...need some advice
by Johnathan Corgan 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- All, I dropped off the face of the earth for a few months while fighting a particularly *nasty* divorce, and to nurse my wounds, I immersed myself in writing cypto-code :) What I've come up with is a loadable module block device driver for Linux that implements transparent encryption/decryption (is there a generic word that means both, like 'cryption' or some such?). The way it works is by 'attaching' a filespec to the block driver, and translating block requests into read/write requests at the appropriate offset in the file. During the read or write, the data is transformed with either DES or 3DES (RSAREF implementation). The key is an MD5 hashed passphrase entered by the user when attaching the filespec. The key is not stored anywhere, and there is no hidden structure to the ciphertext (such as a header block.) The filespec can represent pretty much anything--another block device such as a hard drive partition or floppy drive, a regular file, a remote NFS exported file, CDROM, whatever. If the file is remote, only ciphertext is transmitted on the wire. This part is working rather well at this point (as long as everything is done as root), which brings me to the crux of my post. Being a Unix programming novice (lots of C experience on DOS/Windows), I'm pretty clueless when it comes to Unix level security issues. I need to define and implement the appropriate behavior of the device when dealing with access to the data by different users. Ideally, I want something infinitely flexible and configurable--why program in policy?--so that the user/admin can deal with a variety of threat models. Another, more crypto related question--how to deal with IV's? Right now, I'm using 512 byte sectors with CBC. For each sector, the IV is the sector number. This frustrates the known plaintext attack issue, but I'm not sure if such a simple scheme is really effective. Probably not. Then there is a whole host of issues relating to cryptographically hygienic programming practices...of which I am also pretty ignorant (especially on Unix.) I guess you could say the software is at the "proof of concept" stage, and lacks all sorts of desirable features. But it works (with many bugs I'm sure)...and I have to give credit to the Linux effort: so far I've done this with nothing but the kernel source and the kernel hackers guide as a reference. I took a look at doing this with Windows 95 and didn't even know where to start. (No, I'm not bashing Windows--I love Win95, use it all day at the office and get loads of work done with it--but Linux kernel hacking is much more fun. An ideal world would have the Win95 UI/Plug & Play stuff coded on top of a Unix kernel :) In any case, suggestions, criticism, and comments are welcome. The software will eventually be GPL licensed when it is a bit more mature. == Johnathan Corgan "For the first time in history, it is possible to jcorgan(a)aeinet.com have absolute privacy over arbitrary distances." PGP Key Fingerprint: 4F 28 69 B8 76 2E 42 3E 8B 4C 12 BB 3A 43 D4 07 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMBaCnU1Diok8GKihAQGyoQP+JAYyukotfejK84bm8olDs1GMd6zlwuXc S+91DwrPRb8pyciEC6lIoLNS3coMgPdGTEksNNJMbuIXupJNnXnSum9XrPkMzEkG gL/x6n6v4Jzm9B9IyvIV2R1UrIK893EGQbPKTIgGNNsvORJ/NB8nkoMfZalVlNnD Hl3z3vaYgtU= =grpJ -----END PGP SIGNATURE-----

2 2

Re: Defcon agenda
by gt7508b＠prism.gatech.edu 17 Dec '03

17 Dec '03

> Can some kind soul forward me a copy of the agenda for Defcon? I need > dates and times for the various speakers. > > Thanks, > Sam > You can get it from http://underground.org/conventions/defcon/defcon3/ -- =-=-=-=-=-=-= Tom Cross AKA The White Ninja / Decius 6i5 */^\* -=-=-=-=-=-=-=- -=-=-=-=-=- TWN615(a)mindvox.phantom.com GT7508B(a)prism.gatech.edu =-=-=-=-=-=-= =- "Government is not a reason, not an eloquence; it is a force. Like fire, =- -=- it is a dangerous servant and a fearful master." -- George Washington -=-=

1 0

Re: Questions about Conferences
by Phiberflea＠aol.com 17 Dec '03

17 Dec '03

Joel Hames wrote: What is Defcon? Perry Metzger responded: >Some hacker convention. It doesn't have anything to do with crypto per se. Here are just two of the topics which will be discussed: Bruce Schneier, Author of "Applied Cryptography". TOPIC: Will speak on issues surrounding cryptography, digital authentication, digital cash. EFF. TOPIC: Will cover current legal threats, privacy and computer information networks. I believe last year's key speak was Mr. Phil Zimmerman. There are currently 22 speakers registered for this year's convention. :) See ya in Vegas.

1 0

Re: AP: Load Cash, Cruise Virtual Mall
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Or so we thought until my emailer urped: >>electronic From: listproc(a)mcfeeley.cc.utexas.edu >>Date: Sat, 20 May 1995 07:09:01 -0500 >>Reply-To: listproc(a)mcfeeley.cc.utexas.edu >>Sender: listproc(a)mcfeeley.cc.utexas.edu >>To: rah(a)shipwright.com >>Cc: grgcombs(a)mail.utexas.edu >>Subject: SUBSCRIBE MCIP ROBERT HETTINGA >>X-Comment: Unix List Processor, version 6.0c/940712/0 >> >>You have been added to list mcip(a)mcfeeley.cc.utexas.edu. >>The system has recorded your address as >> >> rah(a)shipwright.com >> >>and in order for your messages to get posted (if the list accepts postings), >>you will have to send them from this address, unless the list does not require >>subscription for posting. Well, you get the point. My apologies. Maybe I should do my mail in Netscape instead... ;-) Now I suppose it's time to change my mcip password, eh? Feh. Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

Banks and Crypto
by KDAGUIO＠aba.com 17 Dec '03

17 Dec '03

See attached file: F:\OFFILES\KODMAIL.MSG begin 666 KODMAIL.MSG M_U=00Z\L```!"@`!`````/O_!0`R`.$%```)``(```!"`````P`Q````6P`` M```"U@0``+$````,`%H```"'!0``1/L@5&EM97,@0F]L9"`H4V-A;&%B;&4I M`-`&!@`!``8`!M#1`2,``.@";`"0&D01=`D``````%"&`'SZ40$#``%W(U@" M4",``=&0_O[^_O[^_O_^_________O__________________________``$B M`((`;0&"`=L!*P)/`C8#_0/0!/_____4!/_______UX[0UUD9+*D0T-#9+)# M0T-#9&1D9&1D9&1D9$-#R++(9+*0A9"0A7B<G$Y@G(6]D)QXG)!OA9"0R)"0 MA4-#0V1D0V1O66]91F1O.$-O.*1O9&]O64Y#;V209&199&1DR.ED0V1D``!D M9&0```!#`&1D9&1D9`!D9&\X`)!DD&209)!DD&3/D)!9A5F%6859A5E..$XX M3CA..)!OG&2<9)QDG&20;Y!OD&^0;Y!DD&20;YQDG&209)!D>&^09)!DD&20 M69!9D%F069!OA5F%6859A5F<9)QDG&2<9)QDG&2<;YQO3CA..$XX3CBU<F`` MG&^%.(4XA3B%3H4XD&^0GY!OD&^<9)QDXI2069!9D%EO3F].;TYO3H5#A4.% M0Y!OD&^0;Y!OD&^0;\B0D&2%6859A5D``)!OA3B0;Y!9;TZ%0Y!DD&20;YQD MD&\30P``````9&0```!#````````0T-7R,C(R,C(R,C(R,C(R,C(R,C(R,C( MR,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(>'AX>'AX>'AX>'AX>'AX>'AX M>'AX>'AX>'AX>'AX>'AX>'AX>'AX>$Z0D)!D`&1D0V15561DPV1D9+*R9$9D M9&1DLD8`0T,`<W-DLC0TR,AD9'IZF,ADR&209`!^IZ=O;[(``````$-S```` M````9```O0#I``!&(LC(R,B0D,C(R&20R,ASD)"RLLC(R``````````````` M``!DY;*RR,C(`!H`LF1#0\C(R,C(D'K(LI"0D)"0D)"0D)!X0\ADD&1O9++( MD,B%9$-DD%ED<Y"<B<C(D)"0D)"0D)"0D,C(R,C(8,B0D)"0R,C(R,C(R,C( MR,C(R`#(R,C(R,B0D,C(R,C(R*Z%>IS(D,@```#(R`````!5=@`````````` M````````````````````````````````````````````````````D)"0D``` M````````````````````````````R,@`````````````R```````````R,@` M``````````#(Q9"0D&20D,B0D,C(R````)"0````D&0```"0D)"09````)"0 MD)"0````D)"0````D)"0````D)"0````D)"0D)"0D)"0D)"0D)```````)`` M``"0D)"0D)````"0D)"0D)"0D)!#````D)"00P```)"0D$,```"0D)!#```` MD)"0D````)`````````````````````````````````````````````````` M``````````````````"0````D)"0D````)"0D-&0>H5O``!Z;X59A4Z%69Q9 MD%E..)Q9A6^];Y!9A62<69!Z>F1Z9`!DA5F0685ZD&^<>GIZ>DY9.#A965EZ M67H`>@!Z>@!#0V1D9&1D`````````````&1D````````````>GIZ>GIZ>GIZ M>GIZ>GIZ>GIZ>DY.3DY.3DY965E965E965E965E965E965E963@X.#@X.#@X M.#(a)X.%E965E965E965E965E965E965EZ>GIZ>GIZ>GIZ>GIZ>GIZ>GIZ>D,` M`'H``)"%G$Z<D'I.D&0"9%E#`,A'4B!2971A:6P@4VAA<F5D(%!R:6YT97(@ M*%!2*0``````````1U)25#(N4%)3`%)3`%@">@#S&;@17P@````0('#L`%X0 M-Q+[`2P!"`%<`2P!\#4<'&!8`I#[_P4`,@"("0``!@`0````$P8``/__+P`` M`$0&```!`KT!``!S!@``__]8`0``,`@```@C?`!L`````0`````````";`"0 M&D01=`D``````%"&`'SZ40$#``%VE5@"4",``=%#1R!4:6UE<R!";VQD("A3 M8V%L86)L92D`1V%L;&EA<F0M4F]M86X@,3(N,'!T```!(@""`/____]M`?__ M__________________________]>0T!H<'"`K#Q,3&QP.$@X@'!P<'!P<'!P M<'`X.'!P<$B,B(24I(1TG+!04(R`P*2H>*B,:(BHC+R$>(Q0.%!P9#Q8<%AP M7#QL<#0T9#2H<'!L<$A(1'!<D&!<8%`X4'#I1$-D2```1%1\````0P!`?'Q\ M?'P`9'QL,`"(6)18B%B(6(A8P("4:X1<A%R$7(1<4#10-%`T4#2D<*APJ'"H M<)APJ'"H<*APJ'!X7(A8D'"H<)AP>%RD<'9LB%B(6(A8E%B46)18E%BD<(1< MA%R$7(1<G&R<;)QLG&R<;)QLL'"P<%`P4#!0-%`PHF!0`(QD@#2`-(`T;$AL M,*1PI(BD<*1PJ'"H<,BUC$B,2(Q(:$B`2&A(:$B(1(A$B$2H<*APJ'"H<*AP MJ'"\D'A<C&!X8(Q@``"D<(`TI'",2&A(B$1X7'A<I'"H<*AP3I"0D#@`>&QX M2&]O<'#!<&QLJ*AP3$QD9'"H3`!#0P!D9'[(9&3(R'Y^>GJ8R&3(9)!D`(FY MN7IZR```````0V0```````!D``#!`,@``$RR`04`D0`W`'H`0P`[`"P!`0`` M``%);%@">@#S&;@17P@````0('#L`%X0-Q+[`5@"D/[^_O[^_O[__O______ M__[__________________________P8'#P"0`#@`;`!#`$,`+`$!`!D``'<C MZ`)L`)`:1!%T"0``````4(8`?/I1`0,`6`)0_O[^_O[^_O\#____`O___O__ M_____O[^_O___________O[^N`(a)7`(\`.0!T`$,`0P`L`0$`+P``NR8``W0` MD!I$$9()``````!PA@`(+U$!`P!8`I#^_O[^_O[^__[________^_______^ M_O[^___________^_OZ0#?__CP`Y`&@`0P!#`"P!`0!$``#'BMP":`"0&J@1 MG`D*`````'B&`!2440$#`%@"6/[^_O[^_O[_______[___[_______[^_O[_ M__________[^_OO_!0`R`'8+```!`78```"Z"0```@%P````,`H```,!:P`` M`*`*```$`6L````+"P``?V$X1&]C=6UE;G0`9P``````````P41O8W5M96YT M(%-T>6QE`"!3='EL90`````````````````````````````````````````` M```!%@"Z`P@`H(H``,(`6`((!P@'#P#"P@%8`F`)8`D4`,+&T"!@"<8*"G]A M-$1O8W5M96YT`&<``````````(%$;V-U;65N="!3='EL90`@4W1Y;&4````` M`````````````````````````````````````````@\`C]@&`*K6`P#!`@@' M"`</`,'##,/#",,NQ`C$("#$#,1_839$;V-U;65N=`!G``````````#!1&]C M=6UE;G0@4W1Y;&4`(%-T>6QE```````````````````````````````````` M``````````,+`+VS"`!'A@``P@%8`@@'"`</`,+&T"`(!\8*"G]A-41O8W5M M96YT`&<``````````,%$;V-U;65N="!3='EL90`@4W1Y;&4````````````` M````````````````````````````````!`L`?;$(`*V!``#"`%@""`<(!P\` MPL8H(P@'Q@H*^_\%`#(`T0T```4!I0```*@+```&`78```!-#```!P%T```` MPPP```@!F@```#<-``!_83)$;V-U;65N=`!G``````````"!1&]C=6UE;G0@ M4W1Y;&4`(%-T>6QE```````````````````````````````````````````` M``4\`/%O"P#'$P8`"M0!#```!HD`/P#(``P``=3##,/8`1<`@0`````````` M``````````!!+A<``=@@PP[#UP`%``$%``#7UP$%``$%``'7"@K$#,3$#L1_ M83=$;V-U;65N=`!G``````````#!1&]C=6UE;G0@4W1Y;&4`(%-T>6QE```` M``````````````````````````````````````````86`'G]"``&A@``P@!8 M`@@'"`</`,+"`%@"8`E@"10`PL8H(V`)Q@H*0FEB;&EO9W)P:'D````````` M````P4)I8FQI;V=R87!H>0`````````````````````````````````````` M```````````````````'%`"LBP@`ACH``,(`6`((!P@'#P#"P8"P!+`$"@#! MQB@C"`?&"@I_83%2:6=H="!087(```````````#!4FEG:'0M06QI9VYE9"!0 M87)A9W)A<&@@3G5M8F5R<P````````````````````````````````@Z`&": M"`!3!```P4"@!0@'#`#!V`$7````````````````````````22X7``'8((/! M@+`$L`0*`,'"`%@""`<(!P\`PL8H(P@'Q@H*^_\%`#(`KA````D!HP````,. M```*`:<```"F#@``"P&L````30\```P!M0```/D/``!_83)2:6=H="!087(` M``````````#!4FEG:'0M06QI9VYE9"!087)A9W)A<&@@3G5M8F5R<P`````` M``````````````````````````E#`/WV"``%"0``P0((!P@'#P#!P4#X!V`) M$0#!V`$7``$`````````````````````02X7``'8((/!@`@'"`</`,'"`+`$ M8`E@"10`PL8H(V`)Q@H*?V$S1&]C=6UE;G0`9P``````````@41O8W5M96YT M(%-T>6QE`"!3='EL90`````````````````````````````````````````` M```*0@`<O0H`NF(#``K4`0P```:)`#\`R``,``'4P0((!P@'#P#!PPS#V`$7 M`((`````````````````````,2X7``'8(-<`!0`"!0``U]<!!0`"!0`!UPK$ M#,1_83-2:6=H="!087(```````````#!4FEG:'0M06QI9VYE9"!087)A9W)A M<&@@3G5M8F5R<P````````````````````````````````M,`.,A"`"W#0`` MP0((!P@'#P#!P0)@"6`)%`#!P4!0"K@+%@#!V`$7``(````````````````` M````,2X7``'8((/!@&`)8`D4`,'"``@'N`NX"QD`PL8H([@+Q@H*?V$T4FEG M:'0@4&%R````````````P5)I9VAT+4%L:6=N960@4&%R86=R87!H($YU;6)E M<G,````````````````````````````````,50"7A0@`:A```,$""`<(!P\` MP<$"8`E@"10`P<$"N`NX"QD`P<%`J`P0#AL`P=@!%P`#```````````````` M`````&$N%P`!V""#P8"X"[@+&0#!P@!@"1`.$`X>`,+&*",0#L8*"OO_!0`R M`!`4```-`;\```#@$```#@'(````GQ$```\!T````&<2```0`=D````W$P`` M?V$U4FEG:'0@4&%R````````````P5)I9VAT+4%L:6=N960@4&%R86=R87!H M($YU;6)E<G,````````````````````````````````-7P!OXP@`'!4``,$" M"`<(!P\`P<$"8`E@"10`P<$"N`NX"QD`P<$"$`X0#AX`P<%`B`YH$!\`P=@! M&``$`````````````````````"@Q*1@``=@@@\&`$`X0#AX`P<(`N`MH$&@0 M(P#"QB@C:!#&"@I_8392:6=H="!087(```````````#!4FEG:'0M06QI9VYE M9"!087)A9W)A<&@@3G5M8F5R<P````````````````````````````````YH M`!L5"`#.&0``P0((!P@'#P#!P0)@"6`)%`#!P0*X"[@+&0#!P0(0#A`.'@#! MP0)H$&@0(P#!P4#@$,`2)`#!V`$8``4`````````````````````*&$I&``! MV""#P8!H$&@0(P#!P@`0#L`2P!(H`,+&*"/`$L8*"G]A-U)I9VAT(%!A<@`` M`````````,%2:6=H="U!;&EG;F5D(%!A<F%G<F%P:"!.=6UB97)S```````` M````````````````````````#W``9DH(`($<``#!`@@'"`</`,'!`F`)8`D4 M`,'!`K@+N`L9`,'!`A`.$`X>`,'!`F@0:!`C`,'!`L`2P!(H`,'!0+`3&!4J M`,'8`1<`!@````````````````````!I*1<``=@@@\&`P!+`$B@`P<(`:!`8 M%1@5+0#"QB@C&!7&"@I_83A2:6=H="!087(```````````#!4FEG:'0M06QI M9VYE9"!087)A9W)A<&@@3G5M8F5R<P`````````````````````````````` M`!!Y`%<B"``S(0``P0((!P@'#P#!P0)@"6`)%`#!P0*X"[@+&0#!P0(0#A`. M'@#!P0)H$&@0(P#!P0+`$L`2*`#!P0(8%1@5+0#!P4`(%G`7+P#!V`$7``<` M````````````````````82D7``'8((/!@!@5&!4M`,'"`,`2<!=P%S(`PL8H M(W`7Q@H*^_\%`#(`P!<``!$!S````$(4```2`2L!```.%0``$P$``0``.18` M`!0!AP```#D7``!_83%$;V-U;65N=`!G``````````"!1&]C=6UE;G0@4W1Y M;&4`(%-T>6QE`````````````````````````````````````````````!%8 M`'$'%@!Q#08`V0$%```%``'9"M0!#```!N$`;`#(``P``=3!X%X3[!,I`,'# M`</##,/7``4```4``-?8`1<`@`````````````````````!)+A<``=@@V0,& M```!!@`#V=D#!@`!``8``]G7`04```4``=>#"@K$`<3$#,1$;V,@26YI=``` M```````````````!26YI=&EA;&EZ92!$;V-U;65N="!3='EL90`````````` M`````````````````````````````!(.``'_Q0`"DP``UP(*``($!`0$!`H` M`M?4`!@``!(```$````````````P*C`JL`08``#4#-("C``@22X@02X@,2X@ M82XH,2DH82D@:2D@82D`````````````````````($DN(#$N($$N(&$N*#$I M*&$I(&DI(&$I```````````````````````````````````````````````` M``%$;V-U;65N=`!G````````````````````````````````C``"TMD$%``` M````````````````````%``$V51E8V@@26YI=`````````````````!);FET M:6%L:7IE(%1E8VAN:6-A;"!3='EL90`````````````````````````````` M````````$Z@`%"X```UK``#2`HP`($DN($$N(#$N(&$N*#$I*&$I(&DI(&$I M`````````````````````"`Q("XQ("XQ("XQ("XQ("XQ("XQ("XQ(``````` M`````````````````````````````````````````/X`5&5C:&YI8V%L```` M`````````````````````````````(P``M+9!!0````````````````````` M`!0`!-E_835496-H;FEC86P```````````"!5&5C:&YI8V%L($1O8W5M96YT M(%-T>6QE`````````````````````````````````````````!0I`%?9`P!$ MO@,`P0((!P@'#P#!PPS#V`$8`(0`````````````````````*#$I&``!V"`N M("#$#,3[_P4`,@!T&@``%0&'````\A<``!8!K@```'D8```7`:<````G&0`` M&`&F````SAD``']A-E1E8VAN:6-A;````````````(%496-H;FEC86P@1&]C M=6UE;G0@4W1Y;&4`````````````````````````````````````````%2D` ME^`#`$3"`P#!`@@'"`</`,'##,/8`1@`A0`````````````````````H82D8 M``'8("X@(,0,Q']A,E1E8VAN:6-A;````````````(%496-H;FEC86P@1&]C M=6UE;G0@4W1Y;&4`````````````````````````````````````````%CP` M-O,7`.CM`P`*U`$,```&B0`_`,@`#``!U,,,P]@!%P"!```````````````` M`````$$N%P`!V"###L/7``4``04``-?7`04``04``=?$#L0*"L$""`<(!P\` MP<0,Q']A,U1E8VAN:6-A;````````````(%496-H;FEC86P@1&]C=6UE;G0@ M4W1Y;&4`````````````````````````````````````````%SD``U<3`*)G M`P`*U`$,```&E@`R`,@`#``!U,,,P]@!%P""`````````````````````#$N M%P`!V"#7``4``@4``-?7`04``@4``=<*P0((!P@'#P#!Q`S$?V$T5&5C:&YI M8V%L````````````@51E8VAN:6-A;"!$;V-U;65N="!3='EL90`````````` M```````````````````````````````8.`!B=A,`HGL#`-0!#```!I8`,@`` M``P``=3##,/8`1<`@P````````````````````!A+A<``=@@UP`%``,%``#7 MUP$%``,%``'7"L$""`<(!P\`P<0,Q/O_!0`R`'<@```9`<(```"F&@``&@&& M````:!L``!L!A@```.X;```<`0,$``!T'```?V$Q5&5C:&YI8V%L```````` M````@51E8VAN:6-A;"!$;V-U;65N="!3='EL90`````````````````````` M```````````````````91@"RZ"$`$SP#``K4`0P```:)`#\`R``,``'4PP'# MPPS#UP`%```%``#7V`$7`(``````````````````````22X7``'8(-D#!@`` M`08``]G9`P8``0`&``/9UP$%```%``'7"@K$`<3!`@@'"`</`,'$#,1_83=4 M96-H;FEC86P```````````"!5&5C:&YI8V%L($1O8W5M96YT(%-T>6QE```` M`````````````````````````````````````!HH`$`7`P!$Q@,`P0((!P@' M#P#!PPS#V`$7`(8`````````````````````:2D7``'8("X@(,0,Q']A.%1E M8VAN:6-A;````````````(%496-H;FEC86P@1&]C=6UE;G0@4W1Y;&4````` M````````````````````````````````````&R@`X!H#`$3+`P#!`@@'"`</ M`,'##,/8`1<`AP````````````````````!A*1<``=@@+B`@Q`S$4&QE861I M;F<``````````````````$AE861E<B!F;W(@;G5M8F5R960@<&QE861I;F<@ M<&%P97(````````````````````````````<JP-00```;KD``-``"````,@` M"```T-`%#`"P!+`$(`/H`PP`!=#5`8L#``````````'(``(``````"1=T``( M````R``(``#0T`$,`+`$L`18`K`$#``!T-`$T````%@"L`0(!V`)N`L0#F@0 MP!(8%7`7R!D@''@>T"`H(X`EV"<P*H@LX"XX,9`SZ#5`.)@Z\#Q(/Z!!____ M_________________________P``````````````````````````P`/_____ M____________________________________________________________ M______________________________________\@```````````````````` M`````+`$___0``30V@9Y````$`,(`/@J_`.P!``````````````````````` M````9`````````!D`&0````````````````````````````````````````` M``````````````````````````````````$``````````````````````'D` M!MK:!GD````0`P@`^"H4!+`$``````````````````````````!D```````` M`&0`9``````````````````````````````````````````````````````` M`````````````````````0``````````````````````>0`&V@H*P4A(`\`# M!P#!,8,*"L%(2`/``P<`P3*#"@K!2$@#P`,'`,$S@PH*P4A(`\`#!P#!-(,* M"L%(2`/``P<`P36#"@K!2$@#P`,'`,$V@PH*P4A(`\`#!P#!-X,*"L%(2`/` M`P<`P3B#"@K!2$@#P`,'`,$Y@PH*P4C0`L`#!@#!,3"#"@K!2-`"P`,&`,$Q M,8,*"L%(T`+``P8`P3$R@PH*P4C0`L`#!@#!,3.#"@K!2-`"P`,&`,$Q-(,* M"L%(T`+``P8`P3$U@PH*P4C0`L`#!@#!,3:#"@K!2-`"P`,&`,$Q-X,*"L%( MT`+``P8`P3$X@PH*P4C0`L`#!@#!,3F#"@K!2-`"P`,&`,$R,(,*"L%(T`+` M`P8`P3(Q@PH*P4C0`L`#!@#!,C*#"@K!2-`"P`,&`,$R,X,*"L%(T`+``P8` MP3(T@PH*P4C0`L`#!@#!,C6#"@K!2-`"P`,&`,$R-H,*"L%(T`+``P8`P3(W M@PH*P4C0`L`#!@#!,CC3!@D``<`K(`,)``;3BP,!U?O_!0`R`*0E```=`7T! M``"I(```'@%]`0``)B(``/__1````*,C```"`KT!``#G(P``4W1A9V5G=6ED M90```````````````%-T86=I;F<@1W5I9&4@1F]R;6%T```````````````` M```````````````````````````````=)0'_E@``E0,``-$!(P``)@)D`(0< M?!7\"``````00(X`-RY1$`,``3OV6`)`(P`!T=`%#`"P!+`$=`2P!`P`!=#0 M`0P`L`2P!(0#A`,,``'0T`30````6`*P!`@'8`FX"Q`.:!#`$A@5<!?(&2`< M>![0("@C@"78)S`JB"S@+C@QD#/H-4`XF#KP/$@_H$'_________________ M____________```````````````````````````L`;X%>!C_____________ M____________________________________________________________ M_________________________P``````````````````````````L`2$`]`` M!-#0!@8``0`&``;04W1A9V5G`````````````````````%-T86=I;F<@1W5I M9&4@1F]R;6%T('=I=&@@0V]U<FEE<B`Q,"!&;VYT```````````````````> M)0&FW```:B\``-$!(P``]`%X`!0>#!>,"@````010,D`DSC'$3L``!\I6`)` M(P`!T=`%#`"P!+`$=`2P!`P`!=#0`0P`L`2P!(0#A`,,``'0T`30````6`*P M!`@'8`FX"Q`.:!#`$A@5<!?(&2`<>![0("@C@"78)S`JB"S@+C@QD#/H-4`X MF#KP/$@_H$'_____________________________```````````````````` M```````L`;X%>!C_____________________________________________ M_____________________________________________________P`````` M````````````````````L`2$`]``!-#0!@8``0`&``;00T<@5&EM97,@0F]L M9"`H4V-A;&%B;&4I`$=A;&QI87)D+5)O;6%N(#$R+C!P=`!'86QL:6%R9"U" M;VQD(#$R+C!P=````2(`@@#_____;0'_____________________________ M7D,\9'AXB+`\4%!T>#Q,/(1X>'AX>'AX>'AX/#QX>'A,H)2,F*B,?*B\6%B< MB,BLK(2PF'20L)C$D(B06%A8>&0\8'A8>%Q(<'@\.'`\L'AT='A44$QX9)QH M9&!8/%AXZ41#:%```$1<?````$,`1'Q\?'Q\`&1\>#``E&"48)1@E&"48,2( MF&N,7(Q<C%R,7%@\6#Q8/%@\K'BL=*QTK'28=+!XL'BP>+!XB&248)!XK'28 M=(ADJ'1V=)1@E&"48)A8F%B86)A8J'B,7(Q<C%R,7*APJ'"H<*APJ'"H<+QX MO'A8,%@P6#Q8,*=@6`"<<(@\B#R(/&Q.;#BL>*R0K'BL>*QTK'3(M9A4F%28 M5'10@%!T4'10D$R03)!,L'BP>+!XL'BP>+!XQ)R(9)!@>&"08```J'B(/*QX MF%1T4)!,B&2(9*AXK'2P>$Z0D)`\`'1TA$QO;WAXP7AT=+2T>$Q.9&1XM$P` M0T,`9&1^R&AHR,A^?GIZF,ADR&209`")N;EZ>L@``````$-D````````9``` MR`#(``!,^_\%`#(`(2H``/__6P```-8E```#`KT!```Q)@``!P!V````[B<` M``0"O0$``&0H``!#1R!4:6UE<R!";VQD("A38V%L86)L92D`1V%L;&EA<F0M M4F]M86X@,3(N,'!T`$=A;&QI87)D+4)O;&0@,3(N,'!T`$=A;&QI87)D+4ET M86QI8R`Q,BXP<'0```$B`((`_____VT!____________________________ M_UY#0%QH:(2\.%14;&@T1#1<:&AH:&AH:&AH:#0T:&AH4)"8?)2@?'"4K%10 MG'BTJ)AXF)Q@@*2(O)B,>%(a)T5&AD.&Q<3&Q,0&!@0#Q<.*1T5&!@5#A$=%R( M8$Q86#18:.E(0U1$```X4'P```!#`#Q\?'Q\?`!D?&`P`)ALE&R8;)ALF&RX M7)1K?$Q\3'Q,?$Q40%1`5$!40*ATF%285)A4F%2D=*1TI'2D=(Q,F&R0;)A4 MF%2,3*!4=F"8;)ALF&R43)1,E$R43*!L?$Q\3'Q,?$R48)1@E&"48)1@E&"L M8*Q@5#!4,%1`5#"?8%``G%QX.'@X>#AL/VPPJ'2HE*ATJ'285)A4R+6<5)Q4 MG%1@.(`X8#A@.(!$@$2`1*1TI'2D=*1TI'2D=+R(C$QX6'A@>%@``*!L>#BH M=)Q48#B`1(Q,C$R@;)A4I'1.D)"0-`!L;'A0;V]H:,%H;&R<G&A,3&1D:)Q, M`$-#`&1D?LA86,C(?GYZ>IC(9,ADD&0`B;FY>GK(``````!#9````````&0` M`,@`R```3$-'(%1I;65S($)O;&0@*%-C86QA8FQE*0!'86QL:6%R9"U2;VUA M;B`Q,BXP<'0`1V%L;&EA<F0M0F]L9"`Q,BXP<'0`1V%L;&EA<F0M271A;&EC M(#$R+C!P=`!'86QL:6%R9"U";VQD271A;&EC(#$R+C!P=````2(`@@#_____ M;0'_____________________________7D,X8&AH@+PX6%AT:#1(-%1H:&AH M:&AH:&AH-#1H:&A0C)R$E*2$?)RT7%BD?+2HG("<H&2`I)3$F)1\6#18:&0X M<&!,;%!$9&1,.&1`K'Q88&1</$1\9(QD5%A8-%AHZ4A#8$@``#Q<?````$,` M0'Q\?'Q\`&1\8#``G'"4<)QPG'"<<,1DE&N$4(10A%"$4%Q,7$Q<3%Q,J'R< M6)Q8G%B86*1\I'RD?*1\E%2<<)!LD%B86)14I%AV8)QPG'"<<)1,E$R43)1, MI&R$4(10A%"$4)QDG&2<9)QDG&2<9+1DM&1<,%PP7$Q<,*=@6`"D9'Q`?$!\ M0&Q4;#BH?*B<J'RH?)Q8G%C(M:!<H%R@7&0\@#QD/&0\@$2`1(!$I'RD?*1\ MI'RD?*1\Q(R45'Q8>&!\6```I&Q\0*A\H%QD/(!$E%245*1LG%BD?$Z0D)`T M`&QL@%!O;VAHQ&AL;)R<:$Y.9&1HG$X`0T,`9&1^R&!@R,A^?GIZF,ADR&20 M9`")N;EZ>L@``````$-D````````9```R`#(``!.^_\%`#(```````\`6@(` M`%,J``#__R$````C!@``"``"````K2P```````````````"R`04`D0`W`'H` M0P`[`"P!`0````%);%@">@#S&;@17P@````0('#L`%X0-Q+[`5@"D/[^_O[^ M_O[__O________[__________________________P8'#P"0`#@`;`!#`$,` M+`$!`!D``'<CZ`)L`)`:1!%T"0``````4(8`?/I1`0,`6`)0_O[^_O[^_O\# M____`O___O_______O[^_O___________O[^N`(a)7`(\`.0!T`$,`0P`L`0$` M+P``NR8``W0`D!I$$9()``````!PA@`(+U$!`P!8`I#^_O[^_O[^__[_____ M___^_______^_O[^___________^_OZ0#?__CP`Y`&@`0P!#`"P!`0!$``#' MBMP":`"0&J@1G`D*`````'B&`!2440$#`%@"6/[^_O[^_O[______P3___[_ M______[^_O[___________[^_B0+__^0`#@`;`!#`$,`+`$!`%L``"?$W`)L M`)`:Y!%T"0H`````>(8`JO-1`0,`6`*8_O[^_O[^_O___________O______ M_O[^_O___________O[^_____P``9```R`#(``!,```````````````````` M```````````````````````````````````````````````````````````` M``````````````#_____`````````````````````````````````````.D` M2`!#`%0`1```````.`!0`'P`````````0P```#P`?`!\`'P`?`!\````9`!\ M`&``,```````T`OW`)`SV"<!```````````````````````````````````` M````````````````````D#/8)P$(4W1A;F1A<F0````````````````````` M````````````````````````D#/8)P$````````````````````````````` M``````````````````````````"0,]@G`0!3=&%N9&%R9`!3!/__```#`')* M970@24E)`!'__P```1?Z$1H`%!*I`@``1/NP!+`$L`2P!``````````````` M``````````$``````````````````````````````/<`"]!4:&4@06UE<FEC M86X@0F%N:V5R<R!!<W-O8VEA=&EO;B!I<R!A='1E;7!T:6YG('1O(&%D9')E M<W,@=&AE('!R:79A8WD@86YD('-E8W5R:71Y(&YE961S#6]F(&)A;FMS(&%N M9"!B86YK(&-U<W1O;65R<R!B>2!E;G-U<FEN9R!T:&%T(&5A8V@@:&%V92!A M8V-E<W,@=&\@87!P<F]P<FEA=&4-8W)Y<'1O9W)A<&AI8R!T;V]L<RX*"E1H M92!!0D$@0W)Y<'1O9W)A<&AI8R!0;VQI8WD@=VEL;"!B92!P;W-T960@;VX@ M=&AI<R!L:7-T(&QA=&5R('1O9&%Y+@H*("`@("`@("`@*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ"M0`'```%E\& M`0```````````#`J,"HP*K`$L`0<``#4#`K0!0P`L`2P!+`$6`(,``70T`4, M`+`$6`*P!+`$#``%T-`%#`"P!+`$L`18`@P`!=#0!0P`L`18`K`$L`0,``70 MT`4,`+`$L`2P!%@"#``%T-`%#`"P!%@"L`1H`0P`!=#0!0P`L`1H`;`$L`0, M``70T`4,`+`$L`2P!%@"#``%T-`%#`"P!%@"L`2P!`P`!=#0!0P`L`2P!+`$ M6`(,``70"D-/3E1!0U0Z("!3;VYI82!"87)B87)AP0)H$&@0)@#!P0+`$L`2 M+`#!P0(8%1@5,@#!("`@("`@("`@1D]2($E-345$24%412!214Q%05-%"L$" M"`<(!Q``P2`@("`@("`@("@R,#(I(#8V,ZDU-#8Y("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M("`(a)*#$Y.34I"@K4`0P```:/`%H`C00,``'4PPS#T`8&```"!@`&T-0%"``7 M`!L'"``%U$%"02!214%&1DE235,@4U504$]25"!&3U(@4%))5D%41:E314-4 M3U((a)0T].5%)/3"`*U`4(`"@`K0\(``743T8@0U)94%1/1U)!4$A9"M0%"``O M`.P3"``%U,0,Q,,,P\,(PPK4!0@`"@`E!@@`!=1!<W-O8VEA=&EO;B!296-O M;6UE;F1S(&$@,3"I>65A<B!%>'1E;G-I;VX@9F]R('1H92!$871A($5N8W)Y M<'1I;VX@4W1A;F1A<F0*U`4(`"\`[!,(``74"M0!#```!I``60`:"0P``=34 M!0@`+P#L$P@`!=30!@8``@`&``;0U`4(``L`L`0(``74Q`S$Q`C$P0((!P@' M$`#!T`((```!@`$(``+05T%32$E.1U1/3BP@2G5L>2`R,2"IJ2!4:&4@1&%T M82!%;F-R>7!T:6]N(%-T86YD87)D("A$15,I('-H;W5L9"!B90UR96-E<G1I M9FEE9"!F;W(@870@;&5A<W0@,3`@;6]R92!Y96%R<R!T;R!A;&QO=R!I;G1E M<F5S=&5D(&9I;F%N8VEA;"!I;G-T:71U=&EO;G,@861E<75A=&4-=&EM92!T M;R!C;VYV97)T('1O(&%N>2!N97<@8W)Y<'1O9W)A<&AY('-T86YD87)D+"!T M:&4@06UE<FEC86X@0F%N:V5R<R!!<W-O8VEA=&EO;B!S86ED#6EN(&$@<&]L M:6-Y('-T871E;65N="!I<W-U960@=&]D87DN"L$""`<(!Q``P45N8W)Y<'1I M;VX@:7,@=&AE('!R;V-E<W,@=VAE<F5B>2!S96YS:71I=F4@9&%T82!C;VUM M=6YI8V%T:6]N<RP@<W5C:"!A<R!W:7)E#71R86YS9F5R<RP@8W)E9&ET(&-A M<F0@86YD(&%U=&]M871E9"!T96QL97(@;6%C:&EN92!T<F%N<V%C=&EO;G,L M(&%R92!P<F]T96-T960@8GD@<V5C<F5T#6-O9&5S('1O('!R;W1E8W0@=&AE M:7(@8V]N9FED96YT:6%L:71Y+B`@($1%4RP@<F5L96%S960@:6X@,3DW-RP@ M:7,@=&AE('!R:6UA<GD@;65T:&]D#75S960@8GD@9FEN86YC:6%L(&EN<W1I M='5T:6]N<R!T;R!E;F-R>7!T(&EN9F]R;6%T:6]N+@K!`@@'"`<0`,%#<FET M:6-S('-A>2!T:&%T('1H92!L;VYG97(@1$53(&ES('5S960L('1H92!M;W)E M(&QI:V5L>2!I=',@8V]D92!C;W5L9"!B92!B<F]K96XN"E=H:6QE(')E86QI M>FEN9R!T:&ES(&-O=6QD(&QI;6ET(&ET<R!L:69E('-P86X@87,@82!G;W9E M<FYM96YT(&-E<G1I9FEE9"!S=&%N9&%R9"P@04)!#7=A<FYE9"!T:&%T(')E M<75I<FEN9R!B86YK<R!T;R!C;VYV97)T('1O(&$@;F5W('-T86YD87)D(&)Y M(#$Y.3@@*'1H92!Y96%R($1%4R=S#6-E<G1I9FEC871I;VX@97AP:7)E<RD@ M8V]U;&0@8F4@<')O:&EB:71I=F5L>2!C;W-T;'D@9'5E('1O('1H92!H:6=H M(&QE=F5L(&]F(&5L96-T<F]N:6,@9G5N9',-=')A;G-F97)S('-E8W5R960@ M8GD@1$53+B`@04)!('1H97)E9F]R92!E;F-O=7)A9V5D('1H92!.871I;VYA M;"!);G-T:71U=&4@9F]R(%-T86YD87)D<PUA;F0@5&5C:&YO;&]G>2`H3DE3 M5"D@=&\@8V]N=&EN=64@=&\@96YD;W)S92!$15,@87,@82!&961E<F%L($EN M9F]R;6%T:6]N(%!R;V-E<W-I;F<-4W1A;F1A<F0@*$9)4%,I(&9O<B!U<V4@ M8GD@=&AE(&9I;F%N8VEA;"!C;VUM=6YI='DN"L$""`<(!Q``P51H97)E(&AA M<R!B965N(&%N(&]N9V]I;F<@9&5B871E(')E9V%R9&EN9R!W:&\@<VAO=6QD M(&-O;G1R;VP@=&AE(&1E=F5L;W!M96YT#6%N9"!S=7!P;W)T(&]F('!R:79A M=&6I<V5C=&]R(&-O;7!U=&5R('-E8W5R:71Y('-T86YD87)D<SH@('1H92!G M;W9E<FYM96YT(&]R('1H92!P<FEV871E#7-E8W1O<BX@($%"02!S=')O;F=L M>2!R96-O;6UE;F1S('1H870@=&AE(%4N4RX@9V]V97)N;65N="!W;W)K('=I M=&@@=&AE('!R:79A=&4@<V5C=&]R#6%N9"!#;VYG<F5S<R!I;B!A;B!O<&5N M(&9O<G5M('1O(&1E=F5L;W`@82!C;VUP<F5H96YS:79E('!O;&EC>2!O;B!T M:&4@8V]M;65R8VEA;"!U<V4-;V8@8W)Y<'1O9W)A<&AY+B`*P0((!P@'$`#! M26X@:71S(&YE=VQYJ7)E=FES960@<&]L:6-Y('-T871E;65N="!O;B!C<GEP M=&]G<F%P:'DL($%"02!P<F]P;W-E9"!A;'1E<FYA=&EV97,@"G1O($1%4R!A M;F0@;W5T;&EN960@;W1H97(@8W)I=&5R:6$@=&AA="!M=7-T(&)E(&UE="!B M969O<F4@8VAA;F=E<R!I;B!C<GEP=&]G<F%P:&EC(`IS=&%N9&%R9',@8V%N M(&)E(&%C8V5P=&5D(&)Y('1H92!B86YK:6YG(&EN9'5S=')Y+B`@(%1H97-E M(&-R:71E<FEA(*FI('=H:6-H('=I;&P@8F4@U``<```6`2@"```````````# M,"HP*C`JL`2P!!P``-2,T`8&```"!@`&T-0%"``L`*$2"``%U"AM;W)E*2`* MU`4(`"\`[!,(``74T`8&``(`!@`&T-0%"``+`+`$"``%U`K4`0P```:/`%H` MN@(,``'4PPS#04)!($-265!43T=205!(62!03TQ)0UDO4#(*U`$,```&D`!9 M`!<$#``!U,0,Q'!R97-E;G1E9"!N97AT('=E96L@=&\@<F5P<F5S96YT871I M=F5S(&]F('1H92!7:&ET92!(;W5S92P@52Y3+B!$97!A<G1M96YT(&]F#4-O M;6UE<F-E+"!.871I;VYA;"!396-U<FET>2!!9V5N8WD@*$Y302D@86YD(&9E M9&5R86P@8F%N:VEN9R!A9V5N8VEE<R"IJ2!W97)E#61E=F5L;W!E9"!F;VQL M;W=I;F<@82!T=V^I9&%Y(&UE971I;F<@:&5L9"!I;B!*=6YE(&]F(&)A;FME M<G,L('9E;F1O<G,@86YD(&-R>7!T;PUE>'!E<G1S(&-O;F-E<FYE9"!A8F]U M="!T:&4@9F5D97)A;"!G;W9E<FYM96YT)W,@9&ER96-T:6]N(')E9V%R9&EN M9R!P<FEV871EJ7-E8W1O<@UI;F9O<FUA=&EO;B!S96-U<FET>2X@"L$""`<( M!Q``P5-P96-I9FEC86QL>2P@04)!(')E8V]M;65N9&5D.@K!`@@'"`<0`,'` M`@3`("!4:&4@9FEN86YC:6%L('-E<G9I8V5S(&EN9'5S=')Y(&)E(&%L;&]W M960@=&\@8V]N=&EN=64@=&\@=7-E($1%4R!B87-E9"!O;B!R:7-K#<$""`<( M!Q``P6%S<V5S<VUE;G0@*&4N9RX@=F%L=64@;V8@=&AE('1R86YS86-T:6]N M*2!A;F0@=&AE(&)U<VEN97-S(&%P<&QI8V%T:6]N(&EN=F]L=F5D+B`*P0(( M!P@'$`#!P`($P"`@02!S96-U<FET>2!F<F%M97=O<FL@96YC;VUP87-S:6YG M(&$@9F%M:6QY(&]F(&-O;6UE<F-I86QL>2!A=F%I;&%B;&4-P0((!P@'$`#! M86QG;W)I=&AM<RP@:6YC;'5D:6YG($1%4RP@8F4@9&5V96QO<&5D+B`@5&AI M<R!F<F%M97=O<FL@<VAO=6QD(&EN8VQU9&4@80W!`@@'"`<0`,%P<F]C97-S M(&9O<B!N96=O=&EA=&5D(&%L9V]R:71H;2!S96QE8W1I;VX@8F%S960@;VX@ M=&AE(&QE=F5L(&]F(')I<VL@86YD(&]T:&5R#<$""`<(!Q``P6)U<VEN97-S M(')E<75I<F5M96YT<RX@(`K!`@@'"`<0`,'``@3`($]P<&]S:71I;VX@=&\@ M9V]V97)N;65N="!M86YD871E9"!K97D@;6%N86=E;65N="!S>7-T96US(&9O M<B!F:6YA;F-I86P-P0((!P@'$`#!87!P;&EC871I;VYS('=H97)E(&ME>7,@ M=V]U;&0@:&%V92!T;R!B92!S=&]R960@;W5T<VED92!T:&4@9FEN86YC:6%L M(&EN<W1I='5T:6]N#<$""`<(!Q``P2AE+F<N(&ME>2!R96=I<W1R871I;VXO M<W5R<F5N9&5R(&]R('1H92!M86YD871O<GD@97-C<F]W(&]F(&-R>7!T;V=R M87!H:6,@:V5Y<RDN(`W!`@@'"`<0`,%);G-T96%D+"!B86YK<R!S:&]U;&0@ M8V]N=&EN=64@=&\@8F4@<F5S<&]N<VEB;&4@9F]R(&ME>2!M86YA9V5M96YT M(&%N9`W!`@@'"`<0`,%C;VYT:6YU92!T;R!C;V]P97)A=&4@=VET:"!G;W9E M<FYM96YT(&9O<B!L87<@96YF;W)C96UE;G0@<'5R<&]S97,L(&%S(')E<75I M<F5D#<$"$2,1(U,`P6)Y(&QA=RX*(,$""`<(!Q0`P<`"!,`@17AP;W)T(&]F M(&-R>7!T;V=R87!H>2!F;W(@9FEN86YC:6%L(&%P<&QI8V%T:6]N<R!M=7-T M(&YO="!B92!R97-T<FEC=&5D+@K!`@@'"`<4`,'``@3`($9U;&P@<&%R=&EC M:7!A=&EO;B!O9B!#;VYG<F5S<R!A;F0@=&AE('!R:79A=&4@<V5C=&]R(&)E M9F]R92!E<W1A8FQI<VAI;F<@82!5+E,N#<$""`<(!Q0`P7!O;&EC>2!F;W(@ M=&AE(&-O;6UE<F-I86P@=7-E(&]F(&-R>7!T;V=R87!H>2P@:6YS=&5A9"!O M9B!B96EN9R!C87)R:65D(&]U="!S;VQE;'D-P0((!P@'%`#!8GD@17AE8W5T M:79E($]R9&5R+@K!`@@'"`<4`,%;3F]T93H@(%1H97-E(')E8V]M;65N9&%T M:6]N<R!W97)E('-U;6UA<FEZ960N("!&;W(@=&AE(&9U;&P@<W1A=&5M96YT M+"!P;&5A<V4-P0((!P@'%`#!8V%L;"!3;VYI82!"87)B87)A(&%T(#(P,B\V M-C.I-30V.2Y="L$""`<(!Q0`P=`""`"``0`!"``"T%1H92!!;65R:6-A;B!" M86YK97)S($%S<V]C:6%T:6]N(&ES('1H92!O;FQY(&YA=&EO;F%L('1R861E M(&%N9"!P<F]F97-S:6]N86P-87-S;V-I871I;VX@<V5R=FEN9R!T:&4@96YT M:7)E(&)A;FMI;F<@8V]M;75N:71Y+"!F<F]M('-M86QL(&-O;6UU;FET>2!B M86YK<R!T;R!L87)G90UB86YK(&AO;&1I;F<@8V]M<&%N:65S+B`@04)!(&UE M;6)E<G,@<F5P<F5S96YT(&%P<')O>&EM871E;'D@.3`@<&5R8V5N="!O9B!T M:&4-8V]M;65R8VEA;"!B86YK:6YG(&EN9'5S=')Y)W,@=&]T86P@87-S971S M+"!A;F0@86)O=70@.30@<&5R8V5N="!O9B!!0D$@;65M8F5R<R!A<F4-8V]M M;75N:71Y(&)A;FMS('=I=&@@87-S971S(&QE<W,@=&AA;B`D-3`P(&UI;&QI 1;VXN"L'@1!/L$S@`P2,C(X/! ` end

1 0

AP: Load Cash, Cruise Virtual Mall
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Ahem. One more time... >WASHINGTON (AP) A day in the financial life of a future consumer may >begin something like this: Wake up, log in, download some e-cash into >your PC's hard drive, then go cruise the virtual mall. > >It's on the verge of happening, experts told Congress on Tuesday. But >some caution that, without planning and coordination, the brave new >Internet world of a cashless, checkless society could turn into an >electronic "Tower of Babel." > >"On the Internet ... it is difficult to tell if a transaction has taken >place since there is no central authority to track and report it," said >David M. Van Lear, chief executive of Electronic Payment Services Inc., >a 2 1/2-year-old joint venture of four banks. > >"There are currently no standard operating regulations," he said. "In >addition, there is no central authority to track and report on criminal >activity, including counterfeiting and money laundering." > >It was all a bit mind-boggling for members of the House Banking monetary > policy subcommittee, whose chairman, Rep. Michael Castle, R-Del., >observed, "Some of us can barely read our e-mail." > >But, more than 25,000 merchants in 150 countries are already on the >Internet, selling or advertising products and services to 20 million >users, a figure that will grow to 100 million within five years, >according to MasterCard International. > >So, Castle said, "it is time for lawmakers to start grappling with the >implications of ìan entirely new monetary system in cyberspace, one that > transcends national governments and national boundaries." > >For instance, how will the Federal Reserve Board measure the amount and >velocity of money flowing through the Internet? How will the Internal >Revenue Service audit transactions conducted anonymously without paper >records? What laws apply when a U.S. consumer orders a product from a >business overseas and the goods never arrive? > >The lawmakers received seemingly conflicting advice from a panel of >experts that included Van Lear, executives from MasterCard and Visa >U.S.A. and Scott Cook, the chairman of the personal finance software >company, Intuit Inc. > >They were told that government will be crucial to fostering stability of > the new electronic monetary system and public trust in it but that >premature or too much regulation could stifle innovation. > >The new technology, the experts said, will both open new avenues for >fraud and offer new protections and safeguards. > >The system, some said, needs to be fully auditable so tax and criminal >authorities can reconstruct a series of transactions but it also should >protect Americansí privacy. > >For instance, David Chaum, the pony-tailed chairman of DigiCash Inc., >said his version of electronic cash, or e-cash, would provide the same >privacy protection and anonymity in small transactions as traditional >cash. > >Using encrypted codes and special software that offer much more security > than the current unprotected transfer of credit card information via >the Internet, consumers could download cash into the hard drive of their > personal computers. > >They'd spend it by transferring it to merchants via computer. Or they >could store the cash on "smart cards" equipped with a computer chip >capable of storing far more information than the magnetic strips now on >credit and debit cards. > >The cards then would function like pocket money and could be used in >vending machines, parking meters and subway turnstiles equipped to >receive them. > >MasterCard International and Visa are developing similar smart cards >but, unlike Chaum's, theirs would generate an audit trail that could >help law enforcement officials combatting tax evasion, counterfeiting >and money laundering. > >Rosalind L. Fisher, executive vice president of Visa, a consortium of >financial institutions, urged Congress to maintain public confidence in >new forms of electronic payment by allowing them to be offered only >through institutions to supervision by banking regulators. > >At the same time, she said, ìwe are concerned that additional regulation > in this area will "stifle innovations ... subjecting many of these >products to ... premature death." > >By way of example, she cited a Federal Reserve regulation that, if >applied, could require machines accepting smart cards to issue paper >receipts, ruining the economic viability of the cards for such small >purchases as a 75-cent soda. > >Castle, who plans at least one more hearing on the future of money this >fall, agreed that Congress should hold off on legislating for now but >should be prepared to move quickly if problems develop. > >"I donít think we need regulations now, but we had better be ready to >respond ... if some guy can crack a code and create a million-dollar >account, transfer it around a couple times and end up in the Bahamas," >he said. > ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

Re: NRC panel wants questions for Law Enforcement on crypto policy
by mkj＠october.ducktown.org 17 Dec '03

17 Dec '03

----- Forwarded message from David Lesher ----- >In April, gnu asked: >> Herb Lin called today to ask if the Cypherpunks could come up with a >> list of questions for their panel to ask the law enforcement community >> about crypto policy. They will be meeting with senior law enforcement >> officials like FBI Director Freeh a week or so from now. > >Did we ever get any feedback on this? > >- -- >A host is a host from coast to coast.................wb8foz(a)nrk.com >& no one will talk to a host that's close........[v].(301) 56-LINUX >Unless the host (that isn't close).........................pob 1433 >is busy, hung or dead....................................20915-1433 ----- End of forwarded message from David Lesher ----- I'm glad you brought that up. Having contributed some questions myself, I was hoping to get some kind of feedback. I didn't expect transcripts of any top-secret meetings or anything, but the whole subject seems to have fallen into a black hole; we don't even know whether the meetings ever took place. If possible, it would be great to hear at least general reactions to at least some of the questions and issues we raised. John, did anything ever come of this? Do you have any info at all? --- mkj

3 2

Re: RC4
by rross＠sci.dixie.edu 17 Dec '03

17 Dec '03

>From: Alex Tang <altitude(a)umich.edu> >> I talked with RSA yesterday specifically about free servers and RC4. >> They just said that they would need a business plan for the >> server product. When i said that the product would be free, they started >> talking in circles about how everyone who uses RC4 needed a license (but i >> was asking about the licenses...) I asked flat out "how much would a >> license for RC4 cost for a free server product". They only reponded with >> "Very Expensive", and then went on about a business plan. > >Ask them about the free version of RC4 which is circulating. If they say >it is patented ask them for the patent number. Ask them why you should >pay them big bucks if you can get it for free. Here's their reply to a similar correspondence: >The RC4 algorithm is copyrighted by and intellectual property of RSA Data >Security. For use of this algorithm in a product or service you plan to >sell, you may use the RC4 software implementation from our BSAFE toolkit. >Licenses are not available for other commercial software implementations of >this algorithm other than what is included in our BSAFE toolkit. I wasn't aware that you could copyright an algorithm. Patent, yes, but not copyright. Intellectual property meens secret, right? Aren't there any precendence cases involving propriety schemes that are reverse engineered? I know there have been, I just can't remember what they are. In any case, RSADSI is likely to sue anyone who attempts to use the RC4 code openly, and even if they lose there are considerable legal fees involved for whoever tries it. What if a bunch of people put secure HTTPd servers online at the same time, without any clear trail pointing to the first one? If the RC4 code really is legal to use, this would make it hard for RSADSI to pinpoint anyone to sue, thus eliminating the intimidation factor. By the way, since RSA is such a vocal opponent of the Clipper chip on the grounds of its secret Skipjack algorithm, why does it market secret algorithms like RC4 and RC2? Does this seen like a double face to anyone else? ----------------------------------------------------------- Russell Ross email: rross(a)sci.dixie.edu 1260 N 1280 W voice: (801)628-8146 St. George, UT 84770-4953

4 3

Challenge-response passwords (Was: big word listing)
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

At 06:59 PM 7/25/95 +0100, Andrew Spring wrote: >Free-after-1997 example: > g is a generator of a prime p. > password is X (0<X<p); > password file has g^X mod p. > login server generates Y, issues challenge g^Y. > expected response is g^XY mod p > login client has X, generates (g^Y)^X = g^XY mod p. > J. Random SuperHacker can get g^X, and g^Y, but not g^XY. It's _not_ free after 1997! I thought of it last fall, was surprised I couldn't find it anywhere in the literature, given that it's pretty obvious, but eventually found that a guy from Siemens had patented it in Germany and then gotten a US patent in ~1994. Unfortunately, he phrased it in terms of "commutative hash functions", with g^X mod p as an example, so it's more general. He also extended it to do two-way authentication (obviously the process can be symmetrical if the user has a stored g^W from the server and can send a challenge, but he found a way to save a step or two.) I developed it because I was looking for a way to do authentication-only public key stuff so the code would be exportable - this approach doesn't generate a shared secret (since the otherwise-secret g^XT is exposed as the response to the challenge.) However, it's possible to extend it to preserve the shared secret - instead of sending response g^XY mod p, send Hash(g^XY mod p) and have the login server validate that. One advantage is that the hash can be much shorter than the whole g^XY mod p, e.g. 32-64 bits instead of 512-1024. And you can now use (g^XY mod p) as a session key (for encrypted sessions) or an authenticator (e.g. send Hash(Data,sequence#,sessionkey) as a MAC for each packet. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #--- # Export PGP three lines a time --> http://dcs.ex.ac.uk/~aba/export/ M0V]N9W)E<W,@<VAA;&P@;6%K92!N;R!L87<@+BXN(&%B<FED9VEN9R!T:&4@ M9G)E961O;2!O9B!S<&5E8V@L(&]R(&]F('1H92!P<F5S<SL-"F]R('1H92!R M:6=H="!O9B!T:&4@<&5O<&QE('!E86-E86)L>2!T;R!A<W-E;6)L92P@( T*

3 2

connectsoft & encryption
by Alan Pugh 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Date: Tuesday, 25-Jul-95 07:26 AM ConnectSoft Licensing Agreement with RSA Data Security Includes Revolutionary S/ MIME Technology; ConnectSoft's early BELLEVUE, WASH. (July 24) BUSINESS WIRE -July 24, 1995--ConnectSoft, Inc., provider of the most powerful, easy-to-use interfaces to digital communication and commerce, announced today it has licensed a new interoperable security technology from RSA that will provide ConnectSoft customers with added privacy and security to their daily communications. The agreement gives ConnectSoft products compliancy with the S/MIME specification (Secure Multipurpose Internet Mail Extension) that ensures a customer's e-mail is read only by the designated recipient -- regardless of the e-mail platform they are using. The new security features will be included in the newest versions of ConnectSoft's E-Mail Connection(tm) and Internet Connection(tm) products that will be released this fall. "In today's networked world, security is a growing concern as we rely on e-mail for more of our day-to-day communications," said Bob Dickinson, ConnectSoft's vice president and general manager, Consumer Online Products & Services division. "Our arrangement with RSA provides encryption and authentication technologies giving our customers the most protected and secure communication available today." The S/MIME specification is based on the popular Internet MIME standard and allows a customer's S/MIME message to be composed and encrypted on one vendor's system and be successfully received and decrypted on a different one. The specification also uses the intervendor PKCS (Public Key Cryptography Standards), the most widely implemented commercial standard for public-key cryptography in North America. Global Security Standard - ------------------------ Encryption and authentication have been viewed as crucial enabling technologies for electronic commerce on the World Wide Web -- but encryption has been slow to come to e-mail, with most packages offering nothing at all. "ConnectSoft's early support of S/MIME demonstrates its commitment to provide customers with secure digital communication as well as its sophistication in developing future electronic commerce solutions," said Jim Bidzos, RSA president. According to RSA, a global security standard is essential for the development of a global digital economy. "If one public-key system is used everywhere for authentication, then signed digital documents can be exchanged between users in different countries using different software on different platforms," Bidzos said. "This interoperability is necessary for a true digital economy to develop." RSA Data Security is the world's "brand name" for cryptography, with more than 12 million copies of its software encryption and authentication installed and in use worldwide. RSA is part of existing and proposed standards for the Internet, CCITT, ISO, ANSI, IEEE and business and financial networks around the globe. The company develops and markets platform-independent developers kits, end user products, and provides comprehensive cryptographic consulting services. Founded in 1982 by the inventors of the patented RSA Public Key Cryptosystem, the company is headquartered in Redwood City, California. ConnectSoft is a privately held company based in Bellevue, Wash. It was founded in January 1988 and operates three divisions -- Consumer Online Products and Services, Commercial Software Development Services and Commercial Network Services -- targeted at providing customers with innovative products, custom software and network services for conducting digital commerce. The Consumer Online Products division markets the company's award winning products, such as E-Mail Connection, Internet Connection and KidMail Connection. The Commercial Software Development Services division develops custom software which enables secure, digital communications, commercial transactions, and Integrated Logistics Systems for Fortune 1000 companies such as United Parcel Service (UPS). The recently formed Commercial Network Services division will provide high bandwidth, high-quality commercial Internet and TCP/IP services to large- and medium-sized companies throughout the United States. -0- E-Mail Connection and Internet Connection are registered trademarks of ConnectSoft, Inc. Other company, brand product and service names may be trademarks or registered marks of their respective holders. - --30--KS/se* CONTACT: Kaufer Miller Communications David Kaufer, Tamese Robinson or Michele Ruegg 206/450-9965 MCI Mail: 576-6983 OR ConnectSoft, Inc. Linda Coyle, 206/827-6467 Ext. 5409 Internet: lindacconnectsoft.com KEYWORD: WASHINGTON INDUSTRY KEYWORD: COMPUTERS/ELECTRONICS COMED PRODUCT INTERACTIVE/MULTIMEDIA REPEATS: New York 212-575-8822 or 800-221-2462; Boston 617-330-5311 or 800-225-2030; SF 415-986-4422 or 800-227-0845; LA 310-820-9473 BW URL: http://www.hnt.com/bizwire * * * END OF STORY * * * -----BEGIN PGP SIGNATURE----- Version: 2.61 iQEVAwUBMBYw0SgP1O9KJoPBAQEnbgf/Xh1RmNq+TRp0x/owRZuJOi/ThSanerkA O59761UffY+syiO9RNeM02imGIn32cvEO2c1ud/nwgIxiPdSeQK4LN41r2fu9xmu OCKgA9jjtMysiFyMYLaeyRXGfvlIoPatTZDQ4e153Gjq0iex2Ely5Ft+KYFgjA0g ysFKf5U7qMfV2nmVExxe7FM/Ou3MsT98E7V44A9auzEEPIqN1bnG/t8hzBgCdb01 U9ywG3HVKDUANSeWpFTLFMqi4inr67/XozXSYBcmyO7xS+pVw92svlrywIs9TVXw 8ejnOQs9pQyKp6M2XJzdIj5nZE7a8EXyBL9A3PBNPFBpztpUa+c5mA== =kOS6 -----END PGP SIGNATURE----- ********************************************* * / Only God can see the whole * * O[%\%\%{<>===========================- * * \ Mandlebrot Set at Once! * * amp * * <0003701548(a)mcimail.com> * * <alan.pugh(a)internetmci.com> * ********************************************* Key fingerprint = A7 97 70 0F E2 5B 95 7C DB 7C 2B BF 0F E1 69 1D

1 0

Re: RC4
by rross＠sci.dixie.edu 17 Dec '03

17 Dec '03

>From: Alex Tang <altitude(a)umich.edu> >> I talked with RSA yesterday specifically about free servers and RC4. >> They just said that they would need a business plan for the >> server product. When i said that the product would be free, they started >> talking in circles about how everyone who uses RC4 needed a license (but i >> was asking about the licenses...) I asked flat out "how much would a >> license for RC4 cost for a free server product". They only reponded with >> "Very Expensive", and then went on about a business plan. > >Ask them about the free version of RC4 which is circulating. If they say >it is patented ask them for the patent number. Ask them why you should >pay them big bucks if you can get it for free. Here's their reply to a similar correspondence: >The RC4 algorithm is copyrighted by and intellectual property of RSA Data >Security. For use of this algorithm in a product or service you plan to >sell, you may use the RC4 software implementation from our BSAFE toolkit. >Licenses are not available for other commercial software implementations of >this algorithm other than what is included in our BSAFE toolkit. I wasn't aware that you could copyright an algorithm. Patent, yes, but not copyright. Intellectual property meens secret, right? Aren't there any precendence cases involving propriety schemes that are reverse engineered? I know there have been, I just can't remember what they are. In any case, RSADSI is likely to sue anyone who attempts to use the RC4 code openly, and even if they lose there are considerable legal fees involved for whoever tries it. What if a bunch of people put secure HTTPd servers online at the same time, without any clear trail pointing to the first one? If the RC4 code really is legal to use, this would make it hard for RSADSI to pinpoint anyone to sue, thus eliminating the intimidation factor. By the way, since RSA is such a vocal opponent of the Clipper chip on the grounds of its secret Skipjack algorithm, why does it market secret algorithms like RC4 and RC2? Does this seen like a double face to anyone else? ----------------------------------------------------------- Russell Ross email: rross(a)sci.dixie.edu 1260 N 1280 W voice: (801)628-8146 St. George, UT 84770-4953

5 4

"grouplens": reputation system, groupware, etc.
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

Hello cpunks, this strikes me as a very visionary proposal for changing the underlying news infrastructure approach. It refers to the idea of "ratings servers" (it would be interesting to trace the origination of the term). I think the ideas are very malleable and may become a powerful force for future cyberspace communities. We are just now witnessing the birth of reputation systems in cyberspace. I think they will eventually become one of its most important features. For any cpunks with interests in investing your time in world-changing technologies, this would be at the top of *my* list. There are very difficult logistical problems to overcome, but this "second generation of communication" will IMHO be a key requirement of developing actual communities in cyberspace. ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^ \ / ~/ |\| | | |> | : : : : : : Vladimir Z. Nuri : : : : <vznuri(a)netcom.com> \/ ./_.| | \_/ |\ | : : : : : : ftp://ftp.netcom.com/pub/vz/vznuri/home.html X-within-URL: http://www-sloan.mit.edu/ccs/CCSWP165.html GROUPLENS: AN OPEN ARCHITECTURE FOR COLLABORATIVE FILTERING OF NETNEWS Paul Resnick*, Neophytos Iacovou**, Mitesh Suchak*, Peter Bergstrom**, John Riedl** * MIT Center for Coordination Science Room E53-325 50 Memorial Drive Cambridge, MA 02139 617-253-8694 Email: presnick(a)mit.edu ** University of Minnesota Department of Computer Science Minneapolis, Minnesota 55455 (612) 624-7372 Email: riedl(a)cs.umn.edu From Proceedings of ACM 1994 Conference on Computer Supported Cooperative Work, Chapel Hill, NC: Pages 175-186 Copyright ©1994, Association for Computing Machinery _________________________________________________________________ ABSTRACT Collaborative filters help people make choices based on the opinions of other people. GroupLens is a system for collaborative filtering of netnews, to help people find articles they will like in the huge stream of available articles. News reader clients display predicted scores and make it easy for users to rate articles after they read them. Rating servers, called Better Bit Bureaus, gather and disseminate the ratings. The rating servers predict scores based on the heuristic that people who agreed in the past will probably agree again. Users can protect their privacy by entering ratings under pseudonyms, without reducing the effectiveness of the score prediction. The entire architecture is open: alternative software for news clients and Better Bit Bureaus can be developed independently and can interoperate with the components we have developed. KEYWORDS: Collaborative filtering, information filtering, electronic bulletin boards, social filtering, Usenet, netnews, user model, selective dissemination of information. INTRODUCTION Computer networks allow the formation of interest groups that cross geographical barriers. Bulletin boards have been an important mechanism for that. Rather than addressing an article directly to a known set of people, the writer posts it in a newsgroup, a public place available to anyone interested in the topic. The Usenet netnews system creates the illusion of a single bulletin board available anywhere in the world. It propagates articles so that, with some delays, an article posted from anywhere in the world is available to everyone else. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. Recent counts indicate that there are more than 8000 newsgroups, with an average traffic of more than 100 MB per day[1]. The newsgroups carry announcements, questions, and discussions. In a discussion, often called a thread, one article induces replies from several others, each of which may also induce replies. The January 24, 1994 estimates of netnews participation indicate that more than 140,000 people posted articles in the previous two weeks. There are many more "lurkers" who read but do not post articles. Clearly, a lot of people are getting value from these bulletin boards. In fact, netnews' rapid broadcast nature and widespread readership has reshaped the way the computing community works. System administrators depend on netnews to keep in touch with the latest development work, the latest security holes, and the latest bug fixes. Researchers depend on netnews as a way of keeping up-to-date on new research directions and important results in between conferences. Many others use netnews just to keep in touch with other people around the world, to learn about new books, new recipes, new music, and what life in other cities is like. Over the years netnews has become a principal medium for sharing among computer users. Even so, the experience of using netnews is not completely satisfying. Almost everyone complains that the signal to noise ratio is too low. Writers cannot easily tell whether their comments are valued, except by the vocal few who post responses. Some seem not to care about reader interest, only about their own right to write. Moreover, tastes differ, so that no one article will appeal to all the readers of a newsgroup. Each reader ends up sifting through many news articles to find a few valuable ones. Often, readers find the process too frustrating and stop reading netnews altogether. Netnews provides two mechanisms that help readers limit their attention to articles likely to interest them. First, the division of the bulletin board into newsgroups allows readers to focus on a few topics. When the number of postings in a newsgroup gets too large, it is often split into two or more newsgroups with identifiable subtopics. Second, some newsgroups are moderated. Attempted postings to these newsgroups are automatically forwarded to the moderator, who decides whether or not they belong in the newsgroup. Usenet propagates only those articles that receive the moderator's stamp of approval. In addition, software packages for reading netnews (hereafter referred to as news clients) provide other mechanisms that ease readers' burdens. First, most news clients display a summary of the author and subject line for each message in a newsgroup. The user then indicates which articles she would like to read. Second, most news clients display all of the articles in a particular discussion thread together. Some initially show only the first article in each thread, allowing users to quickly peruse the current discussion topics. Third, some news clients provide "kill files." A kill file identifies text strings that are not interesting to a particular user. If a user puts the subject line of an article into the kill file, no further articles on that subject will be displayed. If a user puts the author's name into a kill file, no further articles from that author will be displayed. Finally, some news readers provide string search facilities. If the user is particularly interested in articles that mention "collaborative filtering," the news client can find them. GroupLens provides a new mechanism to help focus attention on interesting articles. It draws on a deceptively simple idea: people who agreed in their subjective evaluation of past articles are likely to agree again in the future. After reading articles, users assign them numeric ratings. GroupLens uses the ratings in two ways. First, it correlates the ratings in order to determine which users' ratings are most similar to each other. Second, it predicts how well users will like new articles, based on ratings from similar users. The heart of GroupLens is an open architecture that includes news clients for entry of ratings and display of predictions, and rating servers for distribution of ratings and delivery of predictions. Related Work The general problems of information overload and low signal to noise ratio have received considerable attention in the research literature. We use the term information filtering generically to refer both to finding desired information (filtering in) and eliminating that which is undesirable (filtering out), but related work also appears under the labels of information retrieval and selective dissemination of information [2]. In addition, research on agents [12, 13], user modeling [1, 9], knowbots [8], and mediators [21] has explored semi-autonomous computer programs that perform information filtering on behalf of a user. Malone et al. [13] describe three categories of filtering techniques, cognitive, social, and economic, based on the information sources the techniques draw on in order to predict a user's reaction to an article. The three categories provide a useful road map to the literature. Cognitive, or content-based filtering techniques select documents based on the text in them. For example, the kill files and string search features provided by news clients perform content filtering. Even the division of netnews into newsgroups is a primitive example, since a reader restricts his attention to those articles with a particular text string in their "newsgroup:" field. Other content-based filtering techniques could potentially be used as well. The profile of which texts to include or kill could be more complex than a collection of character strings. For example, strings could be combined with the Boolean operators AND, OR, and NOT. Alternatively, the profile could consist of weight vectors, with the weights expressing the relative importance of each of a set of terms [4, 5, 16]. Some content filtering techniques update the profiles automatically based on feedback about whether the user likes the articles that the current profile selects. Information retrieval research refers to this process as relevance feedback [17]. The techniques for updating can draw on Bayesian probability [2], genetic algorithms [18], or other machine learning techniques. Social filtering techniques select articles based on relationships between people and on their subjective judgments. Placing an author's name in a kill file is a crude example. More sophisticated techniques might also filter out articles from people who previously co-authored papers with the objectionable person. Collaborative filtering, based on the subjective evaluations of other readers, is an even more promising form of social filtering. Human readers do not share computers' difficulties with synonymy, polysemy, and context when judging the relevance of text. Moreover, people can judge texts on other dimensions such as quality, authoritativeness, or respectfulness. A moderated newsgroup employs a primitive form of collaborative filtering, choosing articles for all potential readers based on evaluations by a single person, the moderator. The Tapestry system [6] makes more sophisticated use of subjective evaluations. Though it was not designed to work specifically with netnews, it allows filtering of all incoming information streams, including netnews. Many people can post evaluations, not just a single moderator, and readers can choose which evaluators to pay attention to. The evaluations can contain text, not just binary accept/reject recommendations. Moreover, filters can combine content-based criteria and subjective evaluations. For example, a reader could request articles containing the word "CSCW" that Joe has evaluated and where the evaluation contains the word, "excellent". Our work is similar in spirit to Tapestry but extends it in two ways. First, Tapestry is a monolithic system designed to share evaluations within a single site. We share ratings between sites and our architecture is open to the creation of new news clients and rating servers that would use the evaluations in different ways. Second, Tapestry does not include any aggregate queries. The rating servers we have implemented aggregate ratings from several evaluators, based on correlation of their past ratings. A reader need not know in advance whose evaluations to use and in fact need not even know whose evaluations are actually used. In GroupLens, ratings entered under a pseudonym are just as useful as those that are signed. Maltz has developed a system that aggregates all ratings of each netnews article, determining a single score for each [14]. By contrast, GroupLens customizes score prediction to each user, thus accommodating differing interests and tastes. In return for its reduced functionality, Maltz's scheme scales better than ours, because rating servers can exchange summaries of several users' ratings of an article, rather than individual ratings. The subjective evaluations used in collaborative filtering may be implicit rather than explicit. Read Wear and Edit Wear [7] guide users based on other users' interactions with an artifact. The GroupLens news clients monitor how long users spend reading each article but our rating servers do not yet use that information when predicting scores. Economic filtering techniques select articles based on the costs and benefits of producing and reading them. For example, Malone argues that mass mailings have a low production cost per addressee and should therefore be given lower priority. Applying this idea to netnews, a news client might filter out articles that had been cross-posted to several newsgroups. More radical schemes could provide payments (in real money or reputation points) to readers to consider articles and payments to producers based on how much the readers liked the articles. Stodolsky has proposed a scheme that combines social and economic filtering techniques [19]. He proposes on-line publications where the publication decision ultimately rests with the author. During a preliminary publication period, other readers may post ratings of the article. The author may then withdraw the article, to avoid the cost to his reputation of publishing an article that is disliked. Outline The GROUPLENS section of the paper describes the GroupLens architecture and its evolution. The ONGOING EXPERIMENTATION section describes a larger scale test of the architecture that is in preparation. The SOCIAL IMPLICATIONS section addresses social changes in the use of Netnews that may be precipitated by GroupLens. GROUPLENS GroupLens is a distributed system for gathering, disseminating, and using ratings from some users to predict other users' interest in articles. It includes news reading clients for both Macintosh and Unix computers, as well as "Better Bit Bureaus," servers that gather ratings and make predictions. Both the overall architecture and particular components have evolved through iterative design and pilot testing to meet the following goals: Openness: There are currently dozens of news clients in common use, each with a strong following among its user community. Any or all of these clients can be adapted to participate in GroupLens. GroupLens also allows for the creation of alternative Better Bit Bureaus that use ratings in different ways to predict user interest in news articles. Ease of Use: Ratings are easy to form and communicate, and predictions are easy to recognize and interpret. This minimizes the additional burden that collaborative filtering places on users. Compatibility: The architecture is compatible with existing news mechanisms. Compatibility reduces user overhead in taking advantage of the new tool, and simplifies its introduction into netnews. Scalability: As the number of users grows, the quality of predictions should improve and the speed not deteriorate. One potential limit to growth will be transport and storage of the ratings, if GroupLens grows very large. Privacy: Some users would prefer not to have others know what kinds of articles they read and what kinds they like. The Better Bit Bureaus in GroupLens can make effective use of ratings even if they are provided under a pseudonym. Overview Usenet consists of Internet sites as well as UUCP sites. Typically a site will declare a machine to act as its news server. Users at each site invoke news clients on their computers and connect to the news server in order to retrieve news articles. Users can also write new articles and post them to the news server through their news clients. When a user posts an article, it travels from the news client where the article is composed to the local news server and from there to news servers at nearby sites. After leaving the originating site, an article propagates throughout Usenet, hopping from site to site. Since there is no centralized coordination of the distribution process, an article may arrive at a site via more than one route. Because articles have globally unique identifiers, however, and are never altered once they are posted, any site can recognize a duplicate copy of an article and avoid passing it on. Lotus Notes uses a similar distribution process [10]. The netnews architecture is summarized in Figure 1. GroupLens adds one new type of entity to the netnews architecture, Better Bit Bureaus, as shown in Figure 2. The Better Bit Bureaus provide scores that predict how much the user will like articles, and gather ratings from news clients after the user reads the articles. The Better Bit Bureaus also use special newsgroups to share ratings with each other, to allow collaborative filtering among users at different sites. The remainder of this section traces the processes of rating creation, distribution, and use and describes how they meet [IMAGE] Figure 1: The netnews architecture. News articles hop from news server to news server. A news client connects to the news server at its site and presents articles to users. [INLINE] Figure 2: The GroupLens architecture. Better Bit Bureaus collect ratings from clients, communicate them by way of news servers, and use them to generate numeric score predictions that they send to clients. Clients connect to a local news server, and can connect to a Better Bit Bureau that uses the same or a different news server.the design goals of openness, ease of use, compatibility, scalability, and privacy. Entering Ratings In GroupLens, a rating is a number from 1 to 5, optionally supplemented by the number of seconds which the user spent reading the article. Users are encouraged to assign ratings based on how much they liked the article, with 5 highest and 1 lowest. The user chooses a pseudonym to associate with her ratings that may be different from the name she uses for posting news articles. This preserves the ability to detect that two ratings came from the same person, while preventing detection of exactly who that person is. The GroupLens choice of the form and meaning of ratings is only one possibility in a rich design space. There are many possible dimensions along which to rate articles: interest in subject, quality of writing, authoritativeness of the author, etc. Rather than a single composite rating, separate ratings on several dimensions could be solicited from readers. Free text ratings could be entered rather than numbers. Readers could be asked to predict how well they think other readers will like an article rather than report how much they themselves liked it. Ratings could be restricted only to positive, or only to negative evaluations. The degree of privacy could also be varied, from completely anonymous to authenticated signatures. In fact, an earlier implementation of a Macintosh news client [20] employed ratings with quite a different form than the current GroupLens architecture. Users entered only endorsements, positive ratings, on the assumption that since the signal to noise ratio in netnews is so low it is only important to point out the good articles. Readers endorsed articles that they thought others in a known small group would like. Finally, readers signed endorsements with their real names, allowing other people to select all the articles endorsed by a particular friend. A pilot test of that earlier endorsement mechanism at a Schlumberger research lab indicated that a group of seven people may not be large enough to get the full available benefit of collaborative filtering. As we contemplated a much larger group size, we believed that some users would be less willing to sign their ratings and that it would become increasingly difficult for users to know what articles others in the group would like. The pilot test also reinforced the importance of making it as easy as possible to enter endorsements. To make an endorsement, a user had to select from a pull-down menu, wait for a window to open up, optionally enter text in the window, and then close it. While the whole process took only a matter of seconds if the user entered no text, it was still significantly longer than it normally takes to go on to the next article. We have taken care in the GroupLens system to make entry of ratings as easy as possible. We have modified three news clients, Emacs Gnus and NN for UNIX machines and NewsWatcher for Macintoshes. In each case, entry of a [IMAGE] Figure 3. Reading an article with the modified NewsWatcher client. The user can click on one of the five ratings buttons with the mouse, or type a number from 1 to 5 on the keyboard. rating fits into the overall paradigm of the news client. For example, in the modified NewsWatcher, the numbers 1 to 5 appear as selectable buttons any time a user reads an article (Figure 3), and the user can also type a number as a keyboard shortcut for those buttons. In Gnus, no buttons are displayed, but readers still type the ratings directly. With NN, readers first type the letter `v' (to enter into "rating mode") and then the rating. The GroupLens architecture requires only that ratings be reported on a 1 to 5 scale, not that they be displayed by news clients on that scale. To make the rating scale easy for students to understand, the NN and Gnus clients accept letter grades rather than numbers. When reporting the ratings to the Better Bit Bureau, they translate `a' to 5, `b' to 4 and so on. Other news clients could allow more gradations of ratings (e.g., 1 to 100) and report them as fractions between 1 and 5. Distributing Ratings GroupLens does not interfere with the Usenet propagation scheme at all. On the contrary, it relies upon it heavily. The Better Bit Bureau packages one or more ratings into a news article, following the format in Figure 4, and posts it to a news server. This allows GroupLens to take advantage of the Usenet propagation scheme. Over the years Usenet has demonstrated its ability to propagate articles to every other Usenet site, even as the number of news servers has grown dramatically. Rating servers could exchange ratings directly, through internet or UUCP links, but they would have to reimplement many of the propagation features already found in Usenet. The message format we have defined allows several ratings to be batched in a single article. Each rating is just one line of text, while each Usenet netnews article requires several lines of headers. Thus, packaging several ratings in one article can save a considerable amount of overhead. Our Better Bit Bureaus (BBBs) batch at the session level (i.e., all ratings entered by a user during a reading session go into one ratings article). Other batching policies, such as all ratings from a site over the last hour, could be implemented. Ratings are posted in newsgroups dedicated solely to ratings articles. One natural configuration is to set up a parallel "ratings transport" newsgroup for each "normal" Usenet group. One deficiency of this approach is that if a rating article contains several ratings, it may have to be cross-posted to many ratings newsgroups. Another deficiency is that it requires news servers to carry a large number of new newsgroups devoted solely to ratings, which may increase administrative overhead. Currently, our BBBs post all ratings in a single newsgroup. To facilitate the initial spread of GroupLens, users can participate even if their local news servers do not carry the ratings newsgroup and even if their local site administrators have not set up Better Bit Bureaus. The GroupLens architecture permits this by allowing users to connect to a remote BBB. The left side of Figure 2 illustrates a local BBB that posts ratings articles to the same news server that the clients connect to. The right side of Figure 2 illustrates a client connecting to a remote BBB that propagates ratings articles through a different news server. Predicting Scores The Better Bit Bureaus (BBBs) predict how much readers will like articles. While content filters would make predictions based on the presence or absence of words in the articles, the BBBs in GroupLens use the opinions of other people who have already rated the articles. If no one has read an article, the BBBs are unable to make predictions about it. When ratings for an article are available, they are unlikely to be uniform, due to differences of opinion and goals among the raters. A BBB combines the different ratings to produce a predicted score. Moreover, additional readers are likely to have different opinions about the article. A BBB thus might use the same ratings to predict different scores for different readers, by changing the relative weight given to the ratings. When predictions are on the same scale as ratings, prediction can be modeled as matrix filling, where the columns are people, the rows are articles, and the cells contain the ratings that people have posted, as shown in Figure 5. Many of the cells of the matrix are empty, because readers have not yet examined those articles or have elected not to rate them. A BBB predicts scores for missing cells before the readers examine the corresponding articles. From: MIT GroupLens Better Bit Bureau Subject: Ratings; please ignore Message-ID: <771185369(a)guilder.mit.edu> Groups_Rated: news.adin.policy, news.groups Raters: [Pseudo1] <MATT.94May19124319(a)physics5.berkeley.edu> [Pseudo1] 1 12 news.adin.policy <fred_sCq2FF6.Mtt(a)netcom.com> [Pseudo1] 2 7 news.groups Figure 4: A sample ratings article. Each line in the body of the article contains a rating of one article by one person. The five fields on each line are the id of the article, the pseudonym of the rater, a rating, the number of seconds the reader spent examining the article before rating it, and the newsgroups the article is in. The time count is optional. Additional keyword identified fields can also be included at the end of line. [IMAGE] Figure 5: a sample matrix of ratings. All the scoring methods we have implemented are based on the heuristic that people who agreed in the past are likely to agree again, at least on articles in the same newsgroup. This heuristic will mislead on occasion, but preferences for most kinds of articles are likely to be fairly stable over time. To implement this heuristic, our BBBs first correlate ratings on previous articles to determine weights to assign to each of the other people when making predictions for one of them. Then, they use the weights to combine the ratings that are available for the current article. We have investigated several techniques for correlating past behavior and using the resultant weights, based on reinforcement learning [12], multivariate regression, and pairwise correlation coefficients that minimize linear error or squared error. We illustrate one of the correlation and prediction techniques by computing Ken's predicted score on article 6, the last row of the matrix. First, we compute correlation coefficients [15], weights between -1 and 1 that indicate how much Ken tended to agree with each of the others on those articles that they both rated. For example, Ken's correlation coefficient with Lee is computed as: [IMAGE] In the formula above, [INLINE] is the average of Ken's ratings. All the summations and averages in the formula are computed only over those articles that Ken and Lee both rated. We have conveniently arranged for [INLINE] and [INLINE] to be 3 in this example, but that need not be true in practice. Similarly, Ken's correlation coefficient with Meg is +1 and with Nan is 0. That is, Ken tends to disagree with Lee ( [INLINE] ) and agree with Meg ( [INLINE] ). His ratings are not correlated with Nan's. To predict Ken's score on the last article in the matrix, take a weighted average of all the ratings on article 6 according to the following formula: [IMAGE] This is a reasonable prediction for Ken, since the article received a high rating from someone who agreed with him in the past and a low rating from someone who disagreed. Carrying through similar calculations for Nan yields a lower prediction of 3.75. Since Nan had partial agreement with Lee in the past, Lee's low rating for the article partially cancels out the high ratings that Meg gave it. The score prediction system is robust with respect to certain differences of interpretation of the rating scale. If two users are perfectly correlated, but one user gives only scores between 3 and 5 and the other only scores between 1 and 3, a 5 score from the first user will result in a prediction of 3 for the second. If two users would be perfectly correlated, but the first mistakenly thinks 1 is a good score and 5 is bad, the two will be negatively correlated and a 1 score from the first will result in a prediction of 5 for the second. This leads to a clear explanation to the user of how to assign ratings: assign the rating you wish GroupLens had predicted for this article. Allen's study of five subjects' preferences for newswire articles [1] found very small correlations between subjects, thus calling into question our basic assumption that people who agreed in the past are likely to agree again. It may be, however, that a larger sample of subjects would have yielded some pairs with larger overlaps in their ratings. More importantly, it may be that pairs of people will share interests in some topics but not others. Two people may agree in their evaluations of technical articles, but not jokes. Our BBBs keep separate rating matrices for each newsgroup. One hopes that the accuracy of the predictions improve as the BBB has more past ratings to use in computing correlations. Four people at the University of Minnesota participated in a pilot test of an earlier version, using a slightly different scoring function. While all four participants reported that the predicted scores eventually matched their interests fairly closely, they did observe that there was a start-up interval before the predictions were very useful. Further experiments and analysis are necessary to determine just how long the start-up interval is likely to be for each new user. It seems likely that better scoring mechanisms can be developed. In addition to better matrix filling techniques, it may be helpful to use both others' ratings and the contents of articles in making predictions. It may also be helpful to take into account the time people spent reading articles before rating them, information collected but not used by our BBBs. Fortunately, the GroupLens architecture is open: anyone can implement an alternative BBB so long as it posts ratings articles in the format described above and communicates with clients the same way that our BBBs do. We hope that the development of alternative BBBs will become an active area for future research. As we describe below, our next pilot test should yield rating sets that we will make available to others who wish to evaluate alternative scoring algorithms. Using Ratings It is up to the news client how best to use the scores generated by a BBB. Some may filter out those articles with scores below a threshold. Some may sort the articles based on the scores. Others may simply display the scores, numerically or graphically. In keeping with the ease of use design goal, developers should modify each news client in a manner consistent with that client's overall design. One trend in news clients is to display a summary of the unread articles in a newsgroup. Each line of the summary contains information about one article, typically the author, the subject line and the length. A user browses the summary and requests display of the full text of those articles that seem interesting. All three of the news clients we modified use this display technique. The three modified clients we implemented make slightly different uses of the scores in the summary display. The modified NN client displays articles in the same order a regular NN client does, namely the order in which the articles arrived at the news server. It merely adds an additional column containing the predicted scores. In the first version of this client, the scores were displayed numerically. The modified Gnus client uses the predicted scores to alter the order of presentation of articles in the summary. Gnus clusters articles by thread. The modified Gnus client sorts the threads based on the maximum predicted score over the articles in the thread. Within each thread, however, articles are still displayed in chronological order, to preserve the flow of discussion. As in the modified NN, the scores are displayed in an additional column in the summary. The Minnesota pilot test included users of both the Gnus and NN clients. As expected, participants tended to believe that the sorting and display mechanisms of their own news reader were best, but all were glad to see the score predictions incorporated into that standard format. Several users, however, noticed that it was somewhat difficult to visually scan the predictions to find the high ones. A revised version of the NN client (Figure 6) rounds off to the nearest integer and reports that as a letter grade (A-E), a scale familiar to students at U.S. Universities. The modified NewsWatcher client displays the predicted scores as bar graphs rather than numbers (Figure 7), making it easier to visually scan for articles with high scores (longer bars). Otherwise, it follows the conventions of the original NewsWatcher client. Articles are grouped into threads and the summary display initially shows header lines only for the first article in each thread. Users can twist down the triangle associated with a thread to see the header lines for the rest of the articles. [IMAGE] Figure 6: The modified NN client. The third column displays the number of lines in the article. The fourth column displays the score predictions as letter grades, translated from the numeric predictions that the Better Bit Bureau makes (5=A, 4=B, etc.). When no one has evaluated an article, no prediction is made. [IMAGE] Figure 7: The modified NewsWatcher client displays predicted scores as bar graphs. Disclaimer: the scores were randomly generated for demonstration purposes. In practice, we would expect articles by Pete Bergstrom (one of the authors of this paper) to have much higher predicted scores. Scale Issues Further research is needed to understand how performance will change as the scale increases. In the case of GroupLens, there are several relevant performance measures: prediction quality, user time, Better Bit Bureau compute time and disk storage, and network traffic. The first measure is the quality of score predictions. We expect prediction quality to increase as the number of users increases, since more data will be available to the prediction algorithm. Another measure is how long users have to wait to post ratings and receive predictions. In an earlier version of GroupLens, the functions of the BBB were incorporated in the news client itself. One major advantage of the separate BBB is that it can pre-fetch ratings and pre-compute predictions rather than computing them when the user starts the news client. Thus, user time should remain roughly constant as GroupLens grows, even if it takes more CPU time to compute scores. For many possible prediction formulas CPU time will grow even faster than linearly with increases in the number of users. To reduce CPU time, BBBs could use only a part of the ratings matrix, trading off compute time against quality of predictions. Even though each rating is short, each news article might be read and rated by many raters, so the total volume of ratings could exceed the volume of news. To minimize storage requirements, BBBs may employ algorithms that use and discard ratings as they arrive, rather than storing them. Three basic techniques could reduce network traffic: reduce the size of the ratings, reduce the number of ratings, and reduce the number of places where each rating is sent. Our BBBs batch several ratings in a single article, a first step toward reducing the amount of storage per rating, but further compression is possible. The number of ratings could be reduced by limiting the total number of ratings per article or the number of ratings from users with similar profiles. The separation of the BBBs from the news clients in the GroupLens architecture reduces the number of destinations for each rating: each news client receives only score predictions rather than all the individual ratings that contribute to those predictions. The number of destinations for each rating could be further reduced by sending ratings to some BBBs but not others. For example, BBBs could be clustered, based on geography or interest, and exchange ratings only within clusters. The size of each cluster must be small enough to limit the amount of ratings information distributed, but large enough to provide an effective peer group. The table below estimates daily network traffic for various cluster sizes assuming each user rates 100 articles per day and each rating requires approximately 100 bytes. For comparison purposes, the current netnews traffic is around 100MB per day. Cluster size Daily ratings traffic 100 users 1 MB 10,000 users 100 MB 1,000,000 users 10 GB Summary of GroupLens Architecture The heart of GroupLens is an open architecture for distributing ratings. The architecture specifies the format of ratings produced in batches by BBBs, the propagation of the ratings by Usenet, and the interface for delivering predictions and ratings between news clients and BBBs. Otherwise, the architecture is completely open. BBBs and news clients can be freely substituted, providing an environment for experimentation in predicting ratings and in user interfaces for collecting ratings and presenting predictions. ONGOING EXPERIMENTATION Both of the previous pilot tests, at Schlumberger and the University of Minnesota, involved only local sharing of ratings. These tests led to improvements in both the overall architecture and the user interfaces of news clients, as discussed already. The next step is a larger scale, distributed test, that we plan to carry out this summer. We have established a newsgroup on the news servers at MIT and Minnesota and two (slightly different) Better Bit Bureaus that communicate ratings through that newsgroup. The test is not designed to demonstrate that people prefer to read netnews with our collaborative filters than without them. We believe that such an evaluation should wait for at least one more iterative design cycle. Rather, the goals are to identify any unexpected scaling issues that may arise and to gather a data set that will be useful in evaluating alternative score prediction algorithms. The primary benchmark of any algorithm's effectiveness will be its ability to predict values that have been deleted from a rating matrix. At first glance, it might seem that any large set of ratings would be useful in creating such a benchmark. Upon closer inspection, however, complete ratings matrices are much more valuable than sparse ones. For example, suppose that users read and rate only a small number of articles, based on score predictions they receive from BBB X. If users read different articles, this generates a sparse matrix of ratings. Now suppose that we wish to compare X to an alternative, Y, that predicts different scores for the users. We can compare Y's and X's predictions on those articles that users read, but the sample is biased. Perhaps with Y's scores, the users would have read other articles and liked them. To allow unbiased comparisons, we are asking each of the participants in the next pilot test to read and rate all the articles in a training set. The training set will contain a number of articles from each of the newsgroups that will be included in the test. Since users will contribute ratings under a pseudonym, we will be able to share the ratings in this training set with other researchers. In addition, we will retain the full texts of the articles in the training set. That will enable evaluation of BBBs that perform content filtering, or a combination of content filtering and collaborative filtering, as well as those that use only other users' ratings. SOCIAL IMPLICATIONS Collaborative filtering may introduce many social changes in the already rapidly evolving Netnews community. For example, the utility of moderated newsgroups may decline. New social patterns will have to develop to encourage socially beneficial behaviors, such as reviewing articles that have already received a few low ratings. Finally, if GroupLens is effective at creating peer groups with shared interests, will those peer groups be permeable or will the global village fracture into tribes? Changes to Netnews Behaviors GroupLens has the potential to change Netnews as we now know it. For one thing the quality of articles individual users choose to read should increase. More significantly, as more and more users rely on GroupLens the total number of low-quality articles on Usenet may decrease significantly. Since few people will read such articles, the incentive to post them will decrease. GroupLens may also supplant or supplement other established Netnews behaviors. Moderated Newsgroups GroupLens may reduce the need for moderated newsgroups. The advantages of GroupLens over the existing approach are that "moderators" can be groups of people as well as individuals, and that each user can rely on a different moderator rather than having a single moderator for the entire group. Some newsgroups might choose to use both a moderator and GroupLens. The moderator of a newsgroup will make the initial pass through the article submissions. Peer ratings would then allow further filtering. Newsgroup Splits Currently, newsgroups start off with broad topics and split into narrower topics as traffic increases. For example, the newsgroup rec.sport.football eventually split into the subgroups australian, canadian, rugby, pro, college, fantasy, misc, and one for each team in the NFL. These splits are a form of content filtering, initiated and managed by the users. GroupLens users may find that many such splits are less important, and in some cases undesirable. Over the course of time users will find themselves reading only the subset of the newsgroup they are most interested in, as they correlate with a peer group with similar interests. Splits of interest between groups of users will appear naturally, with no additional user or administrative effort. Allowing the splits to happen through GroupLens rather than through explicit content filtering allows more cross-pollination of general interest articles. For instance, interesting articles posted by Bills fans about an upcoming football game against the Cowboys would also reach Cowboys fans with GroupLens, but would not if the articles were posted in the more specialized newsgroup rec.sport.football.bills. Kill-Files Kill files are a content filtering mechanism implemented in some news clients. Many users who strongly dislike particular subjects or particular authors, however, do not use kill files because they find the mechanism complicated and cumbersome. GroupLens might be an easier means to the same end. A user's peer group will give such articles low ratings, so only a few users will have to read them. Incentives Individuals put additional effort, albeit a modest amount, into providing ratings through GroupLens. These ratings provide benefit to other users who can use them to select interesting articles. It's a two-way street: everyone can be both a producer and a consumer of ratings. When someone reads and rates an article, there is an incentive to provide honest ratings, because dishonest ratings will cause the BBB to make poor future predictions for that user. On the other hand, there is no incentive to rate articles at all. On the contrary, there is an incentive to wait for others' ratings rather than read and rate an article oneself. A certain amount of altruism or guilt may cause most people to "do their share" of rating, but fewer than the socially optimal number of ratings are likely to be produced. The four-person Minnesota pilot test included a high-volume newsgroup, rec.arts.movies. The volume of articles was so high that each participant was unwilling to read a one-quarter share of the total daily volume. The newsgroup was quickly dropped from the test. It may be that a larger user population would generate ratings even for a high-volume list such as rec.arts.movies, but it is harder to draw on a "do-your-share" mentality when collaborating with larger groups of people. There are other, more subtle incentive problems that can arise as well. For example, there is an asymmetry between the effects of positive and negative ratings. If the first few readers rate an article too highly, others will read the article and give it lower ratings. On the other hand, if the first few ratings of an article are negative, others who would have rated it highly may never look at it because of the initial negative rating. To avoid this, it may be necessary to provide external incentives to some people to read and rate articles that have initially low ratings. The external incentives could be money, fame, or simply access to others' ratings: those who did not contribute their share of ratings might be denied access to the Better Bit Bureau's predictions. Global Villages Present newsgroups, like newspapers and local television shows before them, provide a shared history for their community of readers. With GroupLens, users may choose to read articles only from a small group with whom they share many common interests. Over time this could lead to a fracture of the global village into many small tribes, each forming a virtual community but nonetheless isolated from each other. Some kind of fracture is inevitable and even desirable, because no user can keep up with the overwhelming volume of news produced each day. The question is whether the subgroups will be closed or permeable. One argument for prognosticating permeability is that many groups will form for a short time and then disband [3]. Another is that many users will participate in several subgroups, providing a mechanism for the best ideas to cross boundaries of interest groups. CONCLUSION Shared evaluations are useful in all sorts of activities. We ask friends, colleagues, and professional reviewers for their opinions about books, movies, journal articles, cars, schools, and neighborhoods. Clearly, some form of shared evaluations should also help in filtering electronic information streams such as netnews. It is not yet clear exactly what form those evaluations should take, how they should be collected and disseminated, and how they should be used in selecting articles to read. GroupLens is one promising approach. A single number gives a composite rating of an article on all dimensions relevant to a particular reader. We have modified three news reading clients to enable easy entry of such numeric ratings. We have also modified the way that the clients display subject lines to include predicted scores based on others' ratings. Naturally, there will be differences of opinion among readers about particular articles, due to varying interests or quality assessments. To accommodate differences of opinion, not all readers will place equal trust in particular evaluators. The algorithms we have implemented automatically determine how much weight to place on each evaluation, based on the degree of correlation between past opinions of the reader and evaluator. This has the beneficial side effects that readers need not know initially whose evaluations to trust and the evaluators' opinions can become trusted even if the evaluators choose to remain anonymous. The GroupLens architecture allows new users to connect and new rating servers to come on line, without global coordination. A new user need only use a modified news client and have a connection to a rating server. The user need not convince the administrator of her netnews server to modify the news server, run any additional software, or even to carry any additional newsgroups. A new rating server needs only to get access to a news server that carries the ratings newsgroups. Moreover, the architecture is open. Anyone who wishes to can modify a news client to allow entry of evaluations or to use predicted scores, so long as the client follows the protocol we have established for communicating with the rating server. Anyone who wishes to improve on the score predictions that our rating servers make can do so. There may be better ways to correlate past evaluations. There may also be ways to use the evaluations in conjunction with content filtering. For example, when correlating past evaluations, the scoring algorithm might consider evaluations only of past articles that are somehow similar to the current one. Our next pilot test should yield a data set that can be used for evaluating alternative prediction methods. Only further testing can reveal whether GroupLens gathers the right kind of evaluations and uses them in ways that people like. If the simple numeric evaluations turn out to be sufficient, the architecture will scale up to large numbers of rating servers and users. If not, then data from our tests will help develop and evaluate other mechanisms for sharing and using evaluations. Right now, people read news articles and react to them, but those reactions are wasted. GroupLens is a first step toward mining this hidden resource. ACKNOWLEDGMENTS Shumpei Kumon's keynote address at CSCW 92 [11] inspired our investigation of the practical application of reputations to social filtering. Thanks to Lorin Hitt and Carl Feynman for helpful discussions about how to predict scores based on past correlations. Peter Foltz and Sue Dumais generously provided a test rating set generated from one of their experiments on content filtering [5]. Thanks also to Chris Avery, Joe Adler, Yannis Bakos, Erik Brynjolfsson, David Goldberg, Bill MacGregor, Tom Malone, David Maltz, Vahid Mashayekhi, Lisa Spears, Doug Terry, Mark Uhrmacher, and Zbigniew Wieckowski. REFERENCES 1. Allen, R.B. User Models: Theory, Method, and Practice. International Journal of Man-Machine Studies, 32, (1990), pp. 511-543. 2. Belkin, N.J. and Croft, B.W. Information Filtering and Information Retrieval: Two Sides of the Same Coin? CACM, 35, 12 (1992), pp. 29-38. 3. Brothers, L., Hollan, J., Nielsen, J., Stornetta, S., Abney, S., Furnas, G. and Littman, M. Supporting Informal Communication via Ephemeral Interest Groups. In Proceedings of CSCW 92 (1992, New York: ACM), pp. 84-90. 4. Deerwester, S., Dumais, S.T., Furnas, G.W., Landauer, T.K. and Harshman, R. Indexing by Latent Semantic Analysis. Journal of the American Society for Information Science, 41, 6 (1990), pp. 391-407. 5. Foltz, P.W. and Dumais, S.T. Personalized Information Delivery: An Analysis of Information Filtering Methods. Communications of the ACM, 35, 12 (1992), pp. 51-60. 6. Goldberg, D., Nichols, D., Oki, B.M. and Terry, D. Using Collaborative Filtering to Weave an Information Tapestry. Communications of the ACM, 35, 12 (1992), pp. 61-70. 7. Hill, W.C., Hollan, J.D., Wroblewski, D. and McCandless, T. Edit Wear and Read Wear. In Proceedings of CHI 92 Conference on Human Factors in Computing Systems (1992, New York: ACM), pp. 3-9. 8. Kahn, R.E. and Cerf, V.G. The Digital Library Project, Volume 1: The Wold of Knowbots. An Open Architecture for a Digital Library System and a Plan for Its Development . CNRI, 1895 Preston White Drive, Suite 100, Reston, VA 22091 Tech Report (March, 1988). 9. Karlgren, J. Newsgroup Clustering Based on User Behavior-- A Recommendation Algebra . Swedish Institute of Computer Science #SICS-T--94/04-SE (March, 1994). 10. Kawell, L.J., Beckhardt, S., Halvorsen, T. and Ozzie, R. Replicated Document Management in a Group Communication System. In Proceedings of CSCW 88 (1988, New York: ACM). 11. Kumon, S. From Wealth to Wisdom: A Change in the Social Paradigm. In Proceedings of CSCW 92 (1992, New York: ACM), pp. 3. 12. Maes, P. and Kozierok, R. Learning Interface Agents. In Proceedings of AAAI 93 (1993, San Mateo, CA: American Association for Artifical Intelligence). 13. Malone, T.W., Grant, K.R., Turbak, F.A., Brobst, S.A. and Cohen, M.D. Intelligent Information Sharing Systems. Communications of the ACM, 30, 5 (1987), pp. 390-402. 14. Maltz, D.A. Distributing Information for Collaborative Filtering on Usenet Net News . MIT Department of EECS MS Thesis (May, 1994). 15. Pindyck, R.S. and Rubinfeld, D.L. Econometric Models and Economic Forecasts. MacGraw-Hill, New York, 1991. 16. Salton, G. and Buckley, C. Term-Weighting Approaches in Automatic Text Retrieval. Information Processing and Management, 24, 5 (1988), pp. 513-523. 17. Salton, G. and Buckley, C. Improving Retrieval Performance by Relevance Feedback. Journal of the American Society for Information Science, 41, 4 (1990), pp. 288-297. 18. Sheth, B. A Learning Approach to Personalized Information Filtering . MIT Department of EECS MS Thesis (February, 1994). 19. Stodolsky, D.S. Invitational Journals Based Upon Peer Consensus . Roskilde University Centre, Institute of Geography, Socioeconomic Analysis, and Computer Science. ISSN 0109-9779-29 #No. 29/ 1990 (, 1990). 20. Suchak, M.A. GoodNews: A Collaborative Filter for Network News . MIT Department of EECS MS Thesis (February, 1994). 21. Wiederhold, G. Mediators in the Architecture of Future Information Systems. IEEE Computer, March, (1992), pp. 38-49.

1 0

Re: Crypto Law Survey
by greg pitz 17 Dec '03

17 Dec '03

On Wed, 26 Jul 1995 15:28:43 Michael Froomkin wrote: > few years. Second, the American Bar Association Section on > Science and Technology's Information Security Committee is > drafting Guidelines and Model Legislation which, if they are > ever completed, will improve upon the Utah initiative. Would someone be so kind as to describe the Utah initiative? I wasn't able to find a further description in my percursory search of Mr Froomkin's otherwise very informative home page http://www-swiss.ai.mit.edu/6095/articles/froomkin-metaphor/text.html ................... pitz(a)onetouch.com greg pitz ..

1 0

SSL challenge?
by Peter Trei 17 Dec '03

17 Dec '03

Where does the effort to bruteforce SSL stand? I've got a bunch of P5/90s ready and waiting. Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation trei(a)process.com

3 2