Published using Google Docs
Protocol _ Data Donation Program
Updated automatically every 5 minutes

From: ANONYMIZED

To: Ethics Committee, ANON

Protocol / Data Donation Program

 

In this document, we detail how we plan to collect WhatsApp Data as part of the ANONYMIZED project. This document was elaborated by ANONYMIZED.

I – Rationale & Objective of the Research

 

India and Brazil have over the past few years emerged as hotspots in the global misinformation crisis. In recent years, messages containing misinformation about electoral security, terrorism, Covid-19, and vaccine safety have circulated widely in both countries, arguably leading to a slay of problematic behaviors offline, and possibly affecting the outcome of elections (Sinha et al 2019). As argued by the Indian state itself, both partisan and non-partisan threads often contain fake or erroneous news, many of which are suspected to lead to offline crimes. Mob lynchings incidents triggered by hateful messages circulated on the platform have especially attracted attention, both in India and Brazil. These cases have been well documented in prominent international press outlets, with some observers referring to misinformation as a major “public health crisis”.

All of this points to the need for independent, unaffiliated researchers to investigate this issue, as such research would be in the public interest.

Accordingly, the objective of the research is to quantify political misinformation on chat apps, in both India and Brazil. While high-quality evidence about Facebook and Twitter users’ “information diets” now exists (Guess et al n.d., Barbera et al 2015), little systematic evidence so far exists about chat apps (Tucker et al 2018). Encryption means that we currently lack evidence on several crucial metrics: 1.the total proportion of misinformed content (relative to other content) 2. the proportion of that misinformed content that is political, electoral or identity-related in nature (as opposed to other content, for instance entertainment) 3. The proportion of discussions/threads that are organized along political lines. 4. the proportion of content focusing on each likely “hot button topic” for misinformation (for instance: probity of political leaders, corruption, ethnic and religious relations, racism, electoral integrity, etc).

 

Knowing the scope and the type of (mis)information circulating on WhatsApp threads would greatly enhance our ability to combat misinformation. If it was found that a large amount of misinformation, hate speech, or other messages inciting to violence circulate on threads, whether these messages originate from actors affiliated to political actors or whether they are merely left uncorrected by political actors, it may suggest that platforms need to step up their efforts to control content. It may also affect the role assigned to states and individual users in this discussion. It may also suggest that both private and public actors need to be held accountable for the content they encourage or openly disseminate.

For all these reasons, investigating this issue would be in the public interest – acknowledging of course that an extensive array of protocols would be put in place to protect the identity of thread participants. It would be in the interest of the Indian public to carry this research, as finding solutions to the misinformation crisis now appears crucial.

II - Empirical Strategy

 

We propose to field a data donation program for WhatsApp data. In this program, our general strategy is to ask users to donate some of their WhatsApp data for social science research.

 

We provide them with extensive guarantees regarding privacy and anonymization and highlight that their (anonymized-at-the-source) data will at no point be shared beyond the main member of the research team (for now, only PI; though this will in the lead up to the research be extended to one or two more ANONYMIZED employees subject to the same restrictions and code of conduct). Importantly, in the design we outline below, ALL field staff (enumerators and local partners) will have no access to the data collected. To ensure that this is the case, they will sign a data-processing agreement (as per GDPR article 28) clearly outlining their action, identifying a number of restrictions, and penalizing data-processing behaviors outside of the scope of their mission. While field staff make the data collection possible, the data never transit through their own devices (they are instead instantly encrypted and uploaded to a secured server that only the PI has access to) nor do they subsequently have access to the server on which the data are securely stored. We also refrain from asking users to donate one-on-one threads, and concentrate on group threads, to limit privacy concerns.[1] 

The key technical innovation of the project is to make this donation process relatively seamless for consenting users, so that they may donate the data they wish to donate with minimal effort, with the assistance of one of our research associates (who once more, will assist, but never access the data). To reward users for their time and contribution to research, we provide them with small amounts in phone credits.

Concretely, this is how we proceed:

 

  1. At this point, we plan for data collection through in-person contact, both in India and Brazil. That is, our research associates (trained enumerators from a partner survey firm) visit randomly selected citizens face to-face (at their residence) and offer them to participate in a research study about their social media activity, particularly with regards to discussion groups they are part of and about the content that circulates on these groups. We choose to proceed face-to-face as we believe this will help generate a feeling of trust between contacted users and the research team and also help us in sampling populations that are harder to reach online (e.g. women, older people, etc).

 

  1. Field enumerators explain the goal of this study to the individuals contacted as such:

