DOCSLIB.ORG

Towards a Secure Agent Society

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Towards a Secure Agent Society Towards A Secure Agent So ciety Qi He Katia Sycara The Rob otics Institute The Rob otics Institute Carnegie Mellon University Carnegie Mellon University Pittsburgh, PA 15213, U.S.A. Pittsburgh, PA 15213, U.S.A [email protected] [email protected] March 23, 1998 Abstract We present a general view of what a \secure agent so ciety" should b e and howtode- velop it rather than fo cus on any sp eci c details or particular agent-based application . We b elieve that the main e ort to achieve security in agent so cieties consists of the following three asp ects:1 agent authentication mechanisms that form the secure so ciety's foundation, 2 a security architecture design within an agent that enables security p olicy making, se- curity proto col generation and security op eration execution, and 3 the extension of agent communication languages for agent secure communication and trust management. In this pap er, all of the three main asp ects are systematically discussed for agent security based on an overall understanding of mo dern cryptographic technology. One purp ose of the pap er is to give some answers to those questions resulting from absence of a complete picture. Area: Software Agents Keywords: security, agent architecture, agent-based public key infrastructure PKI, public key cryptosystem PKCS, con dentiality, authentication, integrity, nonrepudiation. 1 1 Intro duction If you are going to design and develop a software agent-based real application system for elec- tronic commerce, you would immediately learn that there exists no such secure communication between agents, which is assumed by most agent mo del designers. In fact, software agents, as primarily human-delegated software entities, would face almost all the risk and security threats, whichhuman b eing have to face[1],esp ecially in commercial activities. 1.1 Security mechanisms Security risks are various. In addition to providing con dentiality for data communication b e- tween agents, it is also very imp ortant for agent designers and develop ers to take the following three basic security mechanisms into account: 1. Authentication: the mechanism that makes it p ossible for an agent to ascertain an origin of a received message; with the mechanism, an intruder should not b e able to masquerade as someone else. For example, for a site or a no de on the Internet, this mechanism makes it p ossible to verify the identi cation of a visiting mobile agent. 2. Integrity: the mechanism that makes it p ossible for agents to verify that a received message has not b een mo di ed in transit; with the mechanism, an intruder should not b e able to substitute a false message for a legitimate one. The mechanism also makes it p ossible for a site or no de on the Internet to verify that for instance, a legitimate mobile agent has not b e mo di ed in transit. 3. Nonrepudiation: the mechanism that makes an agent who sent a message not b e able to falsely deny later that it sent the message. The mechanism may also make it imp ossible for anyone else to replay the message later. To construct and use these security mechanisms itself is very crucial part in designing/planning pro cedure of commercial activities for agents. 1.2 Agent and Mo dern Cryptography The ground breaking development of mo dern cryptography has b een meeting the demand of securityofvarious applications over op en network: Conceptually, the op enness of mo dern cryp- tosystems, b oth symmetrical cryptosystem such as DES[2], IDEA[3], and asymmetric cryptosys- tem, such as RSA[4], lays a shared foundation of security op erations of agents across the Internet. Technically, some security standard software packages and APIs are under development, and they could b e available in very near future[6][7]. Those achievements, like the achievements in AI, are rip e to b e adopted in development of agent applications. Agents, as primarily human-delegated software, could b ecome the primary area for us to practice mo dern cryptographic technology b ecause: 1. Software agents are playing increasingly active and bigger role in electronic commerce. To b e adopted into soft agent developmentwould b e the direction for mo dern cryptography to fully demonstrate its p otential signi cant function in electronic commerce. 2. Execution of most security proto cols would b e big burden for end-user, however, it could b e done fairly easily by autonomous software, agents. 2 RETSINA[8], an intelligentmulti-agent pro ject at Carnegie Mellon University, is developing a general architecture of agents which can communicate with agent communication language, such as KQML[9] and work together co op eratively by applying DAI theory and technology. The multi-agent system is exp ected to b e employed in various agent-based applications over the In- ternet, particularly in electronic commerce. Because of the imp ortance and feasibility of security mentioned ab ove, security mechanisms and functionality are considered as one of the basic fea- tures in our design[10]. At same time, we recognize that to achieve agent security, it is necessary to establish trust relationship among agent so cieties and an agent-based public key infrastructure is under construction[11]. In this pap er, we systematically and comprehensively intro duce our metho dology and design of trust establishment, internal security functional mo dule structure of agent, as well as an exten- sion of agent communication language to achieve security of agent and agent so ciety for general agent-based applications. The remainder of the pap er is organized as follows: Section 2, will intro duce our work on establishment of trust for security agent so cieties, which will lay, in a b ottom up fashion, a au- thentication foundation for agent security. This is security infrastructure for secure environment of agent. In section 3, we will intro duce the basic metho dology, a three-level partition for agent securityinvolving security p olicy making, security proto col generation and security op eration execution, as well as the security architecture within an agent. In section 4, we will intro duce an extension of agent communication language for agent secure communication and trust man- agement. In section 5, we will discuss some limitations and op en problems. Since our work, unlike other pap ers[12][13], fo cuses on general reusable software agent architec- ture,we are not going to fo cus on any sp eci c application pro ject or on a particular asp ect. 2 AgentTrust Infrastructure Authentication, integrity, nonrepudiation are fundamental parts of mo dern cryptography.We use those mechanisms through out our daily life, when we sign our name to some do cument for instance, and as wemovetoa world where our decisions and agreements are communicated elec- 1 tronically,we need to replicate these pro cedures . A great advantage of public key cryptography is that it provides mechanisms for such pro cedures in very ecientway[14]. 2.1 PKI: Public Key Infrastructure Whenever we, however, use a public key to encrypt a message or to verify the authenticity digital signature of a message, wemust ensure that the public key we are using is valid and it b elongs to the claimant rather than anyone else. This issue known as the public key integrity problem vitally determines the whole security of communication, including conducting transactions over the Internet. The current state-of-the art solution is to establish in a hierarchical manner a system to is- sue public key certi cates, in which the principal's public key probably as well as some other information is included and signed by an authority, and the authoritymay hold a certi cate issued by a sup er authority, and so on up the hierarchy. This system is the so called public key 1 Obviously,ifwe exp ect to delegate agents to do job for us, wemust incorp orate the corresp onding security mechanisms into agent design and development. 3 Hierarchy 1 Hierarchy 2 Hierarchy 3 application agent Figure 2.1 Multiple Hierarchies across a agent. certi cate management infrastructure, or PKI Public Key Infrastructure[15 ]. It is worth p ointing out that although several PKI implementations are currently evolving such as IETF's PKIxPublic-Key Infrastructure,X.509[16], PKCSPublic Key Crypto System[17], PGPPretty Go o d Privacy[18], SPKISimple Public Key Infrastructure[19 ], SDSISimple Dis- tributed Security Infrastructure[20 ],etc., there is no single PKI implementation nor even a single agreed-up on standard for setting up a PKI. Even those implementations that are based on the same standard X.509 recommendation[16] are still incompatible with each other b ecause of indep endentinterpretations in their actual implementations[21] [22]. Further more, security proto cols, op erations and inter-op erations b etween principals agents, as well as public key management are really dicult for the ordinary end-users to handle. Those routines themselves should b e autonomously and co op eratively p erformed by programs running on the Internet so that the workload of the users can b e lessened. 2.2 Security Agent: Agent-Based/Oriented PKI To exploit public key cryptography for agent security,itwould b e unavoidable for us to consider construction of agent-oriented PKI, which is exp ected not only to b e suitable for agent-based applications[11], but also can take advantages of autonomous agent to facilitates inter-op erability and exibility. Unlike the traditional way of PKI implementation, our PKI implements the authorities of au- thentication veri cation service systems as autonomous software agents, called security agents, instead of building a static monolithic hierarchy.Formats of certi cates for various applications can b e p ersonalized by the users or sp eci c applications.
Load more

