Location-Based Systems: Balancing Privacy and Efficiency, Papers of Computer Science

Download Location-Based Systems: Balancing Privacy and Efficiency and more Papers Computer Science in PDF only on Docsity! Providing Location Abstract Information in a Ubiquitous Computing Environment Mike Spreitzer and Marvin Theimer Xerox Palo Alto To take full advantage of the promise of ubiquitous com- puting requires the use of location information, yet peo- ple should have control over who may know their where- abouts. We present an architecture that achieves these goals for an interesting set of applications. Personal in- formation is managed by User Agents, and a partially decentralized Location Query Service is used to facili- tate location-based operations. This architecture gives users primary control over their location information, at the cost of making more expensive certain queries, such as those wherein location and identity closely interact. We also discuss various extensions to our architecture that offer users additional trade-offs between privacy and efficiency. Finally, we report some measurements of the unextended system in operation, focusing on how well the system is actually able to track people. Our sys- tem uses two kinds of location information, which turn out to provide partial and complementary coverage. 1 Introduction Mobile and ubiquitous computing requires and can ex- ploit a variety of kinds of location information[9, 7, 4]. Just providing a person with access to their normal com- puting services on a continual basis requires that their location be known to a certain extent. In addition, if information is available about who and what is in the vicinity of a person, then that person’s computing en- vironment and applications can behave in a context- sensitive manner. Applications can reflect a user’s cur- rent circumstances and and can respond to changes that might occur in the user’s environment. While desiring to exploit location information, we consider unrestricted access to a person’s location data *This research was supported in part by the Advanced Re- sesrch Projects Agency under contract DABT63-91-C-0027. Permission to copy without fee all or part of this material IS granted provided that the copies are not made or distributed for d!rect commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice IS g)ven that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. SIGOPS ‘93/12 /93/N. C., USA 0 1993 ACM o-8g791-632-8/93 /0012 . ..$ 5050 Research Center to be an unacceptable invasion of privacy[5]. One way to address this fundamental tension between location- based functionality and privacy is to try to give each user control over their location information and over who may gain access to it. Unfortunately, guarantee- ing that no one can gain unauthorized access to one’s location information is, in general, very difficult and ex- pensive. Another important issue is the accuracy and temporal resolution of location information. The sensing facilities we have available to us are not perfect and hence it is important to determine how well they work in practice. Temporal resolution comes into play because it implic- itly defines how small a movement the sensing facilities are able to distinguish, and hence how quickly they are likely to detect a change in someone’s location. Pro- viding useful location information to applications thus faces both the problems of limits of the location sens- ing technologies used as well as protection of users from abuse of those technologies. A topic not covered in this paper is the spatial resolu- tion provided by a system and the implications that has for the kinds of applications that can be implemented. We did not explore this topic because the only spa- tial resolution provided by our sensing technologies is “room-level” resolution. This enables applications such as migrating display windows from one’s office to a con- ference room, but does not easily support finer-grained applications, such as “flicking” a window from one’s portable notebook computer to that of a neighbor sit- ting in the next chair. In order to understand the issues of providing loca- tion information to a system we have chosen a suite of location-based applications to focus on and have de- signed and built a location infrastructure in support of them. The applications we have built or prototype include the following: Visitor guidance : Guide a person to a designated location. Migrating windows : Migrate a user’s windows to a designated location. Note distribution : Send a message to all persons at a given location or set of locations. 270 Ubiquitous Message Delivery (UMD) : A mes- sage submitted for delivery is delivered at the soon- est “acceptable)’ time via the most “appropriate” terminal near the recipient. Acceptable delivery time depends on the context of the recipient. For example, the recipient’s profile may specify that messages below a certain priority level should not be delivered when the recipient is in a meeting with other people. Similarly, the most appropriate ter- minal to use will depend on which devices are avail- able at the recipient’s current location. Me&la Call : A user can request to be connected to one or more other users—wherever they currently are—by the “best” means available. Choices in- clude video, audio, and teletype “talk” connections. As with UMD, users may specify policy constraints that control which kinds of connections may be es- tablished under various circumstances. Scoreboard : This application is an information- oriented “screen saver”. When a display is not be- ing used for anything else, it displays information of general interest, but tailored to the interests of the people nearby. Responsive environment : A “smart building” can optimize its energy usage by exploiting knowledge about which rooms are occupied. It can also control the environmental settings of each room according to the preferences of the people in them[3]. FindNearest : Find the nearest resource or per- son matching a given specification, such as “color printer” or “Unix wizard”. Locations : Display the current locations of various persons, printers, copiers, etc. A common variant is to show the locations of all nearby persons, printers, etc. (see Figure 1). Of these applications UMD and the Locations program are deployed and in use in our lab; for the other appli- cations we have initial prototypes running. In the remainder of this paper we describe the loca- tion architecture we have designed and built, the design rat ion ales behind it, various extensions one could add to offer users additional privacy/efficiency trade-offs, and the current status of our implementation. We also re- port some measurements of the system in operation, fo- cusing on how well the system is actually able to track people. We conclude with a discussion of the insights we have gained from our work. 2 Architecture 2.1 Key Issues The design of a location infrastructure must concern it- self with a variety of fundamental issues. In order to motivate the design of our architecture we start by pre- senting the key issues that we wanted to address. Exam- ples of how applications use our architecture and more detailed design considerations are presented in later sec- tions, after the description of the architecture itself. Perhaps the most important assumption we make is that our system will span more than one administra- tive domain. This being the case, we cannot trust all parts of the system with equal measure. In particular, designs that require one to indiscriminately trust the services and servers of foreign administrative domains seem unacceptable to us. The main consequence is that we cannot simply keep everyone’s location information in a federation of centralized databases, which would otherwise be the simplest means of providing a location infrastructure. A second consequence of multiple administrative do- mains is that we must assume the possibility of sophis- ticated attempts at traffic analysis occurring in some or all parts of a system. As a result, “perfect” privacy guarantees are, in general, very hard (and expensive) to provide. An important observation for our design is that most peoples’ privacy and functionality requirements differ according to the context they are in. Many situations in which functionality is most desired are also situa- tions in which strict privacy guarantees are not so im- portant or where greater trust of system components is warranted. For example, coworkers in a company with benevolent management might be perfectly willing to have their whereabouts known to each other while at work, but might insist on exercising far greater control over who may know their movements when off the job. Furthermore, if the building they work in is physically secure, they may also be willing to accept a more cen- tralized implementation of the location infrastructure in exchange for greater functionality or efficiency. Our canonical example of an untrusted, or partially trusted, environment is a shopping mall. It would be undesirable to allow just anyone (such as junk mail senders) to have access to all one’s movements within the mall, yet one might wish to be visible to, or reach- able by, a select set of friends and family. An important consideration to keep in mind is that in many circumstances having one’s privacy compromised (e.g. while at the mall) is an inconvenience rather than a real problem. Hence, providing guaranteed privacy all the time at a high price—say, in the form of too lit- tle functionality andjor too high a performance cost— will not reflect users’ true needs. On the other hand, 271 depending on the policy its user has specified. Subject to the user’s policy, the agent also makes its user find- able by location using the facilities described later. Some applications work by simply interacting with User Agents. For example, submitting a message for ubiquitous delivery consists of simply giving the mes- sage to the User Agents for the recipients; each agent then takes care of getting the message to its user. Other applications, like Scoreboard, Responsive Environment, and FindNearest, are primarily concerned with a given location, and must perform some kind of a query to find the agents for the people at or near that location. Some- times User Agents themselves need to perform location- based queries—for example, to find nearby terminals through which to present a message for ubiquitous de- livery. One of the key problems addressed by our architec- ture is how to keep disclosure of the association between a person’s identity and that person’s location under the control of that person while supporting our applica- tions with reasonable efficiency. Our architecture pro- vides control through the User Agent: (1) an applica- tion starting from a person’s identity can only discover that person’s location by asking the person’s agent, and (2) an application starting from a location must use the Location Query Service (see below) to discover the iden- tities of the people at that location, and the Location Query Service is designed to give User Agents control over the circumstances of the release of that informa- tion. The Location Query Service (LQS) provides a way of executing location queries that offers different trade-offs between efficiency and privacy. It is built around the idea of queries over located objects. A located object is represent ed by a t uple consist ing of a location, an RPC handle, and an association-list describing the object’s type and other information that the object chooses to make available.1 Examples of located objects include users (represented by User Agents) and terminals (rep- resented by Terminal Agents). A query is a predicate over a location and an association-list; the result of a query is the set of tuples that satisfy the predicate. A key feature of the LQS is that located objects can be anonymous. That is, a tuple’s association-list may reveal only its type and its RPC handle may employ techniques such as indirection through trustworthy in- termediaries to hide the true identity of the real server behind the handle. A client getting a query response listing a tuple with an anonymous RPC handle and no identity in the association-list would have to use the RPC handle to ask the object for its identity.2 That ob- ject (e.g., a User Agent) can respond truthfully, falsely, 10bject type is used indicate which RPC interface to use with the RPC handle. 2III a similar way, a client can hide its identity by issuing its queries from an anonymous RPC handle. or not at all, depending on its policy (which might, for example, require authenticating the caller). Note that a located object could register several tu- ples for itself, in order to make traffic analysis more difficult. The LQS is organized by regions, with a centralized server, called the LocationBroker, running in each re- gion. Public objects whose identities and locations are not meant to be kept secret—such as printers and office display terminals—register a full description of them- selves in the LocationBroker covering the region they in- habit. A private object—such as a User Agent—who is willing to reveal that someone (without revealing who) is at their current location, registers itself in the appro- priate LocationBroker in an anonymous fashion. Each region’s LocationBroker also supports standing queries: a client can submit a query and a callback RPC handle, with the LocationBroker notifying the client of the change whenever the answer to the query changes. This is used, for example, by the Locations program to monitor a given area. A final efficiency trade-off that LocationBrokers can be provide is to implement access control on behalf of an object. This amounts to selectively returning a tu- ple, or portions of its association list, in the results of a query according to a policy specified by the object when it registers itself. An object using a region’s Location- Broker thus has the choice of (1) registering minimal information (location, type, and anonymous RPC han- dle) with the LocationBroker and implementing access control entirely on its o~n, (2) using (and thus trusting) the access control functionality of the region’s Location- Broker, or (3) any combination of the previous two.3 Note that for regions where most User Agents are will- ing to entrust their access controls to the region’s Lo- cationBroker, that region’s LQS has essentially become a centralized design, with all the efficiency benefits and privacy risks that implies. The last piece of our architecture concerns 1/0 de- vices. There is one Terminal Agent for each “terminal”, or cluster of 1/0 devices that operate together (for ex- ample, a workstation’s keyboard, mouse, screen, and sound card comprise one terminal). As with the User Agent, the Terminal Agent consists of several modules, some infrastructure and some application-specific. The agent provides access through a device-independent in- terface, and manages the multiple demands on the ter- minal. Because terminals have owners, and are dedicated (in some cases) to specified uses, there are also policy deci- sions to be made by Terminal Agents. Agents for non- mobile terminals register in the LocationBroker, so that 3Since our interest is in exploring what happens when servers are not trusted, we have not implemented access controls in our LocationBroker. 274 they can be found by location. A mobile terminal may be dedicated to a particular user and might communi- cate directly with that user’s agent instead. 2.3 Application Examples To illustrate how applications make use of our system, we describe how two representative applications are im- plemented: UMD and the Locations program. Someone wishing to send a message for ubiquitous delivery to a user can invoke the SendMsg program to submit a mes- sage to the user’s User Agent. The User Agent keeps track of which (personal) portable computing devices its user is currently using as well as what “public” termi- nals and people are near the user’s current location. The latter is achieved by registering for callbacks with the LQS for the user’s current location. When a message is submitted to the User Agent for delivery, it checks to see if the user’s current situation allows delivery of the message (for example, the user’s policy profile may specify that only priority messages should be delivered when the user is in the presence of other people) and if a suitable terminal is currently available. If so, it sends the message to the terminal’s Terminal Agent; otherwise it waits until the user’s circumstances and/or location change and then tries again. More than one terminal may be available—for ex- ample, if the intended recipient is in their office, they might have access to both their workstation and a portable paging device, if they are carrying one. In this case the User Agent picks the most appropriate one, where appropriateness depends on terminal char- acteristics as well as whether the message to deliver is marked private—and hence shouldn’t be delivered to terminals whose display might be publicly visible (as is the case with workstations). Terminal characteris- tics are exported in the association-list that a Terminal Agent includes when it registers with the LocationBro- ker (or User Agent if it is dedicated to a particular user). In a system with many users, the Locations program needs to be told which users to display information for. One way is to provide an explicit list of user names. In this case the Locations program contacts those users’ agents and requests to be kept appraised of any changes in their users’ locations (assuming they consent). Another way to limit things is to have the Locations program show all users within a specified physical area. Consider what happens when the area fits entirely within an LQS region. The program issues a callback registration to the region’s LocationBroker, asking to be notified of any changes in the area due to User Agents. All User Agents currently registered in the area with the LocationBroker will have their registrations returned in the LocationBroker’s initial response to the callback reg- istration. Any User Agents whose users enter the LQS region at some future point in time and register them- selves in the area with the LocationBroker will have their registrations returned to the Locations program via callback notifications. Similarly, whenever a User Agent leaves the area or changes location within it, a callback will be made to notify the Locations program. An area that intersects multiple LQS regions can be handled by performing the above operations in each re- gion. 3 Design Considerations 3.1 Design Principles As discussed in the previous section, perfect privacy guarantees are difficult to provide. Consequently we have designed a system that allows users to trade off increasing levels of privacy risks for increasing levels of location-based functionality and efficiency. The follow- ing three implementation principles guided our work: ● ● ● Structure the system so that users have both the ability and the choice to not be visible to the vari- ous sensor networks and servers in the system. Avoid requiring personal information to be placed in servers (which may be in untrusted administra- tive domains). Use encryption and anonymous handles to limit the kind of information being revealed. Ideally, sensing systems such as active badges and activity-monitoring OS services would establish se- cret and authenticated communications channels with their users’ agents. Unfortunately the technologies we currently use (Olivetti active badges and the SunOS rus ers daemons) do not allow us to achieve this goal. Our active badges are simple fixed-signal, infra-red bea- cons whose emissions must be gathered by a centralized polling server. Querying rusers daemons suffers from the same problem and, even worse, from the fact that Unix makes this information available indiscriminately. Use of these facilities is acceptable in a friendly envi- ronment, but would not be if we extended our system to a larger, more heterogeneous setting. Only the ability to remain silent—for example, by not wearing one’s ac- tive badge—can ensure that corrupted servers and traf- fic analyzers will not be able to determine the identities of persons entering their domains. An interesting unsolved problem is the question of knowing which sensor systems are actually present at a given location. For example, most people in our lab were originally unaware that the rusers daemon runs on their workst at ion by default. Similarly, most people do not think about the fact that many of their monetary transactions implicitly reveal their current locations to 275 the merchants and banking agencies that are party to each transaction. The potential for inadvertently revealing one’s iden- tity and location can be reduced by employing anonymity. Examples include the use of multiple, anonymous login ids and facilities such as anony- mous electronic cash[2]. Similarly, applications such as Scoreboard only need profile information; they do not need explicit identity information. In our design we rely on anonymity to bridge the gap between wanting to keep location information hidden in a decentralized collection of User Agents and needing to provide some means of performing location queries. User Agents can also use anonymous handles to exercise control over which callers can discover any given piece of information (by choosing how to answer based on the caller’s identity). Queriers, which may themselves be User Agents, can also use anonymity. If both the querier and the re- sponder are initially anonymous and unwilling to reveal themselves without further identification from the other then some additional mechanism is needed to negotiate what to do. We have not explored this topic yet. 3.2 Tradeoffs Anonymity is not always sufficient to preserve privacy. Simply keeping track of how many people are at each location over time can reveal some strong hints about who has been where. The use of multiple, changing anonymous handles and background noise can obscure this information, but there is a long chain of measures and countermeasures that can be taken. One could even be concerned with detection of minute analog differences between individual devices. A user must keep in mind is that there are actually several different ways that the privacy of his location can be compromised: ● ● o ● e ● Application-level operations (such as giving a mes- sage to a Terminal Agent for delivery) with untrust- worthy parties can reveal location information. Location information directly published through the LQS is available to any querier. A LocationBroker might not faithfully implement the access cent rols it offers. The intermediaries used to implement anonymity might be corrupt, or not competent enough to foil the attacker. Traffic analysis of LQS queries or results might re- veal the identity of otherwise anonymous queriers of, or objects in, the LQS. The various location sensing systems that gather location information might deliberately give it to other parties. ● ● The communications between the location sensing systems and the User Agent might not be secret and authenticated. The communications between the person’s portable computers and his processes running at fixed loca- tions (e.g., a User Agent) might not be secret and authenticated. Our architecture gives users choices to limit which of the above potential exposures apply. Different poten- tial exposures involve trusting different system services to different degrees. We must allow users to opt out at whatever level their trust is exceeded. Thus, (1) a User Agent might register a single anonymous tuple in the LocationBroker; (2) a User Agent might register multiple anonymous tuples in the LocationBroker; (3) a User Agent might not register in the LocationBroker at all; and (4) a user might disable transmissions from his portable devices (i.e., receive only—or turn them off if he’s concerned about noise emissions) and refrain from identifying himself to fixed devices. Thus it is important for the system—including applications—to be tolerant of missing or inaccurate information. Uncertainty of lo- cation information (and other personal information) is now fundamentally a part of the system at every level. It would not make sense (in a real system) for a user to give up a lot of efficiency or functionality protect- ing against one potential exposure while not protecting against another that applies in the same situation. For example, in a completely untrusted administrative do- main, one has to assume that any of the domain’s ser- vices (LocationBroker, Terminal Agents, location sens- ing units) could be corrupted. The unfortunate con- sequence of all this is that the users of a system must stay aware of who controls which aspects of the system they are currently using and must act in an accordingly consist ent fashion. Our architecture is not dependent on the exact na- ture of the location sensing technologies, nor the com- munications media, employed. For example, while the experimental system we’ve built to explore our design extends an inconsistent level of trust—it uses anony- mous registrations in the LocationBroker, even though our active badges and Unix workstations reveal location information indiscriminantly—we were willing to accept this because known techniques could be used to provide more secure location sensing facilities. As one possible replacement, consider using portables that have a GPS receiver and a cellular telephone. The portable could get GPS-resolution information to the User Agent, while exposing only cell-resolution location information to only the phone companies involved (if the user assumes nobody is going to use analog techniques to locate his transmitter more precisely), As another possible replacement, consider put ting location beacons 276 100 90 80 .g 70 % @ 60 50 40 Intervals <10 Ulin Intel-vials<30 Ulin Intervsls <1 hr Intervals <2 llrs Illtervsls <4 hrs Au intervals 100 90 Au interv’u” 80 - 70 ‘ 60 - / N 50 - 40 - J m I I 1 I I I I m ~ .“ o 103 200 300 400 500 600 3:001 0.01 0.1 sea hrs Figure 3: Cumulative graphs of badge sighting intervals by interval length, with various upper length considered. bounds on interval length considered. The curve for all intervals (within a “working day” ) is shown extended out to 10 hours in the side plot. Each point on a curve represents the total amount of time spent in intervals shorter in length than that point’s x axis time value as a fraction of the time spent in all intervals considered for the curve. Note that over the region shown by the main figure, the curves are actually just scaled versions of each other because the sum of the interval values used for any x axis point is the same for each curve. The purpose of showing multiple curves is to give the reader some idea of how the (same) data looks as we apply ever-more-aggressive versions of our heuristic for filtering out intervals during which a person is outside the system. When all intervals during the “working day” are in- cluded then short sighting intervals account for a dis- tressingly small percentage of the time. Accounting for likely absences improves the numbers but still leaves sig- nificant periods of time during which a user is sighted only after a lengthy interval. When the badge sighting data is broken down by per- son, considerable variation is seen between people. For example, the percentage of time spent in intervals less than 20 seconds long varied from 9% to 63?10 for the “all intervals” cases. When intervals greater than 1 hour are thrown out then the time spent in intervals of less than 20 seconds varied from 12% to 78V0. These variations 1 10 bounds on interval seem to be due to a variety of factors, such as time spent outside the badge system area during the day, whether or not a person wears their badge all the time, and how “visible” their badge is to sensors. The latter issue is problematic for several reasons: ● ● ● Both natural light and some of our ceiling lighting interfere with the sensitivity of our IR sensors. Many people prefer wearing their badge on their belt rather than pinned to their chest. Unfortu- nately a belt-worn badge is frequently obscured by a person’s arms or other objects; especially when they are seated. Our offices typically have only one sensor in them, yet people tend to face different directions when performing different activities. A common exam- ple is working at a computer versus talking with a colleague. One of the questions we had with using an infra- red-based badge system was how often multiple sensors would see a badge at the same time, This can occur in large rooms containing multiple sensors, at corridor intersections, and for glass-walled offices that happen to have a corridor sensor outside them. Our system has multiple-location sightings about 0.270 of the time; with the bulk of them occurring in our meeting rooms and 279 l~FFTJTn’”ds<’O- Y 80 A ~ Intends <30 LlliIl/ A- i+!fEEH o 100 200 300 400 500 6CM Figure 4: Cumulative graphs of computer input sighting intervals by interval length considered. lab rooms containing multiple sensors. Note that mul- tiple sightings are not a problem for our architecture since uncertainty is part of the system in any case. 4.2 Computer Input Tracking System The basic design of the Unix Location Service is the same as that of the Badge Server: the Unix Location Server polls the rus ers daemon on each workstation in our lab once every 60 seconds to find out when the most recent input activity occurred and which user login id it occurred for. The results are then forwarded to the appropriate User Agents. Figure 4 describes the data we have gathered for this service. The rusers data displays similar characteristics to that of the badge system. That is, the time spent in intervals of small size represents only a small fraction of the total time spent in all sighting intervals, with the fraction significantly improving as larger intervals are excluded from the data, The breakdown by per- son again yields significant differences due to different people’s work patterns. 4.3 Overlap Between Tracking Systems One of the most interesting things we observed about our two tracking systems is that they tend to comple- ment rather than overlap each other. Table 1 lists how 100 80 60 20 0.01 0.1 1 10 hrs interval length, with various upper bounds on often only a person’s badge was seen, only a person’s computer input activity was seen, both were seen, and neither were seen, as a fraction of the total time that the person is in the system. A person is considered to be “in the system” when they are not absent from the badge data and not absent from the input activity data. As before, we define a person to be absent from sensor data during intervals longer than various bounds. We define the notion of a person being “seen” during a sighting interval as meaning that the length of the interval is less than some cut-off value. The table gives overlap statistics for several different absence bounds and “seen interval” cut-off values, the smallest cut-off value being set at a value slightly larger than the minimum sighting interval of either tracking system. The important thing to note is that the fraction of time during which both badge and input activity are seen is quite small, both in absolute terms and relative to the fractions of time during which only one or the other was seen. We attribute this phenomenon to primarily two things: (1) people working at home will be seen by their computer input act ivit, y and not by the badge syst em, and (2) people who wear their badge on their belt and are typing at their workstation will tend to obscure their badge’s emissions while having clearly visible computer input activity. 280 Seen interval cut-off size: 75 sec. 150 sec. 5 min. 10 min. All working-day intervals: Only badge seen: 19% 20% 21% 21% Only input activity seen: 17% 20% 21% 23% Both seen: 7% 9% 10% 13% Neither seen: 57% 51% 48% 43% Only intervals less than 1 hr. considered: Only badge seen: 26% 26% 28% 29% Only input activity seen: 23% 28% 29% 32% Both seen: 9% 12% 14% 17% Neither seen: 42% 34% 29% 22% Only intervals less than 10 min. considered: Only badge seen: 32% 33% 35% 36% Only input activity seen: 31% 36% 38% 43% Both seen: 11% 15% 17% 21% Neither seen: 26% 16% 10% o% Table 1: Table of badge and computer input activity sighting overlap statist its. 4.4 Tracking Moving Persons People sitting within their ofIice provide a different sighting profile to the active badge system than do peo- ple who are moving around. To get a handle on how well our active badge system could track moving persons— such as visitors—we performed several “walk-about” ex- periments to see how well the badge system could follow us. As mentioned earlier, the basic badge sighting inter- val is 15 seconds; which is enough time to walk past about a half dozen offices and perhaps a corridor or two in our lab. We found that a person who randomly walked about our corridors was seen, on average, every 22 seconds, with a standard deviation of 17 seconds. VVe also tried the same experiment with the badge emission period changed to 10 seconds and obtained an average sighting interval of 17 seconds, with a standard devia- tion of 13 seconds. Note that 17 seconds is still enough time to add no- ticeable inaccuracy to an application such as Visitor Guidance. Decreasing the badge emission interval to 5 seconds would presumably give us an average interval length somewhere between 5 and 10 seconds; but would cut the battery lifetime of our badges from its current value of about 3 months to about 1 month. We did not have much trouble with people be- ing sighted in offices while walking past, even though roughly half, on average, of the front wall of each office in our lab is open to IR. Only about 11~0 of the sightings from hall-walking experiments were in offices. While we recognize that the exact placement of a badge sensor within a room can greatly affect this result, we mention it because our sensors were placed in a fashion to op- timize office coverage, without much concern about the hall “cross-talk”. We infer from this that message delivery “chase” ef- fects while people move about should probably not dis- turb the denizens of every office a person walks by. Anecdotal evidence has corroborated this — only one person has reported seeing an attempt at ubiquitous message delivery in his office for someone not present. 5 Conclusions We have designed and built an infrastructure for provid- ing location information and various applications that use that information. The architecture we advocate is a user-centric one in which the personal information for each user—including location information—is managed and controlled by that user’s User Agent. A Location Query Service consisting of a LocationBroker per region is provided to facilitate queries by location. The principle assumptions behind our design were two-fold: ● The design should scale to use in multiple admin- ist rat ive domains. . We did not rule out the existence of untrustworthy servers and sophisticated traffic analysis attacks in some domains. The consequences of these assumptions were that we could not use strictly centralized designs that rely on trusted location databases and we had to accept the fact that strict privacy guarantees are in general difficult and expensive to provide. The hybrid decentralized architecture we designed gives each user a range of privacy options that they may dynamical y choose from. At one extreme is the 281