o “Hi. My name is XXXX and I work for the [SURVEY FIRM NAME]. We are contacting you to ask whether you’d accept to participate in a study on social media. We are working with a team of social scientists at [NAMES of collaborating universities].[2] 

 

If you agree to participate in our study, we will ask you to share some of your social media data. We are especially interested in public, semi-public and semi-private groups you might be part of on WhatsApp. We would like you to donate some of this data.

 

Importantly, any data you share will however be anonymized as described in this document [provide users with a flier about the process ]. Subsequently, we will also ask you a few questions about your opinions, your social media practice, and the data you shared with us.

 

To reward you for helping us do our research, we will compensate you with 250 rupees/25 reals[3] worth of data/phone credits.

 

The identities of the respondents interviewed in this study will be kept strictly confidential. No one will be able to link your data and/or answers to you as an individual nor to anyone else. The data will not be shared with anyone beyond the research team. This is an independent academic study and we are not linked to any platform, political party or government agency.

 

The data donation process will take less than 5 minutes. The subsequent survey you will receive through WhatsApp will take 15 minutes. Participation in this study is completely voluntary. You are free to decline to participate or to end participation at any time for any reason.

 

  1. At this time, we also provide respondents with a printed flyer explaining who we are, what our goals are, and how they can contact us. This includes:

○      Logos of all partner organizations.

○      Phone number for asking questions. This will function as a “hotline” of sort, with a research associate answering questions from 9AM to 5PM every day for the entire duration of the data collection.

○      How we anonymize:

○ Clear technical instructions on how to end participation in the project.

 

  1. At the end of this discussion, we formally ask for consent orally AND we have them sign a consent document that explicitly states that they were willing to share some of their data, understand the attached document, and understand that they can withdraw at any time. We ask three questions:

 

  1. The active cooperation of many participants is necessary to make this study successful. Would you agree to participate in our study?

 

1.Yes (if so, present them with a consent document stating that they understand the project’s goal, its objectives, the anonymization strategy and their rights).

2. No

[→ IF the answer is NO, the interaction ends here.]

  1. Do you understand the content of the attached explanatory document?

1.Yes

2. No

[→ IF the answer is NO, the interaction ends here.]

  1. Do you understand that you can quit the project any time without penalty?

1.Yes

2. No

[→ IF the answer is NO, the interaction ends here.]

 

(ENUMERATOR: IF THE RESPONDENT DOES NOT WANT TO PARTICIPATE, PLEASE THANK THE RESPONDENT, END THE INTERVIEW, AND WRITE DOWN THE REASON FOR NOT BEING INTERVIEWED.)

 

  1. IF they consent to participate and answer the 3 aforementioned questions with a Yes, the process starts.

 

At this point we request them to scan our generated QR code through their WhatsApp App on their own phone. Concretely, our research associate – using the web interface we designed (ANON LINK/) – generates a QR code and asks the respondent to scan it with their phone (this is easily done within WhatsApp through the “linked device” function anyone can use to project their WhatsApp, for instance, on a computer).

Importantly, throughout the process we describe here, the enumerators at no point need to handle the respondents’ devices nor to see their content.

​​

 

  1. Once this is done, the enumerator connects with the user’s WhatsApp, by pressing “connect user” on this screen.

 Once this is done, enumerator presses “choose threads to share”:

At this point the enumerator can show the respondent on the tablet they use for the survey the full list of WhatsApp group names that exist in the respondent’s WhatsApp, without yet having access to their content or to any other information besides metadata.[4] Once more, throughout the whole process, the field staff (here, enumerators) do NOT have access to the content of the threads, as these are directly uploaded to a server that only the main PI (ANONYMIZED) will have access to, at the end of the process we describe in what follows.                

Importantly we at this stage automatically exclude one-on-one threads in order to minimize the amount of data we manipulate, and as we are interested in groups rather than the most private conversations stored in users’ WhatsApp.  

This is how this looks like:

 

We can order these group threads in three different ways: by date of most recent post, by number of people in a group and by total number of posts over the past two weeks.

On this screen, we by default present all threads with 6 or more participants and that count 10 or more messages over the past two months to the participants. 

