The Smalltalk-80* programming language includes dynamic storage allocation, fuU upward limargs, and universally polymorphic procedures; file Smalllalk-80 programming system features interactive exect, tion wiflt incremental compilation, and implementation portability.These features of modern programming systems are among the most difficult tu implement efficiently, even individually. A new implemelltation of the Small/alk-80 system, hnsted on a sinall microprocessor-based computer, achieves high performance while retaining' complete (object code) compatibility with existing implementations. This paper discusses the most significant optimization techniques developod over the course of the project, many of which are applicable to other languages. The key idea is to represent certain nmtime state (both code and data) in more than one form. and to convert between fo~xns when needed.*Smalhalk-80 is a trademark of the Xerox Corporalion. BACKGROUNI)The Smalltalk-80 system is an object-oriented programming language and interactive programming environment.The Smalltalk-80 language inclodes many of the most difficult-toimplement features of modern progralnming languages: dynamic storage allocation, full upward funargs, and call-time binding of procedure names to actual procedures based on dynamic type information, sometimes called message-pa~#tg. The interactive environment includes a full complement of programming tools: compiler, debugger, editor, window system, and so on, all written in the Smalltalk-80 language itself. A detailed overview of the system appears in [SCG 8l]. [Goldberg 83] is a technical refcrcncc for both file nnn-interactive programmer and the system implcmentor; [Goldberg 841 is a reference manual for the interactive system. SPE('IAL l)l I,'FICULTil,;SThe standard Smalltalk-80 system implementation is based on an ideal virtual machine or v-machine. The compiler generates code for this machine, and the implementor's documentation describes the system as an interpreter for the v-Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct 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. © 1983 ACM 0-89791-125-3/84/001/0297 $00.75 machine instruction set, similar to the Pascal P-system [Ammann 75] [Ammann 77]. One unusual feature of the Smalltalk-80 vmachine is that it makes runtime state such as procedure activations visible to tile programmer as data objects. This is similar to tile "spaghetti stack" model of Interlisp [XSIS 83l, but more straightforward: Intcrlisp uses a programmer-visible iudircction mechanism to reference pr~x:edure activations, whe~'cas Ihe Sinalltalk-80 programmer treats procedure actiwttioas just like any other data objects.

No abstract

The Internet is evolving rapidly into a global electronic marketplace, where buyers and sellers can meet and spontaneously transact business. This marketplace is an unprecedented medium f o r sales, marketing, distribution, customer service, and corporate communication that will fundamentally change the structure of corporations and how they d o business. We will assess this phenomenon and its implications frcm the perspective of CommerceNet, a consortium of nearly 80 leading US companies who have come together to field the first large-scale market trial of electronic commerce on the Internet.

No abstract

This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents. S-HTTP, as described by RFC 2660, contains the concept of negotiation headers which reflect the potential receiver of a message's preferences as to which cryptographic enhancements should be applied to the message. This document describes a syntax for binding these negotiation parameters to HTML anchors.

In addition to visiting popular sites such as Facebook and Google, web users often visit more modest sites, such as those operated by bloggers, or by local organizations such as schools. Such sites, which we call "Just Plain Sites" (JPSs), are likely to inadvertently present greater privacy risks than highly popular sites, because they are unable to afford privacy expertise. To assess the prevalence of the privacy risks to which JPSs may inadvertently be exposing their visitors, we examined privacy practices that could be observed by analysis of JPS landing pages. We found that many JPSs collect a great deal of information from their visitors, and share a great deal of information about their visitors with third parties. For example, we found that an average of 7 third party organizations are informed when a user visits a JPS. Many JPSs additionally permit a great deal of tracking of their visitors. For example, we found that third party cookies are used by more than 50% of JPSs. We also found that many JPSs use deprecated or unsafe security practices. Our goal is not to scold JPS operators, but to raise awareness of these facts among both JPS operators and visitors, possibly encouraging operators to take greater care in their implementations, and visitors to take greater care in how, when, and what they share.

Abstract-We often communicate private data in informal settings such as email, where we trust that the recipient shares our assumptions regarding the disposition of this data. Sometimes we informally express our desires in this regard, but there is no formal means in such settings to make our wishes explicit, nor to hold the recipient accountable. Here we describe a system and prototype implementation called Recipient-Accountable Private Personal Data, which lets the originator express his or her privacy desires regarding data transmitted in email, and provides some accountability. Our method only assumes that the recipient is reading the email online, and on an email reader that will execute HTML and JavaScript.

No abstract