UW Computer Security Research and Course Blog

(originally written 11/07/2008)

Early next week, the University of California, Berkeley, in a joint effort with Nokia Research Labs, intends to launch Mobile Millennium, a project that aims to capture traffic patterns accurately and in real-time by harnessing cell phones as mobile sensors.  Previous work has only considered static sensors explicitly placed at location of interest (e.g. major congested roads); as such, their approach suffers from the inherent existence of blind spots in their analyses.  On the other hand, the design of Mobile Millennium lends itself well to monitoring traffic patterns anywhere participating mobile phones receive signal.

In Mobile Millennium, users will be able to voluntarily download a free Java program onto their mobile devices, which monitors their location, speed and direction of movement.  This information will be collected into a large database and analyzed collectively to determine the presence of traffic jams and stranded vehicles, for example.  This technology currently targets GPS-enabled phones whose service provider is a GSM network, e.g. AT&T or T-Mobile.  Mobile Millennium has set virtual trip lines at certain geographic locations so that whenever a participating device passes through the trip line, information is relayed to the project servers. This project will focus on traffic on major roads between the Bay Area and Sacramento, but intends to expand to arterial roads in the future.

From a security perspective, the project incorporates “Privacy by Design” principles so that no data point can be directly connected with a particular phone.  To achieve this involves stripping incoming data of identifying information in addition to encrypting transmitted data and analyzing data on a need-to-know basis.  To further alleviate security fears, Mobile Millennium operates on a completely voluntary-basis and users can stop participating at any time.

Stakeholders
Despite the claims of system anonymity by the creators of Mobile Millennium, users are risking knowledge of their location and identifying information when they volunteer to participate.  Even in the case that the the project adheres to the aforementioned principles of Privacy by Design, there are certain cases in which one can infer user identity from location and external knowledge.  For example, if a participant habitually travels to an area devoid of other participants, then this individual’s movement can be monitored without the system explicitly mapping her data point to her person.  If this area happens to be her home address, then even more information is compromised.

From a more optimistic perspective, by design, Mobile Millennium can track whether participants are stranded on roads; one could easily imagine how this knowledge might facilitate increased precision and a more speedy response to emergency situations, stranded vehicles, etc.  (Thus, perhaps towing companies may be an indirect stakeholder as well.)

In addition,the participating device may witness a significant computational overhead, as it is constantly streaming data to Mobile Millennium servers.  If the technology becomes more main-stream, will this affect how cell phones are created?  Will this have an impact on the types of encryption that can be done, now that computing power is even more limited?

Because users are encouraged to have unlimited plans, the creators of Mobile Millennium themselves may be an indirect stakeholder; if this limitation prevents a certain demographic or region from participating, Mobile Millennium may end up studying traffic patterns of a limited subset of the population and draw biased conclusions.

In addition, citizens of the targeted region are direct stakeholders, even if they are not participants.  Supposedly anyone can check the status of traffic on Mobile Millennium’s website; this technology is intended to relieve areas of major congestion directly, or at least provide the means for the state Department of Transportation to improve infrastructure.  (Thus, one might consider the Department of Transportation another indirect stakeholder.)

Finally, the police department has a potential and indirect interest in the development of Mobile Millennium.  The lack of individual privacy in the project implementation (as well as the perception of such) may effect crime on the road.  This is further discussed in the “Adversaries” section.

Assets and Security Goals
As discussed above, the general privacy of participants should be a major concern of Mobile Millennium.  While the creators have certainly gone to some length to protect the identities of their users, it is not clear that such measures are enough to maintain true anonymity.

In addition, personal security may potentially be at stake; a user might not feel comfortable if strangers know that he is stranded on an isolated road in the middle of the night.  He might very well prefer to call a friend for help rather than alert Mobile Millennium of his distress.

Potential Adversaries and Threats
Though typically not portrayed as an adversary, the police have strong (and arguably, semi-justified)  motivation to infringe on user privacy rights. For example, if one can identify people via Mobile Millennium, it would be easier to find the aggressor of a hit-and-run incident.  It might be easier to track the whereabouts of or verify alibis of suspects.  Similarly, the federal government has an interest in breaking any privacy-ensuring mechanisms set in place by Mobile Millennium; such a breach would facilitate any tapping and/or tracking of individuals of interest.

