Privacy/Reviews/GeolocationAPI: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 4: Line 4:
|'''Feature/Product:''' || Geolocation API
|'''Feature/Product:''' || Geolocation API
|-
|-
|'''Projected Feature Freeze Date:''' || <section begin='eta' />(tbd)<section end='eta' />
|'''Projected Feature Freeze Date:''' || <section begin='eta' />27-Apr-2012<section end='eta' />
|-
|-
|'''Product Champions:''' || Doug Turner & Joshua Dhaliwal
|'''Product Champions:''' || Doug Turner & Joshua Dhaliwal
|-
|-
|'''Privacy Champions:''' || (the privacy Friend you're working with)
|'''Privacy Champions:''' || Joshua Dhaliwal?
|-
|-
|'''Security Contact:''' || Curtis Koenig
|'''Security Contact:''' || Curtis Koenig
Line 19: Line 19:


{|
{|
|'''Architectural Overview:''' || (date TBD)
|'''Architectural Overview:''' || 10-Apr-2012
|-
|-
|'''Recommendation Meeting:''' || (date TBD)
|'''Recommendation Meeting:''' || 10-Apr-2012
|-
|-
|'''Review Complete ETA:''' || <section begin='revieweta' />tbd<section end='revieweta' />
|'''Review Complete ETA:''' || <section begin='revieweta' />10-Apr-2012<section end='revieweta' />
|}
|}


Line 30: Line 30:
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.  
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:''' (describe the goals of the feature/product here)
'''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''':  
'''Design Documents''':  
Link to any design or architectural documents here.
 
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  ==
== Components  ==
Line 39: 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.


=== Component X  ===
'''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
 


This component does A, B and C and interacts with component Y to do D.


The tables below simply summarize the data encountered by this component.
'''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


'''Stored Data:'''


{| class="wikitable"
|-
! What
! Where
|-
| data type
| where stored
|}


'''Communication with Component Y'''
* Page Holding Location Request
** The page then does whatever it intended to do with the address


{| class="wikitable"
Data In: civic address of location
|-
! Direction
! Message
! Data  
! Notes
|-
| ''In:''
| message 1
| types of data received from component Y with the message
|
|-
| ''Out:''
| message 2
| types of data sent to component Y with the message
|
|}


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


= User Data Risk Minimization =
= User Data Risk Minimization =


In this section, the privacy champion will identify areas of user data risk and recommendations for minimizing the risk.
'''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 =
= Alignment with Privacy Operating Principles =
Line 90: Line 116:
(How the feature addresses this)  
(How the feature addresses this)  


''Recommendations'': (what can be improved)
''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====
====Principle: Real Choice====


''Recommendations'':  
''Recommendations'': We plan to ask permission for use of this feature. This may be appropriate? Need to discuss.




====Principle: Sensible Defaults====
====Principle: Sensible Defaults====


''Recommendations'':
''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====
====Principle: Limited Data====


''Recommendations'':
''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 =
= Follow-up Tasks and tracking =

Revision as of 19:25, 5 April 2012

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

Data In: civic address of location

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

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.

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 permission for use of this feature. This may be appropriate? 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