Data Safety: Difference between revisions

<h2> Data Safety Design Principles </h2>

<p>Taking our Privacy Principles down to the data governance layer, we propose a few starting design guidelines:

<ul><li> Clear user benefit: there should always be a clear and direct user benefit that results from the data we collect. Aggressive user data storage “just in case it’s needed later” is not acceptable.

</li><li> Data inventory: we should always know what data we’re collecting, where and how it’s stored, and why the storage of each datapoint is crucial to the end-user feature. We should make sure users can easily get at this inventory, understand it, update it, or delete it.

</li><li> Minimize server-visible data: if we can implement a given feature by never sending data to the server, or by using application-level encryption, then we will.

</li><li> Minimize data retention: we should store data for as little time as possible. In particular, if we need servers only to provide a transit point for data, then that data should only transit, never be stored.

</li><li> Aggregate whenever possible: we will explore whether we can implement the feature with data aggregated across a significant number of users, rather than keeping individual data points. (Given the richness of these datasets, we cannot pretend that de-identification is particularly useful to protecting individual users.)

<p>Background on these principles are included in our January 13, 2012 blog post entitled, "<a href="http://blog.mozilla.com/privacy/2012/01/13/mozilla-to-offer-new-user-centric-services-in-2012> Mozilla to Offer New User Centric Services in 2012</a>."