User Data Principles: Difference between revisions

Mozilla may, in the course of providing services for the user, need to retain user data on its servers.

XXX Final text of the Data Operating Principles here - edits from blog post?

In concrete terms, what this means for a Mozilla-operated service is:

# In addition to inter-service resilience, Mozilla-operated services have inter-user attack resilience.  A compromise of a single user's data should not escalate into an attack on any other user.

# Users must always be able to determine what data is retained, and how that data is being used.  They should be able remove any piece of data at will, and revoke any authorization that has been granted on a particular piece of data.  Authorizations should be granted on the smallest possible unit of data, to the practical extent of available technology.

# Any Mozilla-operated service should protect users from administrative access as well.  This means that **if data is readable by administrative users or batch processes**, there is a well-defined, auditable, revokable process for granting access to it.  That is, there is no super-user level at which an administrative user or process can read all data without leaving a trace.

* User credentials should stay "close to the data".  This means that, when a service does not have a user credential, it should not be able to read or write user data.

* Implementation strategies for this are two-fold:

** Data can be stored encrypted, with client-side keys; in this case, the decryption key is the ultimate user credential (see On Encryption)

** Or user credentials must be relayed from the client-facing service all the way down to the data persistence system used for authorization and authentication decisions at that level.

* When data is available to administrators or batch processes, there should be an authentication/authorization process that grants a "single user's worth" of authorization at a time.  For example, a superuser may obtain a user credential that represents "Superuser Alice, accessing data for user Bob", and data systems should recognize this credential as having Bob's access level.  The generation of any such credential should be audited in a way that Alice cannot tamper with it.

* Data should be subjected to access control rules that enforce both user-level and application-level controls, and these rules should be visible to the user.  If a user stores a piece of data with application A, it should not automatically be available to application B.

* There should always be a simple process that the user can use to find out what has been stored on Mozilla's servers, and a simple process to remove, deauthorize, and/or export the data.

The Firefox Sync system uses client-side keys, which provides a strong guarantee of user authentication, which makes it a good match for conveying user credentials (like passwords).  The requirement to never let a client-side key leave the client makes the design harder to use for other applications (such as server-side analysis of data), and the conveyance of keys between clients during the setup phase is a user experience challenge.  Ironically, the opacity of encrypted records can make some pieces of the system principles harder to achieve - for example, transparency into stored data cannot be provided by a web application, since only the client knows how to read the data.  The careful use of client-side technology is helpful here, but cross-browser implementations can be difficult to achieve.

Implementors should also take care that attackers cannot manipulate the system with encrypted data, for example with replay attacks or unsigned record deletion requests.

==On Shared Persistence==