In many ways people are looking forward to HTML 5 and its expanded list of features. However, there's a number of aspects that have privacy advocates worried. In particular, people are concerned about geolocation. Fortunately the W3C (news, site) is working on solutions.

The Concern

At the W3C Workshop on Privacy for Advanced Web APIs, one of the topics was the Geolocation API Specification. Experts from Google (news, site), Opera Software (news, site) and the Goethe University in Frankfurt, Germany spoke about their experience with handling geolocation information so far, and privacy concerns this experience raised regarding the API.

The Geolocation API Specification states that those implementing the API for user agents (such as browsers) must:

  • Not send location information to websites without the user's permission
  • Request permission through the user interface except for "prearranged trust relationships"
  • Include the URI of the document's origin so the user can inspect it
  • Allow users to revoke permission later in the case of preserving the location permission settings between browser settings

There are also guidelines for those who receive location information, such as:

  • Only request location information when necessary
  • Only use the location information for the tasks it was requested for
  • Dispose of location information once the task is complete, unless granted permission to retain it
  • Protect location data from unauthorized access
  • Allow users to delete and update location information that is stored

As nice as guidelines are, with such highly-charged privacy issues you have to make sure people follow the rules. Enforcement and verification of such complex needs is not a trivial manner. Neither is figuring out the best way to do it.

Google's Take

Jochen Eisinger from Google focused on the Google Chrome team's experience. One issue he brought to light was the question of what to do in the situation where you have obtained the proper permissions to access someone's location information, but there are iframes or other embedded content that also want to access this information.

His concern was that even if a developer felt sure that the user's data was safe by letting a site use their location data on a Google map, users may not agree. Worse, confusion could result as non-technical users saw their locations appearing on sites they never authorized.

Opera's Take

Marcos Caceres with Opera Software expressed concern that the "click to confirm" model when requesting location information gives the user no idea of how their location will be derived (from the GPS, WIFI, cellular network, a web service, etc), and therefore whose privacy policies apply. Worse, he adds (regarding the iPhone and Mobile Safari):

  • The iPhone provides no way to view or change your geolocation provider or possible encryption settings
  • iPhone geolocation privacy policies are buried three-levels deep in the Settings menu's Legal option, which contains "about 50 pages of legalese and no searchable index!"
  • On Mobile Safari, once a user grants an application access to geolocation services three times, the system grants access to location services forever, or until the device is reset, even after clearing the cache, history and cookies

Goethe University's Take

Ioannis Krontiris with the Goethe University and his team were concerned in particular about two issues. One is that of privacy violations from combining geo-location data and browser cookies. Another is the fact that services requesting location information keep records of these requests and the responses. In the case of services like Google Maps that are used repeatedly, this means the services and location service providers have logs of where people have been over time.

In their paper, the team states: "Even though the specification tries to remain agnostic concerning user’s identity, significant risks emerge by the centralized approach taken. What we find critical is the use of unique identifying information to link subsequent location requests back to the same user and build the mobility path, mobility pattern and mobility profile of a particular user. This could allow the extraction of endpoints like home or work place of an individual and eventually lead to his identification."

Possible Solutions

Many possible solutions were discussed as part of the workshop. One suggestion from Eisinger and his team was to store user preferences by both:

  • The origin of the top-level document
  • The origin of the resource requesting their location

Storing preferences in this more complex manner lets users explicitly control which sites can show embedded content. For an example, see the image below:


In Google Chrome, this user authorized to know their location, along with Google Maps embedded on

Caceres and his team found some benefits to the way desktop browsers handled geolocation requests, with Firefox, Opera and Chrome all offering an "information bar" model that lets a user deny a request but still browse the website. If the user then decides they're comfortable giving the site their geolocation information, they can authorize it later. They also liked the Chrome browser's configuration window for seeing which sites you've authorized and whether the requests were made by the site itself or embedded components.

Meanwhile, Krontiris and his team would like to see more tools on mobile devices that let users control their privacy settings. Such tools fall into two major classes:

  • Monitoring applications, which run in the browser's background and user preference settings warn the user when private data is about to be exposed
  • Control applications, which might suppress unnecessary browser information when a site requests location data

Overall, many agree that the Geolocation API Specification will never contain all of the answers to the problem of user location privacy. Additional requirements and methods are needed for those who make browsers as well, along with the will to do right by the user. Ultimately, the browser which best handles geolocation options will gain an edge with technical users. Whether that same edge will apply to mainstream users remains to be seen, but let's not forget that Firefox shoved Internet Explorer aside even with the mainstream crowd.

For more details on other issues brought up during the Workshop and other recommendations, see the W3C Workshop on Privacy for Advanced Web APIs page and the papers linked throughout.