Privacy/Reviews/Wheres My Fox
Contents
Document Overview
| Feature/Product: | Where's My Fox |
| Projected Feature Freeze Date: | (tbd) |
| Product Champions: | JR Conlin |
| Privacy Champions: | Curtis Koenig |
| Security Contact: | Yvan Boily |
| Document State: | [DONE] |
Timeline:
| Architectural Overview: | N/A |
| Recommendation Meeting: | N/A |
| Review Complete ETA: | 2014-04-23 |
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: Provide customers with a means to securely locate, alert and erase their mobile device.
Design Documents: https://wiki.mozilla.org/Services/WheresMyFox#Cloud_Services_Back-End_Design
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.
- Client Component
- Uses Firefox Accounts / Persona for user Authorization
- Provides UI for registering for, and enabling / disabling the service
- Receives commands from the server and executes them
- Sends location information to the server, but doesn't store it
- Erases the user's data at the request of the server
- Server Component
- Uses Firefox Accounts / Persona for user Authorization
- Provides web based UI for phone tracking and control
- Provides commands to device
- Receives and stores tracking information
- Displays device location using Mapbox Mapping UI.
- Manages data storage on AWS RDS.
Persona / Firefox Accounts
Users need to identify themselves to both the device and to the back-end. To accomplish this, we've chosen to use Firefox Accounts (defaulting to Persona until Firefox Accounts is considered production ready). When a device registers the user sends the FxA assertion, and a SimplePush URL to the server. The Assertion is validated, and a SHA256 hash is generated from the email(UserID) in lieu of the FxA ID, the device is then assigned a UUID4(DeviceID). The UserID and DeviceID are then associated and stored in the database. The DeviceID is returned to the device, which then uses this value in subsequent calls. In addition, the server returns a HAWK Secret for subsequent exchanges between the device and the server.
Exchanged Data:
| Direction | Message | Source | Data | Notes |
|---|---|---|---|---|
| In: | /1/register | Client | JSON block containing the following { ValidationAssertion, PushURL, DeviceID, Passcode Boolean, Accepts} | ValidationAssertion - The FxA/Persona assertion result from the client login.
PushURL - SimplePush URL for the device. DeviceID - [optional] Device ID (if the device has already registered). Passcode Boolean - Does the device have a passcode already set? This prevents the site from sending an overriding passcode which may lock users off of their own device. Accepts - A subset of valid commands available for the device. |
| (validation response) | Persona/FirefoxAccounts | JSON block containing user email | ||
| Out: | verify assertion | Persona/FirefoxAccounts | Assertion | Returns assertion content including user email. |
| registration response | Server Component | JSON: {DeviceID, HAWK Secret} | DeviceID - UUID4
Secret - HAWK secret for subsequent command checks. (This changes for each registration, invalidating the older Secret, if it exists) |
AWS RDS
User data must be stored in order for the system to be useable and scalable. To that end, efforts have been made to minimize the amount of user identifiable information that is stored or meaningful outside of the system.
"Old" Location data is deleted from the database after 15 minutes, and only the last known location reported by the device is retained.
In addition, a table must be maintained that stores pending device commands. This may include the outbound lock code. These pending commands are removed immediately after the device has received the commands.
Stored Data
| Table | Column | Data | Notes |
|---|---|---|---|
| deviceInfo | deviceID | UUID4 | |
| name | User friendly name for device | defaults to the local part of the verification email address | |
| lockable | boolean flag indicating if device is lockable | If a device does not have a local lock code, it is considered lockable from this app's perspective | |
| loggedin | obsolete | ||
| lastExchange | UTC of last data exchange between server and client | ||
| hawkSecret | shared secret for HAWK communication from device | ||
| pushUrl | SimplePush URL for sending notifications to the device | ||
| accepts | subset of device accepted commands. | ||
| pendingCommands | id | serialNumber for commands | |
| deviceId | target device id | ||
| time | timestamp of when the command was submitted | ||
| cmd | command JSON string for device | ||
| position | id | serialNumber for positions | |
| deviceId | target device id | ||
| time | time record was recorded | ||
| latitude | device latitude | ||
| longitude | device longitude | ||
| altitude | not currently used | ||
| userToDeviceMap | userId | SHA256Hash of user email | |
| deviceId | associated device | ||
| name | user friendly name for device |
Mapbox APIs
See Mapbox .js Developer Guide for full details.
These Javascript API calls are used to display device location to the user. These APIs receive only a lat. and lon. in order to render a marker for display. There is no other information sent to this API.
Client / Server interactions
Clients use HTTPS calls to both provide information and retrieve commands from the Server. HTTPS was chosen for a number of reasons, related to battery life and general connectivity. Each command request is signed with HAWK using the previously exchanged Secret.
Message Flow
| Origin | Target | Medium | Action | Response |
|---|---|---|---|---|
| Server | Client | SimplePush | Action Event | Device connects to server |
| Client | Server | POST https:/1/cmd/deviceid | Server responds with next pending command | |
| Client | Server | POST https:/1/cmd/deviceid | Command reply/ack | Server responds with next pending command |
| command | arguments | action | response |
|---|---|---|---|
| "r"ing | "d"uration in seconds | cause phone to ring for duration in seconds. A duration of 0 will cause the phone to stop ringing | "ok": true |
| "l"ock | "c"ode, a 4 digit value
"m"essage, a 100 character maximum ASCII message to be displayed on the lock screen. |
if the phone does not already have a set lock code (identified by the has_lockcode boolean returned by the device), the new lock code is set and the device is locked. | "ok": true |
| "e"rase | Erase the contents of the "apps", "pictures", "sdcard", "videos" and "music" areas of Device Storage, and factory resets the phone. | ||
| "t"rack | "d"uration in seconds | cause the phone to return tracking information at a regular period for duration seconds. | "latitude":, "longitude":, "altitude":, "time":, "has_lockcode": |
Client Component
The Client component implements the UI for registering to the service, and enabling or disabling it at any time at the user's discretion. It also executes the commands received from the server. The UI is implemented within the Settings app, and the rest of the client logic is implemented in a certified app of its own.
The only data stored by the client is the server's response to the initial registration, as summarized in the table below.
Stored Data:
| What | Where |
|---|---|
| deviceId | IndexedDB storage inside the Find My Device certified app |
| hawkSecret | IndexedDB storage inside the Find My Device certified app |
The client may also temporarily store the return values for commands (which may include user location) in the event of a failure to communicate with the server. This information is never persisted permanently.
If the service is disabled through the Settings app, the client stops communicating with the server entirely, but keeps its state (both the persistent information in the table above and the temporary return values for commands) so that it can continue operating if re-enabled.
User Data Risk Minimization
In this section, the privacy champion will identify areas of user data risk and recommendations for minimizing the risk.
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) The feature must be enabled explicitly on a device before the device will register and the service can be used. Given the use case for the feature it's fairly obvious to a user that data will be gathered in order to provide a tangible service to locate a lost device.
Recommendations: We should include a link to that user can choose to follow that shows exactly what data will be gathered as well as our privacy policy.
- bug 994317 Should link to privacy policy and data that is collected for Where's My Fox
Principle: Real Choice
This feature requires direct user action to be enabled and if a user disables the feature all gathered data will age out and no longer be gathered.
Recommendations:
Principle: Sensible Defaults
The feature is off by default and purges information at 15min intervals.
Recommendations:
Principle: Limited Data
The feature only gathers the data necessary to ensure that a given user is given the proper location data for a given device.
Recommendations:
Follow-up Tasks and tracking
| What | Who | Bug | Details |
|---|---|---|---|
| [DONE] Public Comment closed | Curtisk | https://groups.google.com/forum/#!topic/mozilla.dev.planning/sDCuDrLyTcs | 2014.04.23 |
| [NEW] | bug 994317 Privacy policy and link to gathered data | ||
| [NEW] | bug 1000164 - Request a lock code when one is not set when enableing Where's My Fox / Find My Device | ||
| }} | bug 1000173 - Display a user visible icon when enableing Where's My Fox / Find My Device |
