Privacy/Reviews/GeolocationAPI

Document Overview

Feature/Product:	Geolocation API
Projected Feature Freeze Date:	27-Apr-2012
Product Champions:	Doug Turner & Joshua Dhaliwal
Privacy Champions:	Sid Stamm
Security Contact:	Curtis Koenig
Document State:	[ON TRACK] risk analysis

Timeline:

Architectural Overview:	10-Apr-2012
Recommendation Meeting:	n/a
Review Complete ETA:	June-2012

Architecture

In this section, the product's architecture is described. Any individual components or actors are identified, their "knowledge" or what data they store is identified, and data flow between components and external entities is described.

The main objective of this feature/product is: To make changes to the existing geolocation WebAPI in order to allow web developers to convert an arbitrary location (given in latitude and longitude) into civic mailing address for increased user readability.

Design Documents:

http://arreth.wordpress.com/2012/03/14/ch-ch-ch-ch-changes-to-geolocation-api-specifcations-2-2/

http://arreth.wordpress.com/2012/03/13/proposed-changes-to-geolocation-api-specification/

Components

Describe any major components in the system and how they interact. Also include any third-party APIs (those Mozilla does not control) and what type of data is sent or received via those APIs.

There are three components:

1. The content (untrusted) page requesting the location
2. The Geolocation API (Gecko)
3. The Reverse Geocoding service (e.g., Google)

NOTE:

• All Location data mentioned in this section may pertain to the user's location data (retrieved by another function), or to any arbitrary location data.
• Location data in this context is equivalent to the coordinates interface as described in the W3C Geolocation API documentation here: http://dev.w3.org/geo/api/spec-source.html#coordinates_interface

Page Holding Location Request

A web page requests help from our API to convert a location to a civic address. This request is sent to our Geolocation API, which brokers communication with a third party geocoder and then returns the resulting civic address to this page.

Stored Data: None relevant.

Communication with Geolocation API:

Direction	Message	Data	Notes
In:	successCallback	Civic address data	Callback is defined in application's Javascript
Out:	getAddress	Location data, along with success and error callbacks, and options for the request

Mozilla Geolocation API

This is a browser component in privileged code that brokers communication between the page requesting the location information and the third party location services. This component begins to handle the request by asking the user for permission to use geolocation.

This API will prompt the user for permission even if website is not requesting the user's location (ie. just converting an arbitrary location into a civic address). This is because it calls a third-party API with arbitrary data. We are planning to have the implementation only ask permission if the user has not currently authorized other geolocation activity on the page.

If permission is given, this request is processed, and the location's lat/long is then sent to the platform's reverse geocoding API (if available). If not, the request is not performed, and the interaction stops here.

Stored Data:

What	Where
Location data: nsIDOMGeoPositionCoords object	stored as an nsCOMPtr property in the request object (memory only)

The civic addresses are not stored in this component, and are only retrieved and passed as parameter arguments to/from the third party geocoding API. No actual civic address object is being stored in this component. The location data stored in this component are provided by the page holding location request and may or may not have been obtained through the other geolocation API.

Communication with page requesting location data:

(See "Page Holding Location Request" component for communications with that component.)

Communication with 3rd Party Geocoding API:

Direction	Message	Data	Notes
In:	Return from Geocode API	Address object(s)	return from 3rd party API (such as Android's getFromLocation)
Out:	Call to Geocoding API	Latitude and longitude	3rd party API (such as Android's getFromLocation)

The 3rd party APIs vary from platform to platform, but we would only ever be handing over the latitude and longitude to these 3rd party APIs. For example, on the Android platform, we use a call to getFromLocation(double, double, int) (documented here: http://developer.android.com/reference/android/location/Geocoder.html).

This call would return a list of Address objects, which should be of the general form that is documented here: http://arreth.wordpress.com/2012/03/13/proposed-changes-to-geolocation-api-specification/

On the Android platform, the Address objects are of the form documented here: http://developer.android.com/reference/android/location/Address.html

Platform Reverse Geocoding API (3rd-Party)

On request, the 3rd party reverse geocoding API reverse geocodes lat/long into a civic address and passes it back to the Mozilla Geolocation API.

NOTE: 3rd party API should be from a trusted source to ensure that IF we are actually using the user's location data, then it is not compromised

Stored Data: Unknown -- this third party is out of Mozilla's control. Potentially they could store any data we send them via the Mozilla Geolocation API.

Communication with Mozilla Geolocation API:

(See "Mozilla Geolocation API" component for communications with this component.)

User Data Risk Minimization

Location Disclosure

The Geocoding API service provider may be different than the location provider, and potentially may learn the location of Firefox users who encounter pages using this API.

The Risk is that, since this feature is sending longitude and latitude to the Geocoding service, the user may be leaking his location to an unknown third party.

Recommendation: If possible, make sure the location is obtained from the same service provider that is used for geocoding. This way, the same entity is used for both operations, reducing any surprise when users identify with whom their coordinates are shared.

Requirement: Ensure the user is aware when this Geocoding API is activated.

Resolution:

[ON TRACK] User is prompted for authorization unless other Geolocation services are used on the same page. Do we use the same organization for both geolocation and geocoding?

Geographical Tracking

As the user physically changes location (with a mobile device, laptop, etc), he may also frequently visit sites that use geocoding. As a result, the geocoding service is exposed to the user's location at multiple points in time and space.

The Risk is that the geocoding service will be able to tie multiple requests together into a trail of locations corresponding to an individual's movements. This problem is present also in other geolocation services, not just geocoding.

Requirement: Ensure no other client-state data are transmitted to the geocoding service (cookies, etags/cache tags, last-access timestamps, etc).

Resolution:

[NEW] make sure requests to the geocoding API are stateless and anonymous

Local Traces

Calls to and from the geocoding API may be cached locally. The side-effect of this are that these data could form a "tracking record" of everywhere the users' browser activated geocoding -- a series of addresses where the user probably physically sat.

The Risk is that the locations will be persisted longer than necessary and may become discoverable by others who access the device; this leaks the user's physical location history to another person, probably without consent.

Requirement: store addresses and longitude/latitude coordinates in volatile memory only (not on disk or in cache).

Resolution:

[NEW] verify that location data encountered by this feature is kept in memory only (not on disk).

Confused Origin

Web pages are often composed of objects and frames from many different web sites. An iframe or subordinate resource on a page may trigger access to the geocoding API. Consider a map widget in an iframe; it may want location information geocoded into an address for display, but might be served by "thirdpartymaps.com" instead of the main page.

The Risk is that it will not be clear to the user which part of the page (which origin) caused the geolocation request.

Requirement: make it obvious who is requesting the call to the API.

Recommendation: allow only script running in the context of the top-level document (the one displayed in the address bar) to make requests to this API.

Resolution:

[NEW] verify that only the top-level page can use this API.

Alignment with Privacy Operating Principles

In this section, the privacy champion will identify how the feature lines up with Mozilla's privacy operating principles.

See Also: Privacy/Roadmap_2011#Operating_Principles:

Principle: Transparency / No Surprises

(How the feature addresses this)

Recommendations: We should let the user know that this function MAY involve the data associated with their location(s) (ie. from geo-tagged photos, etc.)

Principle: Real Choice

Recommendations: We plan to ask the user for permission for use of this feature through use of an on-screen prompt. This may be appropriate for this feature? Need to discuss.

Principle: Sensible Defaults

Recommendations: No real defaults involved, since we plan to ask permission for this feature. If future plans don't involve this process, then the default use will be to allow reverse geocoding of locations, since the location itself may be arbitrary and have most likely have no risk to the user. Again, we need to discuss this point.

Principle: Limited Data

Recommendations: The data being shared to 3rd party platforms is only the bare minimum data that can be shared. All other location data being stored is dealing with the Firefox browser itself, and is our responsibility.

Follow-up Tasks and tracking

What	Who	Bug	Details
[NEW] Initial Overview Discussion	?		Meeting time TBD