The government may also have an interest (albeit, a different one) on the state and/or judicial level.  If they can even determine that a certain demographic frequents certain roads in certain patterns, this may induce a bias toward one class (e.g. a wealthier class) over another to increase revenue.

Potential Weaknesses
From a security perspective, there seems to be no way for a user who decides to stop participating to ensure that indeed their information is no longer being tracked by Mobile Millennium.  In addition, who is in control of the system?  If the control of the system gets into the wrong hands, are there mechanisms in place to ensure that an adversary can still do no harm despite having access to the centralized information?

Potential Defenses
To the weaknesses above, defenses might include mechanisms to ensure that a former participant is indeed no longer participating.  An extreme version of such a defense would be to get a new phone, but this is cumbersome; it should not be at the expense of the user to ensure his or her non-participation.  The claimed ability to be able to disable participation at any time is already a first line of defense against privacy issues and/or qualms had by the user.

Evaluation and Conclusion
Mobile Millennium proposes a new technology that allows the tracking of large group of people without explicitly identifying them.  However, with this technology comes a lot of privacy issues; in particular, it is questionable how much identifying information could be inferred without explicit mapping of data point to name.  Because there will always be conceivably special cases in which little information is needed to deduce a person’s association with a data point, it is extremely difficult to defend against this kind of privacy breach without refusing to participate in the first place.  One can think of addressing this potentially contrived case as a “worst case analysis”.  Any theoretical defense toward adding data points to make an inferred data point more anonymous debunks the very purpose of this study, which involves understanding the traffic patterns of real people.  While it seems that technology of this type poses severe privacy issues, it will inevitably become more mainstream because of the benefits that a system gains from tracking people (or things) within it.  In fact, a similar technology is already implemented in many hospitals as a way of tracking equipment, patients and staff.  (It should be noted, however, that this technology is restricted to the domain of the hospital and would not, for example, aid the police in tracking their suspects.)  Toward that end, it is increasingly necessary to resolve these issues in a way that renders the technology simultaneously respectful of individual privacy and contributing to society as a whole.

iGoogle is a personal web portal service of Google, which serves as a customizable start page to the Internet.  It was Google’s star product in 2007, whose traffic had increased by 267.64%.  In iGoogle, users can have several pages under different named tabs.  Users can add Google gadgets and RSS feeds to the pages.  Page layouts can be customized.  iGoogle is an open platform that anyone can create their own gadgets. Users can also share their iGoogle pages with others by sending out their pages with or without the settings for the contained gadgets.  Different from most other web portals, iGoogle dedicates large amount of space on top of its pages to Google’s own web search service.

There are many stakeholders of iGoogle.  Users are the most obvious and probably the most important direct stakeholders.  Google itself is a direct stakeholder as well.  It benefits not only because it can collect all kinds of information about its users, but also because users will be more likely to use its web search service — Google puts a big search box on the top. Creators of the Google gadgets are also direct stakeholders because they use iGoogle as the platform for their web applications. There are two kinds of indirect stakeholders. Those content (RSS) providers, such as New York Times, are indirect stakeholders because their RSS feeds can be directly added to iGoogle.  Advertisers are the other indirect stakeholders because iGoogle promotes Google’s web search service as mentioned.

One important asset of iGoogle is its handiness.  iGoogle has tons of useful and high quality gadgets for various scenarios and purposes. Users can put as much information as possible through it.  It also loads very fast which is important because most users use iGoogle quite frequently.  Actually, a great amount of users set iGoogle as their browser homepages.  Had iGoogle taken tens of seconds to load, it wouldn’t have been that popular.

Another asset of iGoogle is the users’ personal information. iGoogle gadgets, such as, weather, Gmail, calendar, to-do list and sticky notes, each contains very private information about users.  Being a collection of these gadgets, iGoogle is more privacy-sensitive than any single one of its gadgets.  Thus, keeping the private information safe is a very important security goal of iGoogle.

Towards these assets, there are several threats.  One is looking-over-shoulder attack.  It could be friends, or strangers, or hidden cameras, depending on where iGoogle is used.  It is a threat because by looking at one’s iGoogle pages from behind, the attackers can know a lot about the user, such as his or her interests, stocks and agenda of the day.  Another similar but more serious threat occurs when other people use your browser.  As many users set iGoogle as their browser homepages and never log out for convenience, no password is needed in order to open iGoogle on their browsers.  In such case, people who gain access to your browser will also gain access to all your private information on your iGoogle.

