Privacy/Reviews/Wheres My Fox

From MozillaWiki
Jump to: navigation, search

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]


Architectural Overview: N/A
Recommendation Meeting: N/A
Review Complete ETA: 2014-04-23


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:


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)


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

In short the flow is:
  • Server sends a SimplePush alert to device
  • Device POSTs command from server (via a HAWK signed request)
  • Device processes command and responds to server with requested data/acknowledgement (HAWK signed).
  • Server replies with any additional pending commands.
  • rinse, repeat.
Command Structure and responses
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.


Principle: Sensible Defaults

The feature is off by default and purges information at 15min intervals.


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.


Follow-up Tasks and tracking

What Who Bug Details
[DONE] Public Comment closed Curtisk!topic/ 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