You are currently viewing Google vs. Respondent Privacy

Status: Rejected

Last updated: July 17, 2020

Note: Since publishing this post, we’re focusing on ensuring that users have access to the newest version of SurveyCTO Collect and moving away from attempts to appeal to Google to release it in the Google Play Store. Read our release notes to learn more about how to install the latest version and its enhanced functionality for phone surveys, including streamlined survey administration and respondent privacy protection.

In response to our users’ rapidly evolving needs for data collection technology, we’ve developed a major new version of SurveyCTO Collect with powerful new features for conducting telephone interviews and protecting respondent privacy — but Google is blocking us from releasing it

For reasons we cannot discern and they will not reveal, they have decided that our integrated phone-app capabilities do not constitute “core functionality” for our app. The result is that we cannot (even with users’ explicit permission) access device call logs to protect respondent phone numbers.

While the Google team has been responsive and courteous, they have been unwilling to answer direct questions or do anything other than re-state (and re-link) a variety of policies, all of which we believe we are in full compliance with, both in spirit and in letter. They have also been unwilling to escalate our case to somebody who might be able to answer questions and help us resolve the issue. We therefore decided to seek community help in finding a resolution, so that we can maintain robust privacy protections and release this important update.

You can find more details below. If you’d like to support us, please consider tweeting something like the following (or emailing to

  • Hey @Google, please don’t prevent @SurveyCTO from protecting respondent privacy!
  • Hey @Google, we think “default phone handler” capabilities are “core functionality” in @SurveyCTO!
  • Hey @Google, @SurveyCTO has new “default phone handler” support that you should agree meets your “default phone handler” use case.

If you have other ideas for how we can resolve this issue, please write to me at Thank you!


As the global pandemic rendered in-person survey operations unsafe or even impossible, telephone surveying became a critical tool in helping to keep data flowing to policymakers and program implementers all around the world. Here at Dobility, we have worked around the clock to improve our telephone-survey capabilities, in order to meet the rapidly-changing needs of our users.

In early July, we completed our most ambitious update to the SurveyCTO Collect app on Android, to integrate phone-call-management directly into the app. The goals were twofold: to streamline the user interface for managing phone calls during interviews, and to protect respondent privacy by limiting where, when, and to whom respondent phone numbers appear. We accomplished this by offering to take over as the Android device’s default phone app whenever Collect users wish to make or receive phone calls for telephone interviews, and by ensuring that respondent phone numbers flagged as private will not appear in the device’s global call log.

This latter capability — the ability to keep sensitive respondent phone numbers private — is critical for protecting the human subjects of research and is often required by the institutional review boards (IRBs) that safeguard research ethics all around the world. While Google has tried to start cracking down on who can read device call logs in recent years, there are many ways in which phone numbers in the call log can be exposed: they are plainly visible in other phone apps, all apps built and approved during earlier policy eras can read the logs, and all apps installed outside the Google Play Store can read the logs. Therefore, it’s critical that we be able to keep sensitive phone numbers out of those global logs.

Rejection by Google

Ironically, it is Google’s crackdown on access to call logs that is preventing us from releasing our updated app in the Google Play Store: they have rejected our app as violating their policies around access to sensitive device permissions.

Note: all of their emails link to permitted uses and use cases here, and to exceptions here.

We did our best to review their policies and ensure that we were fully compliant. For example, we made sure that we only ever accessed call logs when we were operating as the device’s default phone app — with the user’s explicit permission to both take over as the default phone app and access the call logs. Further, we only accessed the call log when respondent phone numbers were flagged as having to stay private, in order to reduce the number of cases in which we would have to use sensitive permissions. When we reached out to the policy support team with questions about where and how we were non-compliant, we were essentially given the same information and links:


Attempts to engage

We sent more questions, then, which elicited another slightly different response (though still not direct answers to any of our questions):


After more back-and-forth like this, it seemed that the issue was how we promote our app in its store listing, and whether or not “default phone handler” functionality was represented as “core functionality.” We therefore updated our store listing to make it abundantly clear how important the phone-app capabilities were to our app:

SurveyCTO Collect for Android is a powerful tool for telephone surveying (a.k.a. Computer Assisted Telephone Interviews, or CATI). Collect can take over as your default phone app, deeply integrating call-management features with form-filling features, effectively turning any Android device into a mobile call center.

Survey forms can launch and manage phone calls, you can receive calls within the app, and the entire user experience has been optimized for interviewing. For multi-use devices, Collect makes it easy to switch between Collect and other phone apps, so that you’re always using the right phone app for your needs. A setting allows you to use Collect as your default phone app either on-demand, whenever-running, or always.

To protect respondent privacy and honor the requirements of institutional review boards (IRBs) protecting human subjects, your survey forms can request that particularly-sensitive respondent phone numbers be hidden on the device. When you do so, they will be labeled with safe, non-personally-identifiable labels that you choose in your survey design, respondent phone numbers will be kept out of the device’s call log, and they will never be given to another phone app on the device.

Collect can also be used for mobile data collection (a.k.a. Computer Assisted Personal Interviews, or CAPI). It allows you to collect data offline so that you can conduct household interviews, facility inspections, or any other kind of data collection even in remote, poorly-connected environments.

Collect is a core part of the overall SurveyCTO product, which also includes web and desktop software components. After data has been collected with Collect, it is uploaded to the SurveyCTO server when an Internet connection is available or transferred to a supervisor’s laptop over a local (offline) wi-fi connection.

SurveyCTO was initially built on the Open Data Kit (ODK) open-source platform, and has specialized in data quality, data security, and overall reliability. Learn more at or in the documentation at

Still, however, they rejected us, and still their policy support team kept saying mostly the same things:


Some of the words were slightly different this time. So, for example: “Currently, you have declared Default Phone handler as the core functionality of your app; however, your metadata does not indicate the app as the declared core functionality.” We had to Google for what “metadata” might mean in this context, only to find that it’s another way of talking about the store listing details (including the app description and promotional images). But we’d already revised the description (above), and we’d already prominently featured multiple new promotional images:

How could Google think that our store listing didn’t describe Default phone handler capabilities as a core function of the app? Unfortunately, they simply refuse to say, despite our repeated attempts to clarify.

They did mention something new in their latest message: “Without the core feature(s), the app is “broken” or rendered unusable.” Without acting as the default phone app, we cannot manage phone calls within Collect, so that aspect of the experience can be “broken”; and without the call-log permissions, we cannot protect the privacy of respondent phone numbers. But, is the entire app broken without the phone-app or call-log capabilities? No, you could still do other things with it. But is that really their policy, that the entire app be totally unusable without one of its core features?

We have made multiple attempts to have our case escalated to somebody within the Google policy support team who can answer direct questions and help us to resolve the issue. So far, they have declined, opting only to re-state and re-link the same policies again and again. (We have suspected that we are actually interacting with a bot.)

Next steps

At the end of the day, we are supportive of Google’s attempts to restrict app permissions to what is reasonably necessary and what can be made clear and reasonable from the point of view of that app’s users. Their policies make sense. And we appreciate Google’s fast turn-around in reviewing our app and responding to queries. However, we have reached an impasse: we believe that we are fully compliant with their policies, but they keep rejecting us. And all attempts to understand the true reason behind the rejections have failed.

Will Google truly force us to give up on protecting respondent privacy? Without even making clear why it is they think we’re violating their policies?

Please see the top of this post for how you can help us avoid that fate. Thank you!

Chris Robert


Chris is the founder of SurveyCTO. He now serves as Director and Founder Emeritus, supporting Dobility in a variety of part-time capacities. Over the course of Dobility’s first 10 years, he held several positions, including CEO, CTO, and Head of Product.

Before founding Dobility, he was involved in a long-term project to evaluate the impacts of microfinance in South India; developed online curriculum for a program to promote the use of evidence in policy-making in Pakistan and India; and taught statistics and policy analysis at the Harvard Kennedy School. Before that, he co-founded and helped grow an internet technology consultancy and led technology efforts for the top provider of software and hardware for multi-user bulletin board systems (the online systems most prominent before the Internet).