However, this interface allows participating users to select themselves the groups they are willing to donate by ticking the corresponding box in the right panel.

 

  1. We at this point ask participants to share data from the subset of these groups that they did select for the two months before they entered the program (i.e. two months before the date of their interview), and for two months going forward, though we readily note that they may themselves choose to restrict their donation to either part of this (as shown below). That is, provide us with only past or only future data, in addition to only sharing a subset of these groups.

  1.  As this inclusion/exclusion process takes place, our interviewer asks which type of data they are willing to give:

a)    Historical data (past two months)

b)    Future data (in the next two months)

c)     Both historical and future data.

 

If the respondent indicated willingness to share data going forward, we explain to them what they ought to do to ensure that the collection happens over the next two months, as well as what they can do to ensure it does not, should they change their mind.

 

Importantly, they can take these steps in seconds, on their own phones should they want to disconnect. This is explained in detail in the draft flier we distribute when asking for users’ consent. The enumerator will also demonstrate it in person.

9.     Once this inclusion/exclusion process is completed, the enumerator presses the “log messages” button (see screenshots above).

 

Doing so leads to two things:

 

·       An upload of the last two months of content of the selected threads onto our secured server (details below), in an anonymized manner (details on anonymization strategy below). That is, we never upload nor store non-anonymized content. The content is encrypted as it is transferred from the field staff’s devices to our cloud server.[5] This guarantees that neither the PI nor research staff ever has access to such content, either now or in the future.

 

·       An anonymized mirror copy of the selected threads, allowing us to collect data on these selected threads going forward. Importantly, we limit ourselves to two months going forward, after which the process is automatically disabled, with the user being disconnected and his contact information deleted from our database. Importantly, we do not have access to the data until the data collection period is concluded and/or the user disconnects. At that time, the temporarily saved unencrypted data which is saved in a location we cannot access is encrypted and sent to our server, where it is stored (and the unencrypted data is permanently deleted, as described above.

 

  1. At this stage, once messages/threads are logged, respondents answer a brief series of questions about up to 20 of the threads whose data were harvested, and about their own demographic characteristics (10 min max).

 

  1. Within a few weeks, they receive the reward (phone credits) directly on their phones. When they do, they once again receive contact information for the “hotline” and a link towards information about the data donation program.

 

III – Responses to Key Ethical and Privacy Concerns

a)    What (anonymized) data do we collect through this strategy?

 

Though this information is immediately anonymized and never stored pre-anonymization (details below), we collect information on:

·       who users are connected to (i.e. users address book).

·       who they chatted with.

·       how many groups they are part of.

·       what is the respective size of these groups?

·       and most importantly, the content from chats the users consented to share.

 

The information we get from the content of the chats includes messages, images and videos exchanged in the chat and the timestamps of when they were sent and who sent them.

As detailed below, we do not however systematically keep all of this data on our servers. This is because we run systematic checks on already anonymized data to exclude (and permanently delete) data which potentially allows for re-identification. This is an extensive, comprehensive step to ensure that as close as possible to 0% of data we store allows for re-identification, despite our best measures to avoid uploading and storing such data in the first place. Details on this systematic anonymization audit (SAA) are below.

 

b)    How are these data anonymized as they are uploaded?

 

As noted above, all the data is anonymized before it is stored on our servers.

 

On servers: the current plan is to store these data on ANONYMIZED university servers, for which the necessary guarantees in terms of privacy and data transfer are already in place.

 

That is, we do not store any raw de-anonymized data. We anonymize any personally identifiable information like the names, phone numbers, and emails from the dataset.

The anonymization is done through a state of the art privacy preserving algorithms which are well established and widely used library provided by Google called the Google Data Loss prevention API https://cloud.google.com/dlp/docs/deidentify-sensitive-data

 

With this process, each bit of sensitive information is encoded and replaced with a unique identifier. Here are examples of this process – showing each time the original and the de-identified version:

 

EXAMPLE 1:

Original: I am john doe. My phone number is 733610710, and my email address is abc123@gmail.com.

 

De-identified: I am DATA_SURROGATE(40):ASfZ4S34ebXX7dBtmpXNhIrsDaHxd69QQDWkburV. My phone number is DATA_SURROGATE(36):AYRHBhn9bOsxvuT6upvCL6CdB7fCs+worhgd, and my email address is DATA_SURROGATE(60):AZvZxsvw71AvuU70BN+djsLgObqqebgCmEPgbHuTQFZ06sTwRMOF6R5VZw==.

 

