|
|
|
| People | Publications | Projects | Funding | |
|
|
Opportunistic people-centric mobile-sensing model introduces a new security challenge in the design of mobile systems: protecting the privacy of participants while allowing their devices to reliably contribute high-quality data to these large-scale applications. AnonySense is a privacy-aware architecture for realizing pervasive applications based on collaborative, opportunistic sensing by personal mobile devices. AnonySense allows applications to submit sensing tasks that will be distributed across anonymous participating mobile devices, later receiving verified, yet anonymized, sensor data reports back from the field, thus providing the first secure implementation of this participatory sensing model. Our papers describe the underlying threat model and trust model, and show how AnonySense provides the desired security properties. We evaluated our prototype implementation through experiments that indicate the feasibility of this approach, and through demonstration applications. Our experiments show that our implementation is efficient, and how our location-blurring feature can provide statistical k-anonymity.
Read more about the project in our papers published at PERVASIVE '08
[manuscript]
and
MOBISYS '08
[manuscript]
|
CenceMe is a personal sensing system that enables members of social networks to
share their sensing presence with their buddies in a secure manner.
Sensing presence captures a user’s status in terms of his activity (e.g.,
sitting, walking, meeting friends), disposition (e.g., happy, sad, doing OK),
habits (e.g., at the gym, coffee shop today, at work) and surroundings (e.g.,
noisy, hot, bright, high ozone). CenceMe injects sensing presence into popular
social networking applications such as Facebook, MySpace, and IM (Skype,
Pidgin) allowing for new levels of "connection" and implicit communication
(albeit non-verbal) between friends in social networks. The CenceMe system is
implemented, in part, as a thin-client on a number of standard and
sensor-enabled cell phones and offers a number of services, which can be
activated on a per-buddy basis to expose different degrees of a user’s sensing
presence; these services include, life patterns, my presence, friend feeds,
social interaction, significant places, buddy search, buddy beacon, and "above
average?"
Read more about the project in our white paper published in EUROSSC '07. [manuscript] |
There is substantial interest in the cycling community in collecting data
quantifying various aspects of the cycling experience. Existing commercial
products have begun to integrate data from multiple local sensors (including
biometric sensors and a GPS receiver) on a single user display, and even
provide map software. A limitation of the currently available products is
the inability to share data with other riders in real-time. Further, often
real-time performance analysis of locally collected data is limited to local
display of simple statistics like min, max and mean over the entire trip. When
the road terrain is highly non-uniform and uphills can last a long time,
comparing current speed against a trip-wide average loses significance.
With the BikeNet application, we work to address these limitations by allowing
cyclists to share information about themselves and the paths they mutually
traverse for real-time display. In BikeNet, information sharing occurs via short
range radios, and can be direct (i.e., bike-to-bike) or indirect through neutral
third-party entities called Checkpoints. Checkpoints are virtual storage and
aggregation devices that are placed along roads and trails frequented by
cyclists; they store location-specific performance data on per-cyclist and
aggregate bases.
Read more in our project report published in SENSYS '07. [manuscript] |
Skiers are interested in knowing current trail conditions (e.g., ice, bare
spots, congestion) when at the base of the mountain in order to determine which
lift to use to get to the desired trail head at the top of the mountain. Resort
managers are interested in learning skier flow statistics to estimate wear on
the terrain in order to enact preventative maintenance (e.g., close trail, make
artificial snow). Safety/emergency personnel are interested in tracking skiers'
location and speed in case of accidents (e.g., fall off trail, avalanche), and
also to prevent accidents by speed policing. Skiers may be interested in
tracking their own location or the location of their friends on the mountain, as
well as avoiding lifts with long queues.
We are inspired by the resemblance of a ski resort trail map to a static sensor
network data dissemination tree; many trails with heads at the top of the
mountain funnel towards a small number of lift entry/collection points at the
base of the mountain. In the SkiScape, ski lifts provide
a continuous supply of data mules (skiers) to the trails at no cost to the
sensing/communication infrastructure. Static sensors, mounted on light poles,
sense data about the adjacent trail area; mobile sensors, mounted on skiers, can
collect data in their locality as the skier traverses the mountain. Skiers
opportunistically collect/carry data of interest as they travel along the trails
to the data sinks at the base. In this way we leverage a sparse deployment of
both static and mobile sensors to give a more complete picture over time of the
field of interest at lower cost than would be required with a fully static
deployment.
Read more about the idea in the poster abstract from SENSYS '06. [manuscript] [poster] |
We have started to deploy Sensor Access Points (SAPs) - Aruba AP-70 WiFi APs
and with one or more Tmote Invents - across Dartmouth Campus. Currently we
have complete coverage of the Computer Science building and plan on covering
Thayer School of Engineering next and then experiment with mobile sensors and
their interaction with these SAPs to develop out MetroSense. Collectively this
infrastructure presents a general purpose, open programming environment for
people-centric applications. The idea is to "parasitically" use existing APs to
build out our campus area SAP infrastructure. SAPs seamlessly support standard
WiFi access, ground-truth sensing (since SAPs have sensors), and sensor comms
(802.15.4) and run the Open-WRT Linux distribution on the AP and TinyOS on the
mote.
Read our architecture white paper published in WICON '06. [manuscript] |