Another threat is eavesdropping on the network.  This is always a threat for network applications, but it is more serious for iGoogle as it does not encrypt the communication between client and server, and gadgets are responsible for their own communication with the corresponding services.

Since iGoogle is an open platform, one threat is the malicious gadgets.  As reported by media, users easily trust the gadgets found on Google’s gadget directory.  They don’t realize that these gadgets can be developed by anyone not just Google.  Also, since the malicious gadgets might be used along with other important gadgets like Gmail on the same page, they might be able to gain some access to these gadgets through some bugs in iGoogle or the browsers.  More easily, the malicious gadgets can just slow down the loading speed of the whole page, which directly harms the handiness asset of iGoogle.

I think iGoogle is weak against many of the above threats.  One is that, iGoogle uses “http” instead of “https”, which obviously could reveal what apps users are using to the eavesdroppers.  Also iGoogle does not show if the gadgets themselves are using secure connections or not.  For example, when using Gmail alone, one can notice that it uses https and there are other indications such as a lock in the status bar.  However, in the case of iGoogle, one cannot tell if the Gmail gadget is using “https” or “http”.  Users may thus make some wrong decision, for example, reading emails through a public WIFI.

Another potential weakness against eavesdropping is that the iGoogle pages appear highly frequently on the network, especially when being set as browser homepages.  This could definitely ease eavesdropping, as there is more redundancy.  I am not sure how much such redundancy will help the attackers, but the attackers do get more information about the encryption. Also when setting iGoogle as browser homepages, and seeing it over and over, users may lower their alertness against privacy leak as iGoogle becomes more a usual thing to them.

The “share” feature of iGoogle is another weakness against privacy leak, because it also enables users sending settings for gadgets along with the page to other users.  One case is that users might misunderstand the settings for gadgets as preferences for applications and send them.  They will be surprised that their sensitive information such as the contents in their sticky notes, and their calendars are also sent out.  Generally, what are sent depends on the implementation of each gadget.  The other case is that people who have gained access to one’s browser can send out his or her sensitive information by just a few clicks.

There are many possible defenses against the above-mentioned potential attacks.  One defense against the weakness of the “share” feature is asking for authentication (password) before sending out the settings for gadgets instead of just giving out warnings as in the current iGoogle.  The result is that malicious people can no longer send out all the private information easily.

Another defense against looking-over-shoulder attack is to hide iGoogle pages when users are accessing iGoogle using an unrecognized IP address.  This can prevent occasional privacy leak when getting online using WIFI in a public area.  Some browser extensions can also be helpful by using more complex detection mechanisms.

As for secure connection, iGoogle could also let users to decide whether or not to use “https”, as Google has done in Gmail.  Since “https” may slow down the page, it is possible in some cases that users prefer faster loading.

iGoogle could also provide some indication on whether or not the gadgets are using secure connections.  For example, putting a lock icon on the gadget’s title bar to indicate that the gadget is using secure connection.  Such indication is important in helping users make the right decision.

As iGoogle keeps growing, the security issues mentioned can become more and more important.  If not taken seriously, users’ privacy can be easily revealed to malicious people or organizations.  As web browsing becomes more and more important in our daily life, iGoogle will be much more valuable.  It can grow into a platform for all kinds of web applications, and a personalized mash-up center, and a true start page to the Internet.  And when more and more private information are placed through iGoogle, Google must provide better and complete mechanisms for protecting users’ privacy in all contexts.

The security issues mentioned above are not alone with iGoogle, but also with all other web portal services such as Netvibes, My Yahoo, and Windows Live.  Currently, developers have been focused on creating more useful and prettier gadgets in order to attract users.  Less work has been done to improve the security of the platform.  Users also haven’t yet paid attention to these issues, even though they are aware of these issues when using similar services separately, for example, Gmail.  The success of iGoogle not only shows the potential of web portals but also emphasizes these security issues.  If there is something goes wrong, even if it is the fault of a third party gadget, Google will definitely be blamed.  I like iGoogle a lot. It is fast, open, and has a lot of gadgets. I hope to see more security concerns from Google, as I already have tons of private information there.