Privacy/Reviews/Wheres My Fox

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:	[NEW]

Timeline:

Architectural Overview:	(date TBD)
Recommendation Meeting:	(date TBD)
Review Complete ETA:	tbd

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

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.

Component X

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.

Stored Data:

What	Where
data type	where stored

Communication with Component Y

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

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)

Recommendations: (what can be improved)

Principle: Real Choice

Recommendations:

Principle: Sensible Defaults

Recommendations:

Principle: Limited Data

Recommendations:

Follow-up Tasks and tracking

What	Who	Bug	Details
[NEW] Initial Overview Discussion	?		Meeting time TBD