Trusted Developer Best Practice for Openness & Transparency

1.png

Principle 1. Introduce Yourself
Developers should clearly identify themselves and provide mechanisms for users to easily connect and interact on privacy issues. Developers should not seek to mislead users or to hide their identities.

Best Practice:

  • Identify yourself in a conspicuous way when a user first accesses an application or service.
  • Provide an in-app mechanism or pointer to access detailed privacy policy information.
  • Specifically provide a contact mechanism for privacy related questions.
  • Privacy policies should be short and concise, but complete, and in plain and simple language.
  • Privacy policies can include greater detail linked under high level topic summaries.

Principle 2. Inform before Access
Developers should not access or allow access to any user content or private user data without informing the user in advance in clear and simple language. This includes clearly establishing the user’s identity before allowing them access to their previously shared personal data or content.

Best Practice:

  • At a minimum, this includes obtaining and later verifying a unique user name and password.
  • Developers should not allow third party access through their application without notice.
  • Notice should be particularly conspicuous where data access could be unanticipated by the user.

Principle 3. Obtain Explicit Consent
Developers should obtain consent before accessing user content or private user data. Developers should explain in clear and simple language what user content or private user data will be accessed and what it will be used for (including uses beyond the service involved), including what service limitations would result from denied permission, before asking for user consent.

Best Practice:

  • Best practice is a limited, general consent at install for base-level data access.
  • Best practice is to obtain further specific consent as features are enabled or configured.
  • Developers should get specific consent for data which users could find sensitive (e.g. location).
  • Developers should explicitly gain consent and identify any data accessed when the app is not in use.

Principle 4. Explain Your Data Retention Practices
Developers should indicate whether specific data use will be transient (queried, used, and immediately forgotten) or retained, and whether data will be stored locally on the user’s device or transmitted and stored remotely.

Best Practice:

  • Best Practice is to provide a UI cue when non-obvious data access is taking place.
  • Data retention time-limits should be part of your privacy statement.
  • Legal or regulatory compliance obligations that impact retention should be clearly stated.

Principle 5. Disclose Who Else Might Have Access to Data
If user content or private user data will be shared with third parties, developers should inform users of the obligations they will impose on those involved, the purpose for sharing, the names or attributes of the third parties involved, and seek consent in advance of access.

Best Practice:

  • Developers should clearly explain any legal obligations that might force third party disclosure.

Principle 6. Provide Notification of Changes & Significant Events 
Developers should inform users in the event of breach, legal process, or a change in practice or business control that implicates user content or private user data, the developer/user relationship, or privacy policies.

Best Practice:

  • Developers should re-inform and seek additional consent for any material change in practices.
  • Notifications should be timely to reduce the potential damage to everyone involved.