EXAMPLE 2:

Original: You can call me on 1234567890

 

De-identified: You can call me on DATA_SURROGATE(36):AQtE07P8stbJs+vjH+OGnFZUHJsUqQcjsMJV

 

EXAMPLE 3:

Original: Reach out to me on abc123@gmail.com

 

De-identified: Reach out to me on DATA_SURROGATE(52):ARWUCKt+HYuAJutfFHmmxGKA1qsYop6SH2/HvHnLBbxgANDhS/uY

 

EXAMPLE 4:

Original: Hey, John here, I was trying to call you on 9989932

 

De-identified: Hey, DATA_SURROGATE(32):AWR1VJ8jrm0hkCaC6qh8ZDNg16RZEg== here, I was trying to call you on DATA_SURROGATE(36):AWhNRghawZHTIpeQBHnt73AFltCCImoQ57LG

 

In each of these examples, DATA_SURROGATE is an identifier to indicate which part of the message has been deidentified.

The below images show examples of all the fields (not just the text message) being collected and how they are ultimately stored. The first one is the original pre-anonymization data. The second one is the anonymized data.

We can see that other fields such as the ID of the user (the phone number), the group ID, the receiver and sender information have all been anonymized.

Pre-anonymization:

Post-anonymization:

While it can technically be used for re-identification, we delete the original key to make this impossible as soon as we have verified that the data is safely stored.

We do not store group icon pictures (i.e., profile pictures), nor audio messages.

 

For pictures/videos included within the threads that we collect, we create the following pipeline:

 

1.         We start by storing the pictures and videos securely on our servers but also create hashes of them.

2.         We then use the aforementioned hashes to identify if the same image/video were in data shared by multiple users.

3.         After the data collection, we proceed to irreversibly anonymize most images we store, with the exception of images/videos which are shared by at least 5 groups/threads in our data AND that do not contain personal data (for instance, a nude that was forwarded around). Since this eventually be limited to a small number of items, the PI will check each of these images individually to decide whether this is the case.  Overall this procedure ensures that we do not  access the vast majority of un-anonymized visual content. Importantly, the viral content we keep and analyze is extremely unlikely to be personal or private content.

To anonymize, we rely on tools such as Brighter AI and Gallio to blur out faces, as in the example below. Tools such as Brighter AI and Gallio provide us with an automated (and hence convenient) on-premise procedure (the data never leaves our servers during this process) to blur faces and a few additional identifying features of images/videos (for instance, car plates).  

Examples of anonymization are shown below (image of several friends, obtained with permission):

We at that point replace the un-anonymized images and videos stored on our servers with these anonymized images and permanently delete the un-anonymized originals.

c)        What may not be anonymized through this process

 

As noted above, our anonymization is extensive. It removes mentions of names, emails and phone numbers and replaces them with random text (also called hashes). We also automatically blur faces and a few objects predictably containing personal information (for instance, car plates) on images and videos that are not viral.

 

Even with this extensive protocol, we however must acknowledge that perfect, foolproof anonymization is never possible. This is because users may share on the threads (whose content we log, following the process detailed above) text containing personal information which does not belong to the categories listed above, or that may be triangulated with context/metadata to make reidentification possible. We are not able to predict sufficiently perfectly which phrase or type of text may contain such information in order to devise an automated strategy to systematically anonymize said text.

Besides, despite our systematic blurring of faces and a few other objects predictably containing personal data, this may similarly be the case of images or videos. Contrary to what software providers such as Brighter AI and Gallio claim on their website, automated procedures to blur faces and car plates do not equate to an absence of personal data nor to perfect anonymization. This is, similarly, because images may contain other personal information about individuals, even if their faces are blurred (their dress may for instance provide clues to their identities), especially if information about context is otherwise also present (either as text or visual).

Hence, as developed in the following section, we implement a second stage of anonymization, this time human-driven.

d)        How do we deal with imperfectly anonymized data or data on our servers that provide a potential for re-identification?  

We implement a second, human-supervised stage of anonymization.  We implement this systematic anonymization audit (SAA) BEFORE analyzing the data, in order to potentially strengthen - and hopefully perfect - an already thorough anonymization strategy.  

