MozillaWiki

Privacy/Reviews/GeolocationAPI: Difference between revisions

Page Discussion

Privacy/Reviews/GeolocationAPI (view source)

Revision as of 16:48, 2 July 2012

4,283 bytes added ,  2 July 2012
→‎Follow-up Tasks and tracking
 
(12 intermediate revisions by 3 users not shown)
Line 12: Line 12:
|'''Security Contact:''' || Curtis Koenig
|'''Security Contact:''' || Curtis Koenig
|-
|-
|'''Document State:''' || <section begin='status'/>{{ok|documenting}}<section end='status'/>
|'''Document State:''' || <section begin='status'/>{{ok|pending team responses}}<section end='status'/>
|}
|}


Line 23: Line 23:
|'''Recommendation Meeting:''' || n/a
|'''Recommendation Meeting:''' || n/a
|-
|-
|'''Review Complete ETA:''' || <section begin='revieweta' />May-2012<section end='revieweta' />
|'''Review Complete ETA:''' || <section begin='revieweta' />June-2012<section end='revieweta' />
|}
|}


Line 42: Line 42:
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.
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:  
There are three components:
- 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.  
# The content (untrusted) page requesting the location
- Location data in this context is equivalent to the coordinates interface as described in the W3C Geolocation API documentation here:
# The Geolocation API (Gecko)
    http://dev.w3.org/geo/api/spec-source.html#coordinates_interface'''
# 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===
===Page Holding Location Request===
Line 63: Line 67:
|-
|-
| ''In:''  
| ''In:''  
| success callback function (defined in application's Javascript)
| successCallback
| Civic address data
| Civic address data
|  
| Callback is defined in application's Javascript
|-
|-
| ''Out:''  
| ''Out:''  
Line 79: Line 83:
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 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.


* 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)
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.
 
''Sid: Yes, we should ask if the user has not beem prompted for that site.  Do we allow third party content (iframes on the page, for instance) to invoke this API?''
 
''TODO: verify that we 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.
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.
Line 94: Line 94:
! Where
! Where
|-
|-
| location data  
| Location data: nsIDOMGeoPositionCoords object
| nsIDOMGeoPositionCoords object stored as an nsCOMPtr property in the request 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.
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.
'''Note:''' "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


'''Communication with page requesting location data:'''
'''Communication with page requesting location data:'''
Line 116: Line 114:
|-
|-
| ''In:''  
| ''In:''  
| apiEndpoint return
| Return from Geocode API
| specific types of data received from Geocoding API with this API call
| Address object(s)
|
| return from 3rd party API (such as Android's getFromLocation)
|-
|-
| ''Out:''  
| ''Out:''  
| apiEndpointCall
| Call to Geocoding API  
| specific types of data sent to Geocoding API with this API call
| Latitude and longitude
|  
| 3rd party API (such as Android's getFromLocation)
|}
|}


''TODO: document the API here -- what are the third party request API call names?  What data (specifically) do we send them and what do they return?'''
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)===
===Platform Reverse Geocoding API (3rd-Party)===
Line 142: Line 144:
= User Data Risk Minimization =
= User Data Risk Minimization =


'''Areas of Risk'''
=== Location Disclosure ===
* Dealing with the 3rd party platform APIs
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. 
** 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
''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.
 
{{ResolutionBox|{{ok|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).
 
{{ResolutionBox|{{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.


* Properly storing this location data within the Firefox application
''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.
** Possibility of exploits to obtain the location data from outside sources?
 
''Requirement'': store addresses and longitude/latitude coordinates in volatile memory only (not on disk or in cache).
 
{{ResolutionBox|{{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.
 
{{ResolutionBox|{{new|verify that only the top-level page can use this API.}}}}


= Alignment with Privacy Operating Principles =
= Alignment with Privacy Operating Principles =
Line 157: Line 191:


====Principle: Transparency / No Surprises====
====Principle: Transparency / No Surprises====
(How the feature addresses this)
This feature prompts users before giving content access to the geocoding API.  Users who have allowed the current page to obtain their location through the other geolocation API will not be prompted, though they have already authorized location services on the current page.


''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.)
''Recommendations'': Let the user know that this function MAY involve the data associated with their location(s) (ie. from geo-tagged photos, etc.) Update the prompt message to say this.
 
{{ResolutionBox|{{new|}}}}




====Principle: Real Choice====
====Principle: Real Choice====
This feature will prompt the user for permission for use of this feature through use of an on-screen prompt. The prompt is simple and allows the user to continue using the current web site without granting access to this service.


''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.
''Recommendations'': None.


====Principle: Sensible Defaults====
====Principle: Sensible Defaults====
This feature is disabled by default and when a site requests access, the user will be asked for permission.  The prompt is tied into other geolocation services too -- the user will be prompted only once per site per session (so there will not be a flood of prompts for each call to this API).  The effect is that the user will be prompted once to allow a site to access location services, then not again for that session on that site.


''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.
''Recommendations'': None.


====Principle: Limited Data====
The data being shared to 3rd party platforms is only the bare minimum data that can be shared for the services requested. All other location data being stored in the browser is stored only in memory (not on disk).


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


''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.
{{ResolutionBox|{{new|verify that location data encountered by this feature is kept in memory only (not on disk).}}}}


= Follow-up Tasks and tracking =
= Follow-up Tasks and tracking =
Line 183: Line 223:
! Details
! Details
|-
|-
| {{new|Initial Overview Discussion}}
| {{done|Architectural documentation}}
| ?
| Joshua Dhaliwal
|
| April/May-2012
|-
| {{done|Risk Analysis}}
| Sid Stamm
|
| 4-June-2012
|-
| {{done|Public Review}}
| [https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.planning/VTf_b2_-Cc8 dev.planning]
|  
|  
| Meeting time TBD
| no comments
|-
|{{new|follow-up tasks}}
|
|follow-up tasks above need to be resolved
|-
|}
|}




[[Category:Privacy/Reviews|Template]]
[[Category:Privacy/Reviews|GeocodingAPI]]
Curtisk
canmove, Confirmed users, Bureaucrats and Sysops emeriti
2,776

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/429289...447058"