cypherpunks-legacy
Threads by month
- ----- 2026 -----
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2000 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1999 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1998 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1997 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1996 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1995 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1994 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1993 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1992 -----
- December
- November
- October
- September
December 2003
- 8635 participants
- 56359 discussions
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
> 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
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
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
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
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
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
-----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
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
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