Recommended publications
  • 1. Course Information Are Handed Out
    6.826—Principles of Computer Systems 2006 6.826—Principles of Computer Systems 2006 course secretary's desk. They normally cover the material discussed in class during the week they 1. Course Information are handed out. Delayed submission of the solutions will be penalized, and no solutions will be accepted after Thursday 5:00PM. Students in the class will be asked to help grade the problem sets. Each week a team of students Staff will work with the TA to grade the week’s problems. This takes about 3-4 hours. Each student will probably only have to do it once during the term. Faculty We will try to return the graded problem sets, with solutions, within a week after their due date. Butler Lampson 32-G924 425-703-5925 [email protected] Policy on collaboration Daniel Jackson 32-G704 8-8471 [email protected] We encourage discussion of the issues in the lectures, readings, and problem sets. However, if Teaching Assistant you collaborate on problem sets, you must tell us who your collaborators are. And in any case, you must write up all solutions on your own. David Shin [email protected] Project Course Secretary During the last half of the course there is a project in which students will work in groups of three Maria Rebelo 32-G715 3-5895 [email protected] or so to apply the methods of the course to their own research projects. Each group will pick a Office Hours real system, preferably one that some member of the group is actually working on but possibly one from a published paper or from someone else’s research, and write: Messrs.
    [Show full text]
  • Oral History of Butler Lampson
    Oral History of Butler Lampson Interviewed by: Alan Kay Recorded: August 22, 2006 Cambridge, Mass. CHM Reference number: X3697.2007 © 2006 Computer History Museum Oral History of Butler Lampson Alan Kay: Part of my job here as given by the Computer History Museum is to try and get a few good words from you that we could use as the opening blurb for your award from the Computer History Museum. But also to get an oral history. Butler Lampson: I was going to say, I thought the job was to record hours of brilliant conversation that historians in 2100 will pore over. Kay: That is your job. My job is to only to try and instigate it. My theory about this thing is that you should not try and talk short. Lampson: Well, we’ve got lots of time right? Kay: Okay. We do have lots of time and tape is cheap. Lampson: Tape is cheap. Right. My sister’s a film editor and she hates it. She says things were much better in the days when film was expensive, because people would think about what they shot. Now, she says, they shoot hundreds of hours of crap and then they expect the editor to sort it out. Kay: We have to transcribe those hundreds of hours. Lampson: Yeah. Somebody’s got to look at it, it’s got to be fussed around with, and besides, she says, frequently in the whole of hundreds of hours you don’t find what you want because nobody thought about it beforehand. Kay: You remember Bonnie, my wife, ran a film and video company for ten years.
    [Show full text]
  • The People Who Invented the Internet Source: Wikipedia's History of the Internet
    The People Who Invented the Internet Source: Wikipedia's History of the Internet PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 22 Sep 2012 02:49:54 UTC Contents Articles History of the Internet 1 Barry Appelman 26 Paul Baran 28 Vint Cerf 33 Danny Cohen (engineer) 41 David D. Clark 44 Steve Crocker 45 Donald Davies 47 Douglas Engelbart 49 Charles M. Herzfeld 56 Internet Engineering Task Force 58 Bob Kahn 61 Peter T. Kirstein 65 Leonard Kleinrock 66 John Klensin 70 J. C. R. Licklider 71 Jon Postel 77 Louis Pouzin 80 Lawrence Roberts (scientist) 81 John Romkey 84 Ivan Sutherland 85 Robert Taylor (computer scientist) 89 Ray Tomlinson 92 Oleg Vishnepolsky 94 Phil Zimmermann 96 References Article Sources and Contributors 99 Image Sources, Licenses and Contributors 102 Article Licenses License 103 History of the Internet 1 History of the Internet The history of the Internet began with the development of electronic computers in the 1950s. This began with point-to-point communication between mainframe computers and terminals, expanded to point-to-point connections between computers and then early research into packet switching. Packet switched networks such as ARPANET, Mark I at NPL in the UK, CYCLADES, Merit Network, Tymnet, and Telenet, were developed in the late 1960s and early 1970s using a variety of protocols. The ARPANET in particular led to the development of protocols for internetworking, where multiple separate networks could be joined together into a network of networks. In 1982 the Internet Protocol Suite (TCP/IP) was standardized and the concept of a world-wide network of fully interconnected TCP/IP networks called the Internet was introduced.
    [Show full text]
  • A Memorable Trip Abhisekh Sankaran Research Scholar, IIT Bombay
    A Memorable Trip Abhisekh Sankaran Research Scholar, IIT Bombay It was my first trip to the US. It had not yet sunk in that I had been chosen by ACM India as one of two Ph.D. students from India to attend the big ACM Turing Centenary Celebration in San Francisco until I saw the familiar face of Stephen Cook enter a room in the hotel a short distance from mine; later, Moshe Vardi recognized me from his trip to IITB during FSTTCS, 2011. I recognized Nitin Saurabh from IMSc Chennai, the other student chosen by ACM-India; 11 ACM SIG©s had sponsored students and there were about 75 from all over the world. Registration started at 8am on 15th June, along with breakfast. Collecting my ©Student Scholar© badge and stuffing in some food, I entered a large hall with several hundred seats, a brightly lit podium with a large screen in the middle flanked by two others. The program began with a video giving a brief biography of Alan Turing from his boyhood to the dynamic young man who was to change the world forever. There were inaugural speeches by John White, CEO of ACM, and Vint Cerf, the 2004 Turing Award winner and incoming ACM President. The MC for the event, Paul Saffo, took over and the panel discussions and speeches commenced. A live Twitter feed made it possible for people in the audience and elsewhere to post questions/comments which were actually taken up in the discussions. Of the many sessions that took place in the next two days, I will describe three that I found most interesting.
    [Show full text]
  • Desktop Publishing Pioneer Meeting: Day 1 Session 4 - Technology in the 1980S
    Desktop Publishing Pioneer Meeting: Day 1 Session 4 - Technology in the 1980s Moderators by: Burt Grad David C. Brock Editor: Cheryl Baltes Recorded May 22, 2017 Mountain View, CA CHM Reference number: X8209.2017 © 2017 Computer History Museum Table of Contents TEX TECHNOLOGY .................................................................................................................. 5 FRAMEMAKER TECHNOLOGY ................................................................................................ 7 EARLY POSTSCRIPT DEVELOPMENT EFFORTS .................................................................11 POSTSCRIPT AND FONT TECHNOLOGY ..............................................................................12 COMMERCIAL POSTSCRIPT ..................................................................................................15 POSTSCRIPT VS. OTHER APPROACHES .............................................................................20 POSTSCRIPT, APPLE, AND ADOBE .......................................................................................22 HALF TONING AND POSTSCRIPT ..........................................................................................24 ADOBE ILLUSTRATOR TECHNOLOGY ..................................................................................25 LASERWRITER TECHNOLOGY ..............................................................................................26 FONT SELECTION ...................................................................................................................27
    [Show full text]
  • Jonathan Zittrain's “The Future of the Internet: and How to Stop
    The Future of the Internet and How to Stop It The Harvard community has made this article openly available. Please share how this access benefits you. Your story matters Citation Jonathan L. Zittrain, The Future of the Internet -- And How to Stop It (Yale University Press & Penguin UK 2008). Published Version http://futureoftheinternet.org/ Citable link http://nrs.harvard.edu/urn-3:HUL.InstRepos:4455262 Terms of Use This article was downloaded from Harvard University’s DASH repository, and is made available under the terms and conditions applicable to Other Posted Material, as set forth at http:// nrs.harvard.edu/urn-3:HUL.InstRepos:dash.current.terms-of- use#LAA YD8852.i-x 1/20/09 1:59 PM Page i The Future of the Internet— And How to Stop It YD8852.i-x 1/20/09 1:59 PM Page ii YD8852.i-x 1/20/09 1:59 PM Page iii The Future of the Internet And How to Stop It Jonathan Zittrain With a New Foreword by Lawrence Lessig and a New Preface by the Author Yale University Press New Haven & London YD8852.i-x 1/20/09 1:59 PM Page iv A Caravan book. For more information, visit www.caravanbooks.org. The cover was designed by Ivo van der Ent, based on his winning entry of an open competition at www.worth1000.com. Copyright © 2008 by Jonathan Zittrain. All rights reserved. Preface to the Paperback Edition copyright © Jonathan Zittrain 2008. Subject to the exception immediately following, this book may not be reproduced, in whole or in part, including illustrations, in any form (beyond that copying permitted by Sections 107 and 108 of the U.S.
    [Show full text]
  • Two Facets of Authentication
    SRC Technical Note 1998 - 007 March 18, 1998 Two Facets of Authentication Mart´ın Abadi d i g i t a l Systems Research Center 130 Lytton Avenue Palo Alto, California 94301 http://www.research.digital.com/SRC/ Copyright c IEEE 1998. All rights reserved. Republished by permission. Two Facets of Authentication Mart´ın Abadi Digital Equipment Corporation Systems Research Center [email protected] March 18, 1998 Abstract Authentication can serve both for assigning responsibility and for giving credit. Some authentication protocols are adequate for one pur- pose but not the other. This paper explains the distinction between responsibility and credit, through several examples, and discusses the role of this distinction in the design and analysis of protocols. Contents 1 Responsibility and Credit 1 2FourExamples 2 2.1SigningaPublicKey....................... 2 2.2EncryptingaSessionKey.................... 4 2.3 Making a Session Key from Encrypted Shares . 5 2.4TheStation-to-StationProtocol................. 7 3 Discussion 8 3.1Design............................... 8 3.2Analysis.............................. 9 Acknowledgements 10 References 11 1 Responsibility and Credit Authentication can serve both for assigning responsibility and for giving credit. An “authenticated” message M from a principal A toaprincipalB may be used in at least two distinct ways: • B may believe that the message M is being supported by A’s authority. For example, suppose that B is a file server, A a client, and M a request to delete a file f.ThenBmay use A’s identity as an argument to the access control decision of whether to delete f. • B may attribute credit for the message M to A. For example, suppose that B is running a contest, offering a prize to the principal that mails the factors for a large number.
    [Show full text]
  • Alan Mathison Turing and the Turing Award Winners
    Alan Turing and the Turing Award Winners A Short Journey Through the History of Computer TítuloScience do capítulo Luis Lamb, 22 June 2012 Slides by Luis C. Lamb Alan Mathison Turing A.M. Turing, 1951 Turing by Stephen Kettle, 2007 by Slides by Luis C. Lamb Assumptions • I assume knowlege of Computing as a Science. • I shall not talk about computing before Turing: Leibniz, Babbage, Boole, Gödel... • I shall not detail theorems or algorithms. • I shall apologize for omissions at the end of this presentation. • Comprehensive information about Turing can be found at http://www.mathcomp.leeds.ac.uk/turing2012/ • The full version of this talk is available upon request. Slides by Luis C. Lamb Alan Mathison Turing § Born 23 June 1912: 2 Warrington Crescent, Maida Vale, London W9 Google maps Slides by Luis C. Lamb Alan Mathison Turing: short biography • 1922: Attends Hazlehurst Preparatory School • ’26: Sherborne School Dorset • ’31: King’s College Cambridge, Maths (graduates in ‘34). • ’35: Elected to Fellowship of King’s College Cambridge • ’36: Publishes “On Computable Numbers, with an Application to the Entscheindungsproblem”, Journal of the London Math. Soc. • ’38: PhD Princeton (viva on 21 June) : “Systems of Logic Based on Ordinals”, supervised by Alonzo Church. • Letter to Philipp Hall: “I hope Hitler will not have invaded England before I come back.” • ’39 Joins Bletchley Park: designs the “Bombe”. • ’40: First Bombes are fully operational • ’41: Breaks the German Naval Enigma. • ’42-44: Several contibutions to war effort on codebreaking; secure speech devices; computing. • ’45: Automatic Computing Engine (ACE) Computer. Slides by Luis C.
    [Show full text]
  • Hints and Principles for Computer System Design Butler Lampson August 13, 2020
    Hints and Principles for Computer System Design Butler Lampson August 13, 2020 Abstract This new long version of my 1983 paper suggests the goals you might have for your system— Simple, Timely, Efficient, Adaptable, Dependable, Yummy (STEADY)—and techniques for achieving them—Approximate, Incremental, Divide & Conquer (AID). It also gives some princi- ples for system design that are more than just hints, and many examples of how to apply the ideas. Table of Contents 1. Introduction 3 1.1 Oppositions and slogans 5 2. Principles 6 2.1 Abstraction 6 2.1.1 Safety and liveness 8 2.1.2 Operations 9 2.2 Writing a spec 9 2.2.1 Leaky specs and bad specs 11 2.2.2 Executable specs 13 2.3 Writing the code: Correctness 13 2.3.1 Types 15 2.3.2 Languages 16 2.4 Modules and interfaces 16 2.4.1 Classes and objects 17 2.4.2 Layers and platforms 19 2.4.3 Components 20 2.4.4 Open systems 21 2.4.5 Robustness 22 2.4.6 Standards 22 2.5 Points of view 23 2.5.1 Notation 23 3. Goals and Techniques 25 3.1 Overview 25 3.1.1 Goals 25 3.1.2 Techniques 25 3.2 Simple 26 3.2.1 Do one thing well 27 3.2.2 Brute force 29 3.2.3 Reduction 29 3.3 Timely 30 3.4 Efficient 30 3.4.1 Before the ABCs 31 3.4.2 Algorithms 36 3.4.3 Approximate 37 3.4.4 Batch 41 1 3.4.5 Cache 42 3.4.6 Concurrency 44 3.5 Adaptable 49 3.5.1 Scaling 50 3.5.2 Inflection points 51 3.6 Dependable 53 3.6.1 Correctness 54 3.6.2 Retry 55 3.6.3 Replication 56 3.6.4 Detecting failures: real time 58 3.6.5 Recovery and repair 59 3.6.6 Transactions 59 3.6.7 Security 60 3.7 Yummy 63 3.7.1 User interfaces 63 3.8 Incremental 65 3.8.1 Being and becoming 65 3.8.2 Indirection 69 4.
    [Show full text]
  • 19788 NAE Bridge V33n1
    Spring 2003 The BRIDGE LINKING ENGINEERING AND SOCIETY Computing Meets the Physical World Butler Lampson Autonomous Robot Soccer Teams Manuela Veloso Flying with Animals Part One: Linking Artificial Information-Processing Machines and Living Information-Processing Machines Chris Diorio Part Two: Interfacing Computer Electronics with Biology Thomas Daniel Entering the Brain: New Tools for Precision Surgery Eric Grimson Promoting the technological welfare of the nation by marshalling the knowledge and insights of eminent members of the engineering profession. The BRIDGE NATIONAL ACADEMY OF ENGINEERING George M.C. Fisher, Chair Wm. A. Wulf, President Sheila E. Widnall, Vice President W. Dale Compton, Home Secretary Harold K. Forsen, Foreign Secretary William L. Friend, Treasurer Editor-in-Chief George Bugliarello (Interim) Managing Editor: Carol R. Arenberg Production Assistants: Penelope Gibbs, Kimberly West The Bridge (USPS 551-240) is published quarterly by the National Academy of Engineering, 2101 Constitution Avenue, N.W., Washington, DC 20418. Periodicals postage paid at Washington, D.C. Vol. 33, No. 1 Spring 2003 Postmaster: Send address changes to The Bridge, 2101 Constitution Avenue, N.W., Washington, DC 20418. Papers are presented in The Bridge on the basis of general interest and time- liness. They reflect the views of the authors and not necessarily the position of the National Academy of Engineering. The Bridge is printed on recycled paper. © 2003 by the National Academy of Sciences. All rights reserved. A complete copy of each issue of The Bridge is available in PDF format at http://www.nae.edu/TheBridge. Some of the articles in this issue are also available as HTML documents and may contain links to related sources of information, multimedia files, or other content.
    [Show full text]
  • Vision and Reality of Hypertext and Graphical User Interfaces
    Universität Hamburg Fachbereich Informatik Vogt-Kölln-Str. 30 D-22527 Hamburg Germany Bericht 237 Vision and Reality of Hypertext and Graphical User Interfaces FBI-HH-B-237/02 Matthias Müller-Prove [email protected] In die Reihe der Berichte des Fachbereichs Informatik aufgenommen durch Prof. Dr. Horst Oberquelle Prof. Dr. Christopher Habel Februar 2002 Abstract The World Wide Web took off ten years ago. Its tremendous success makes it easy to forget the more than forty years of hypertext development that preceded the Web. Similarly, modern graphical user interfaces have drawn attention away from the many compelling ideas behind earlier user interface designs. In the present thesis, numerous early hypertext and graphical user interface systems are presented and contrasted with today's Web and desktop interfaces. The designers of early hypertext and graphical user interface systems shared a common objective: the development of a personal dynamic medium for creative thought. Not very much is left from this original vision. Retrospect reveals promising insights that might help to reconcile the desktop environment with the Web in order to design a consistent and powerful way to interact with the computer. Zusammenfassung Das World Wide Web hat vor nunmehr über zehn Jahren seinen unvergleichlichen Siegeszug begonnen. Dabei wird oft übersehen, daß die Idee des Hypertexts eine bereits über vierzigjährige Geschichte hinter sich hat. Die Arbeit zeigt diese Entwicklung anhand der verschiedenen Hypertextsysteme auf und kontrastiert sie mit dem Web. Die Betrachtung der Grafischen Benutzungsoberflächen zeigt ganz ähnlich, daß auch hier viele gute Ideen auf dem Wege zu den heute dominierenden Fenstersystemen verloren gegangen sind.
    [Show full text]
  • The Power of the Context
    The Power Of The Context Remarks upon being awarded — with Bob Taylor, Butler Lampson and Chuck Thacker — the Charles Stark Draper Prize of the National Academy of Engineering, February 24, 2004 by Alan Kay When Bill Wulf called to say that the four of us had been awarded this year’s Draper Prize, I was floored because even the possibility was not in my mind. Given the amazing feats of engineering in the 20th century, the previous laureates, and that this is just the 10th awarding of the prize, it seems unbelievable Bob Taylor to have been chosen. Of course, every engineer, mathematician Butler Lampson and scientist — every artist — knows that the greatest privilege is being able to do the work, and the greatest joy is to actually turn yearnings into reality. So we were already abundantly rewarded many years ago when this work came together to create a new genre of practical personal computing. There were three people who were absolutely indispensible to Chuck Thacker Alan Kay Xerox PARC's success: Bob Taylor, Butler Lampson, and Chuck Thacker. Receiving this award with them is a truly incredible honor. Since this award is about a whole genre of computing, it is extremely important to acknowledge and thank the larger group of several dozen PARC researchers who helped conceive the dreams, build them and make them work. This was especially so in our Learning Research Group, where a wide range of special talents collaborated to design and build our computing Dan Ingalls Adele Goldberg and educational systems. I particularly want to thank Dan Ingalls and Adele Goldberg, my closest colleagues at PARC for helping realize our dreams.
    [Show full text]