Document Overview

Feature/Product:	Geolocation API
Projected Feature Freeze Date:	27-Apr-2012
Product Champions:	Doug Turner & Joshua Dhaliwal
Privacy Champions:	Joshua Dhaliwal?
Security Contact:	Curtis Koenig
Document State:	[NEW]

Timeline:

Architectural Overview:	10-Apr-2012
Recommendation Meeting:	10-Apr-2012
Review Complete ETA:	10-Apr-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.

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

Page Holding Location Request

Page requests to convert a location to a civic address
This request is sent to our Geolocation API

Stored Data: None.

Data In: location data, callback functions

Mozilla Geolocation API

Our API handles the request by asking the user for permission to use geolocation
- Not sure if we should be asking for permission if website is not requesting the user's location (ie. just converting an arbitrary location into a civic address)
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: location data
- Data In: location data, callback functions
- Data Out: lat/long from location data

Platform Reverse Geocoding API (3rd-Party)

The 3rd party reverse geocoding API would then reverse geocode this lat/long into a civic address and pass it back to our API
- 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: possibly lat/long of the location data
- Data In: lat/long of location data
- Data Out: civic address of location

Mozilla Geolocation API

We then recieve the civic address back from the platform API, the address is then passed back to the page holding the request from a success callback

Stored Data: reverse geocoded address of the location's lat/long data given to the platform reverse geocoding API
- Data In: civic address of location
- Data Out: civic address of location

Page Holding Location Request
- The page then does whatever it intended to do with the address

Stored Data: the same reverse geocoded address of the location's lat/long data
- Data In: civic address of location

User Data Risk Minimization

Areas of Risk

Dealing with the 3rd party platform APIs
- If the 3rd party is not trusted, then this location data may be compromised
  - This may or may not be harmful to the user, as the location may be arbitrary, or may be the user's location

Properly storing this location data within the Firefox application
- Possibility of exploits to obtain the location data from outside sources?

Alignment with Privacy Operating Principles

In this section, the privacy champion will identify how the feature lines up with Mozilla's privacy 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

Privacy/Reviews/GeolocationAPI

Contents