Privacy/Reviews/GeolocationAPI: Difference between revisions
No edit summary |
|||
Line 4: | Line 4: | ||
|'''Feature/Product:''' || Geolocation API | |'''Feature/Product:''' || Geolocation API | ||
|- | |- | ||
|'''Projected Feature Freeze Date:''' || <section begin='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:''' || | |'''Privacy Champions:''' || Joshua Dhaliwal? | ||
|- | |- | ||
|'''Security Contact:''' || Curtis Koenig | |'''Security Contact:''' || Curtis Koenig | ||
Line 19: | Line 19: | ||
{| | {| | ||
|'''Architectural Overview:''' || | |'''Architectural Overview:''' || 10-Apr-2012 | ||
|- | |- | ||
|'''Recommendation Meeting:''' || | |'''Recommendation Meeting:''' || 10-Apr-2012 | ||
|- | |- | ||
|'''Review Complete ETA:''' || <section begin='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:''' ( | '''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''': | ||
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. | ||
'''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 = | = 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 = | = Alignment with Privacy Operating Principles = | ||
Line 90: | Line 116: | ||
(How the feature addresses this) | (How the feature addresses this) | ||
''Recommendations'': ( | ''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
- If the 3rd party is not trusted, then this location data may be compromised
- 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 |