Jump to content
Gov  路  Market  路  Community  路  Policies  路  Funding  路  Open Call  路  Get started

Policies/en/Data-Collection-Guidelines

From WikiDeal
This is the latest revision of this page; it has no approved revision.

This is a draft version. Source: adapted notably from the Wikimedia Foundation Governance Wiki, https://foundation.wikimedia.org/wiki/Legal:Data_Collection_Guidelines (CC BY-SA 4.0), with changes. Status: proposal, to be adopted. See the detailed disclaimer.

In simple words: every time a platform collects data about its users (which pages they visit, which country they are in, what they answer in a survey), there is a risk for their privacy. This page proposes a method to measure that risk BEFORE collecting anything: three risk levels, clear criteria, and a review by privacy specialists when the risk is not low. The goal is to collect as little as possible, as safely as possible.

Data collection guidelines

The right to privacy is at the core of how communities would contribute to the WikiDeal platform: upholding this right is intended to be a central aspect of the human rights commitments of the Ynternet.org Foundation. These data collection guidelines outline best practices for managing privacy risk in data collection. They complement the data retention guidelines and the data publication guidelines (proposal, to be adopted), providing guidance about how to handle potentially sensitive data through the entirety of its life cycle. Taken together, these guidelines would contribute to the commitment to protect users' data as elaborated in the Privacy policy.

The breadth of what constitutes data collection can vary widely, as many teams may engage in some kind of data collection behavior. To provide guidance in meaningfully evaluating a potential data collection activity, five general categories are examined:

  • Data subjects (for example readers, contributors, app users, donors)
  • Data senders (for example platform tools like a browser, app, or extension; or third-party software providers)
  • Data recipients (for example the Ynternet.org Foundation, user groups and partner organizations, third-party software providers, the public)
  • Type of data (for example user account information, page information, telemetry data, demographic information, attitudinal or behavioral information, geographic information, event information)
  • Data usage and changes to data usage (for example published in raw format, published anonymously, not published; de-identified, aggregated, and kept in perpetuity)

What is out of scope: the variables entered by the parties in a contract (names, amounts, addresses, bank details) are private data of the parties by default, governed by the Privacy policy, not a data collection activity in the sense of these guidelines. These guidelines concern the data the platform itself would collect about its users.

The following data collection risk tiering grid presents those categories as criteria, to help teams assess the risk tier of their data collection activity.

Data collection risk tiering grid

Low risk criteria
  • The data subject is subject to the applicable Privacy policy;
  • The data sender is subject to the applicable Privacy policy;
  • The data recipient of the data is the Ynternet.org Foundation, or an approved third-party software provider that does not use cookies;
    • Note: if the third-party software provider is using cookies or other client-side storage, this immediately becomes a medium or high risk activity
  • The data would be kept for a typical retention period and then deleted, aggregated, or de-identified and sanitized;
  • The data collected does not include:
    • multiple items of unhashed personal information<ref name="personal_info">Personal information (from the Privacy policy): information you provide or information collected that could be used to personally identify you. While not all of the following types of information are necessarily collected, at least the following are considered "personal information" if otherwise nonpublic and usable to identify you: (1) your real name, address, phone number, email address, password, identification number on government-issued ID, IP address, user-agent information, payment account number; (2) when associated with one of the items in subsection (1), any sensitive data such as date of birth, gender, sexual orientation, racial or ethnic origins, marital or familial status, medical conditions or disabilities, political affiliation, and religion.</ref>
    • personal information + username, user ID or app ID
    • long-term viewing history<ref name="long_term">Long-term viewing history data: data that logs pageview histories of more than 90 days for logged-out users, or more than 1 pageview for logged-in users.</ref> + unique ID<ref name="unique_id">Unique identifier (ID): an expansion of "personal information" as defined in the Privacy policy. To this list are added username, user ID, and app install ID. Hashed versions of plaintext unique IDs are still considered to be unique IDs, since they may still uniquely identify a user.</ref>
    • granular geographic data<ref name="granular_geo">Granular geographic data: data that identifies the location of a user at a sub-national resolution.</ref> + unique ID<ref name="unique_id" />
    • sensitive data<ref name="sensitive_data">Sensitive data (from the Privacy policy): date of birth, gender, sexual orientation, racial or ethnic origins, marital or familial status, medical conditions or disabilities, political affiliation, and religion.</ref>
