WorldSpotting, A New Class of Ubicomp Apps

There's an interesting class of ubicomp apps that I'm calling WorldSpotting. These kinds of apps are mobile systems where people act both as sensors and as users of the system. Some examples WorldSpotting applications include:
  • Gawker Stalker, which lets you track and send updates on where celebrities are in Manhattan
  • Mobile Media Metadata, which lets you easily tag photos with place names, based on what other people have labeled
  • Wardriving, where people both collect data on the location of WiFi access points and use those, for general network access or for location positioning
  • Bustle, a system we are developing that lets you contribute information on how busy a place is, as well as query how busy places are. An example application would be to see how busy the local cafe is.
The pros of WorldSpotting applications is that you can get massive scale without having to install lots of infrastructure, as has typically been done for many ubiquitous computing applications. Thus, WorldSpotting is a hybrid between personal ubiquitous computing, that is applications that serve and describe individuals, and place-based ubiquitous computing, applications that serve and describe places.

However, there are many challenges in building WorldSpotting applications, many of which we found through a great deal of trial and error in building and evaluating Bustle. These include:
  • How to actually do sensing? Sensing can be done manually, as in Gawker Stalker, or automatically. Here, the issues include timeliness, accuracy, overhead for users, and the cost of additional sensors (which may be the greatest barrier, since manufacturers tend to be conservative due to costs). With Bustle, we overcame this problem by using WiFi, which is now a commodity on laptops.
  • How to share sensed information? Since we don't have ubiquitous wireless networking yet, it is possible to collect data and then share it later on once re-connected to the network. In some cases, this is still useful, for example WarDriving, but in other cases, stale data is useless.
  • How to detect and prevent cheating? This is a question we often get about Bustle, which is, what is to prevent cafe owners from saying that there place is only moderately busy, to fool people into going there? There isn't a clear solution yet, but one possibility is reputation management, looking for people whose data consistently matches other people's. Another is to look for anomalies, for example, a computer that only reports from one location.
  • How to calibrate world models? One of the issues we had with Bustle is that we could automatically sense the number of WiFi devices, but needed some human interaction to translate that into the number of people and the number of open tables in an area. With enough people, you could do statistical techniques to calibrate what sensed readings actually mean in practice.
  • How to manage end-user privacy? One of the potential risks in WorldSpotting is that people who contribute data can be tracked. Another potential risk is sensor data mining, looking for people whose readings are consistently similar, which can be used to infer that there is some kind of relationship. In Bustle, we tried to minimize this by using anonymous readings and by eliminating as much data as possible on the client-side, before the data is shipped to us. For example, we don't get any data about WiFi MAC addresses, nor do we want any.
  • How to provide incentives to collecting data? This is another question we often get about Bustle, which is why a person would want to collect and share data. From a game theory perspective, there is little upside to sharing data, but a fair amount of possible downside, in terms of privacy and overhead. One possible solution here is to make everything automatic, so that people don't have to do anything special at all. Another possible solution is to provide a scoreboard. One need only look at the SETI@Home statistics to see that there will be some set of people who will fight and fight hard to be on top. It's also interesting to point out that a non-trivial number of people contribute wardriving data, with little to personally gain. However, these issues point to a larger and deeper question, namely...
  • How many people does one need for coverage? This is still an open question, but our early data for Bustle suggested that we only needed about 20 participants to cover half of the buildings on the CMU campus. Obviously, more is better, but my instinct here says that you would need fewer people than you might think to get good enough data in practice.
To wrap up, I though I'd include other possibly interesting WorldSpotting applications:
  • Cars that have "bump" sensors in them, to detect potholes in the ground. With enough cars, you could have a real-time map of what roads in a city need to be fixed
  • Bus Finder. With enough people running the app on their phone, you could have real-time maps showing where the buses are and how busy they are. This is especially useful in Pittsburgh, since buses tend to be full on snowy and rainy days, and hence don't stop for new passengers.
  • Airport lines. You could have real-time data on how long the lines for tickets and for the security checks are. I've personally missed more than one flight by underestimating this.

Comments

Popular posts from this blog

How to Fix a Jammed Toyota Camry Trunk

Web 2.0 and Research

[Research] Famous Rejected Papers