Concretely, the PI and two close associates based at ANON university (and hence, as ANON university employees, subject to the same restrictions and code of conduct), but with knowledge of the context, will systematically review all the text and visual content already anonymized using automated methods and evaluate the potential for re-identification of personal data, following clear guidelines developed in relation with the project’s ethics advisory board, and based on the GDPR’s definition of personal data in article 4:

‘Personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.

Our strategy is to start by further anonymizing the text content. We systematically remove any mention of:

We also conditionally redact:

Once this is done, we proceed to further anonymize the visual content, where we see a need to do so. While almost all identifying content has been removed from the textual part of the WhatsApp thread, this should be a necessary additional step in some cases.

Concretely, we make sure to blur:

And pledge to add to this list as need occurs.

In the image below, we would for instance blur the brand on the first person’s jacket:

While we recognize that these multiple, extensive steps fall short of eliminating 100% of the possible risks of identification of the individuals involved, we believe it comes extremely close to doing that, in practice. And welcome further recommendations to further strengthen this process while providing us with the ability to carry research we eventually believe to be in the public interest.

e)        What does the back-end concretely look like?

The back-end is hosted on a secure server by Amazon AWS. The server only allows login to a specific set of IP addresses and uses two factor authentication. The data in the backend is stored in MongoDB where files are stored as JSON objects (see Figure in Page 11 for example). All media files including images and videos are also stored as base64 encoded strings in MongoDB instead of as raw files (for added protection).

This is how this encoded content concretely looks like:

This is how images are stored:

f)        How do we deal with unexpected findings?

While we see this probability as low ex-ante, we also recognize that either this data collection project or the analysis of said data might lead to some “unexpected findings”, as defined here:

“incidental or unexpected findings are traditionally associated with clinical research but may occur in human and social science research as well. Such findings fall outside of the scope of the principal research objectives but necessitate action on the part of the researchers.

The handling of incidental or unexpected findings may raise ‘serious and/or complex’ ethics issues as such findings can have a significant impact on research participants’ wellbeing, cause psychological distress to researchers, raise safety or safeguarding issues, or require the researcher to disclose the information to appropriate or designated authorities” .

In the context of this project, these ethics issues may be considered as ‘serious and/or complex’ if the research yields, for example:

OR

If we detect such content, the research team will within 3 days (from the time of discovery) consult with the ANON university project ethics advisory board (which contains both Brazil and India specialists) to establish the best way forward on a case by case basis. We refrain from establishing a blanket policy ex-ante in light of the rapidly changing political landscapes in both countries and in light of the potential for political bias in the judicial system.

g)        Justification For Parameters of the Data Collection

As explained above, we ask participants to share up to four months of data (2 months prior, two months after) on a very specific subset of their threads (i.e. threads with 6 or more participants and that count 10 or more messages over the past two months – ALL OTHER THREADS, including one-on-one threads, ARE ALTOGETHER EXCLUDED FROM THE DATA COLLECTION), though we also provide them with an easy way to share only a subset of this subset. That is, they may share either historical data or data going forward; they may also exclude any thread on the list we initially present them with, and as noted above, as many threads on that list as they wish. We also note that they may quit the program at any time after they consented.

We believe these parameters to constitute the right compromise between 1. the data minimization principle, 2. The feasibility of our anonymization-intensive strategy and 3. our ability to conduce meaningful scientific enquiry – and especially statistical analyses - in the public interest.

We land on these parameters after assuming the following:

This is more or less the number we guess we need to be able to say something meaningful with a high degree of reliability, and in order to be able to be able to detect statistically significant differences across types of threads.

 

 


[1] While large group threads are technically private threads, many of them are in practice public or semi-public in India and Brazil, as both public and private actors add users on groups that are very often large without properly asking for their consent. This type of group is our main target in this research project.

[2]  Both in India and Brazil, the our team will collaborate with a prominent local university on this project.

[3] 250 rupees = 3 dollars; 25 reals = 5 dollars, approximately.

[4] This is because they cannot access the content of the thread on the tablet they are handling. At this stage, we merely extract metadata about the groups as well as their names.

[5] Concretely, we rely on the following procedure: 1. The unencrypted data is exported and temporarily saved in a location that the research team cannot temporarily access as its access is temporarily protected. 2. An automated procedure encrypts it. 3. The encrypted copy is stored safely in the research team’s server. 4. As soon as step 3 is completed, the unencrypted data that was exported and temporarily saved is permanently deleted.

[6] Chauchard and Garimella (2022) provides useful baseline estimates.