Privacy/Reviews/KPI Backend

Document Overview

Feature/Product:	KPI Backend
Projected Feature Freeze Date:	End of Q2
Product Champions:	Austin King
Privacy Champions:	TBD
Security Contact:	TBD
Document State:	[ON TRACK] needs more info

Timeline:

Architectural Overview:	TBD
Recommendation Meeting:	TBD
Wrap-up Meeting:	(if necessary)

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 allow the BrowserID product team to access how well changes to the service are meeting key performance indicators (KPI). UX will design a feature change, engineering will build it and a KPI Dashboard will give us the feedback of how successful the change is with real users.

KPI Backend must be built before we build the KPI Dashboard, which will be built next quarter and have it's own privacy review. KPI Backend stores the raw data described below.

Design Documents: Link to any design or architectural documents here.

• Main Feature Issue
• Mailing list discussion
• Work Week scratch pad

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

The client portion of the KPI feature is the HTML/Javascript that runs in a user's browser when they sign into a website using Persona Sign-In on a browser without native support. The dialog that is displayed records interactions and timing information, building a JSON data structure during interaction with the dialog. This JSON data structure is then sent to Persona Sign-In servers at the end of the interaction.

Server Component

Persona ID is currently implemented in two data centers with six "webheads", frontline web servers receiving requests from client devices. For this feature each webhead will expose a new API that accepts JSON data and forwards it to data storage servers. Data will be retained forever or purged based on resource usage. Historical data will be valuable for guiding the teams design decisions.

We reserve the right to sample data, but will start with 100% intake.

The client accessible API is: /wsapi/interaction_data

The API requires an HTTP POST with a CSRF token. The JSON document described above is the payload. The server returns a 200 on successful storage, and a non-500 otherwise. In the event of failure, the client may store the blob in localStorage and retry transmission at a later point.

Data Storage Component

Persona Sign-In webheads (Server Component) serve as simple forwarders to this component, whose primary purpose is to store the data. The Server Component does some input validation and then POSTs the data to a small number of servers (The Data Storage Component) who store it. These servers expose a similar API for receipt of the data as the Server Component. Additionally, these servers have APIs to allow read access to the data based on a date range, supporting streaming or pagination as desired.

Access to this data may be highly restricted initially, with a goal of opening up access as much as is feasible to allow for transparency, community involvement, and a high level of decoupling between the systems that store and the systems that analyze the data to answer meaningful questions about project health and usability.

Stored Data:

What	Where
JSON file	Transmitted to a CouchDB database (this Server Component) behind our firewall, once each time a user uses the BrowserID dialog

Communication with Server Component

Direction	Field	Data Sample	Notes
In:	timestamp	13330461000000	Unix timestamp rounded to 10 minute intervals
	event_stream	[ picker, 732 ], [ picker::change, 1700 ], [ picker::signin: 2300 ]	A list of UI Events and time offsets in milliseconds
	email_type	secondary	Which type of email was used? Primary or Secondary.
	number_emails	3	The number of emails a user has associated in their account
	new_account	false	Is the user brand new in the last 24 hours?
	language	en_US	i18n language code
	number_sites_logged_in	1	Number of websites which user used BrowserID on in last 24 hours
	screen_size	{ width: 640, height: 480 }	Device screen size
	sample_rate	1.0	Controls sampling of data submission client side
	user_agent	{ os: iOS, browser: Safari, version: 5.1 }	Course grained user agent (not the same as User Agent string)
Out:			Same data available behind our firewall

Data Glossary for deeper details of each Data element.

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

Users traffic on the system is potentially logged more than necessary. We should ensure this data collection only happens at appropriately spaced intervals (not hundreds of times per login, for example) and we are collecting the minimum amount of data required and it is retained for as short a term as possible.

The Risk is that we may end up with too much data that never gets used for the clear value proposed to users of the system.

Requirement: Work with Security Assurance and our Legal/Privacy Policy folks to minimize logging, minimize retention window, deploy a secure data storage infrastructure, and document and publish a data collection and retention policy.

Resolution:

[NEW]

Follow-up Tasks and tracking

What	Who	Bug	Details