Risk level Tier 1: High risk Tier 2: Medium risk Tier 3: Low risk
Data that could certainly expose data subjects or recipients to risk of harm. Data that could likely or possibly expose data subjects or recipients to risk of harm. Data that is unlikely to expose data subjects or recipients to risk of harm.
Criteria The data collected is ongoing<ref name="ongoing">Ongoing data collection: data collected in an ongoing manner, typically through automated means. This covers telemetry data from app or web interactions. Importantly, it is data collected through implicit consent just by using the platform. It can be long term (for monitoring usage over an indefinite amount of time) or short term (for conducting experiments that have a definite end).</ref> and fails TWO OR MORE of the low risk criteria.

OR

The data collected is one-off<ref name="one_off">One-off data collection: data collected in a single instance, typically through a survey. Data subjects in this context may explicitly consent to sharing data by acknowledging a privacy statement, filling out a survey, and clicking a "Submit" button.</ref> and fails THREE OR MORE of the low risk criteria.

The data collected is ongoing<ref name="ongoing" /> and fails ONE of the low risk criteria.

OR

The data collected is one-off<ref name="one_off" /> and fails TWO of the low risk criteria.

The data collected is ongoing<ref name="ongoing" /> and fails ZERO of the low risk criteria.

OR

The data collected is one-off<ref name="one_off" /> and fails ONE OR ZERO of the low risk criteria. The single criterion failed cannot be collecting sensitive data.

Response time goal 3 work weeks 5 work days Not applicable
What should teams do next?
Things to do for all risk tiers
  • Once the tier of risk has been assessed using this tiering grid, log the data collection activity in the data collection activity log (the concrete logging tool would be defined upon adoption of this proposal).
  • If the data obtained is later used for a new purpose, the tier of risk would be reassessed using the tiering grid and a new data collection activity log entry would be submitted.
Additional things to do depending on the data collection activity and risk tier For surveys: fill out a survey privacy statement to supplement the data collection activity log entry.
For all other data collection activities: submit the data collection activity to a privacy review (privacy engineering and privacy legal, plus other teams if needed). Reviewers would suggest mitigation measures to make it low or medium risk.

During the review process, the reviewers would request approval of the data collection activity from a director or higher of the team that owns the data collection activity, in order to proceed with high-risk collection activities.

For all other data collection activities: submit the data collection activity to a privacy review (privacy engineering and privacy legal, plus other teams if needed). Reviewers would suggest mitigation measures to make it low risk.

During the review process, reviewers would request approval of the data collection activity from the engineering manager of the team that owns the data collection activity, in order to proceed with medium-risk collection activities.

For all other data collection activities: no additional privacy review would be necessary.

Recurring or changes to existing data collection activities

If a data collection activity is recurring,<ref name="recurring">Recurring data collection: instances of data collection that either recur after some time period (for example each month, quarter, or year), or have equivalent data collection schemas across some set of contexts (for example iOS and Android).</ref> subsequent reviews would be of a known risk, and would require less stringent review standards. For example:

  • A high risk one-off survey in the first quarter would be deemed a known high risk (faster response and decision cadence) in later quarters, if the information collected is the same.
  • A medium risk ongoing data collection activity on iOS would be deemed a known medium risk (only requiring entry into the activity log) if an identical schema had already been reviewed for Android.

Proposed changes to existing ongoing data collection activities should be considered to involve a change in the type of data collected, and should be considered a new entry in the data collection activity log, and a new data collection to review.

Mitigations

Here is a list of example mitigation measures that can lower the risk of a data collection activity:

  • Because it is trivially easy for a bad actor to derive granular geographic data from a full IP address, for the purposes of these guidelines, collecting complete versions of IP addresses is considered to be both a unique identifier<ref name="unique_id" /> and a leak of granular geographic data: therefore, collecting IP addresses is a medium risk data collection activity. Relevant mitigations include:
    • dropping the last two octets of IP addresses (for example 192.168.xxx.xxx)
    • hashing IP address + user-agent
  • For circumstances in which granular geographic data is critical, consider collecting sub-national geographic data and then dropping all unique IDs.
  • To collect riskier unique IDs (like IP addresses) and maintain a low-risk status, it may be necessary to hash them.

Definitions

<references />

See also

Retrieved from "https://wikideal.net/w/index.php?title=Policies/en/Data-Collection-Guidelines&oldid=1601"