Last week app developer Dan Nolan noticed that Google transaction records were giving him the name, geographic region, and email address of every user who bought an Android app he sold via Google Play. Dan’s bottom line was simple: “Under no circumstances should [a developer] be able to get the information of the people who are buying [his] apps unless [the customers] opt into it and it’s made crystal clear to them that [app developers are] getting this information.” Dan called on Google to cease these data leaks immediately, but Google instead tried to downplay the problem.
In this post, I examine Google’s relevant privacy commitments and argue that Google has promised not to reveal users’ data to developers. I then critique Google’s response and suggest appropriate next steps.
Google’s Android Privacy Promise
In its overarching Google Privacy Policy, Google promises to keep users’ data confidential. Specifically, at the heading “Information we share”, Google promises that “We do not share personal information with companies, organizations and individuals outside of Google unless one of the following circumstances apply”. Google then lists four specific exceptions: “With your consent”, “With domain administrators”, “For external processing”, and “For legal reasons.” None of these exceptions applies: users were never told that their information would be shared (not to mention “consent[ing]” to such sharing; Google shared data with app developers, not domain administrators; app developers do not process data for Google, and the data was never processed nor provided for processing; and no legal reason required the sharing of this information. Under Google’s standard privacy policy, users’ data simply should not have been shared.
Users purchase Android apps via the Google Play service, so Google Play policies also limit how Google may share users’ information. But the Google Play Terms of Service say nothing about Google sharing users’ details with app developers. Quite the contrary, the Play TOS indicate that Google will not share users’ information with app developers. At heading 10, Magazines on Google Play, Google specifically notes the additional “Information Google Shares with Magazine Publishers”: customer “name, email address, [and] mailing address.” But Google makes no special mention of information shared with any other type of Google Play content provider. Notice: Google notes that it shares certain extra information with magazine publishers, but it makes no corresponding mention of sharing with other content providers. The only plausible interpretation is that Google does not share the listed information with any other kind of content provider.
Users’ Google Play purchases are processed via Google Wallet, so Google Wallet policies also limit how Google may share users’ information. But the Google Wallet privacy policy says nothing about Google sharing users’ details with app developers. Indeed, the Google Wallet privacy policy is particularly narrow in its statement of when Google may share users’ personal information:
Information we share
We will only share your personal information with other companies or individuals outside of Google in the following circumstances:
* As permitted under the Google Privacy Policy.
* As necessary to process your transaction and maintain your account.
* To complete your registration for a service provided by a third party.
None of these exceptions applies to Google sharing users’ details with app developers. The preceding analysis confirms that the Google Privacy Policy says nothing of sharing users’ information with app developers, so the first exception is inapplicable. Nolan’s post confirms that app developers do not need users’ details in order to provide the apps users request; Google’s app delivery system already provides apps to authorized users. And app developers need not communicate with users by email, making it unnecessary for Google to provide an app developer with a user’s email address. Google might argue that it could be useful, in certain circumstances, for app developers to be able to email the users who had bought their apps. But this certainly is not “necessary.” Indeed, Nolan had successfully sold apps for months without doing so. The third exception does not apply to any app that does not require “registration” (most do not). Even if we interpret “registration” as installation and perhaps ongoing use, Nolan’s experience confirms why the third exception is also inapplicable: Nolan was easily able to do everything needed to sell and service the apps he sold without ever using users’ email addresses.
Even if it were necessary for Google to let developers contact the users who bought their apps, such communications do not require that Google provide developers with users’ email addresses. Quite the contrary, Google could provide remailer email addresses: a developer would write to an email address that Google specifies, and Google would forward the message as needed. Alternatively, Google could develop an API to let developers contact users. These suggestions are more than speculative: Google Checkout uses exactly the former technique to shield users’ email address from sellers. (From Google’s 2006 announcement: “To provide more control over email spam, Google Checkout lets shoppers choose whether or not to keep email addresses confidential or turnoff unwanted email from the stores where they shop”) Similarly, Google Wallet creates single-use credit card numbers (“Virtual OneTime Card”) to let users make purchases without revealing their payment details developers. Having developed such sophisticated methods to protect user privacy in other contexts, including more complicated contexts, Google cannot credibly argue that it was “necessary” to reveal users’ email addresses to app developers.
Siliconvalley.com quotes an unnamed Google representative defending Google’s approach:
“Google Wallet shares the information necessary to process a transaction, which is clearly spelled out in the Google Wallet Privacy Notice.”
I emphatically disagree. First, it simply is not “necessary” to provide developers with access to customer names or email addresses in order to process customer transactions. Apple has long run a similar but larger app marketplace without doing so. Scores of developers, Nolan among many others, successfully provide apps without using (and often without even knowing they are receiving) customer names and email addresses. To claim that it is “necessary” to provide this information to developers, Google would need to establish that there is truly no alternative — a high bar, which Google has not even attempted to reach.
Second, this data sharing is not “spelled out in the Google Wallet Privacy Notice” and certainly is not “clear[]” there. The preceding section analyzes the relevant section of the Google Wallet privacy policy. Nothing in that document “clearly” states that Google shares users’ email addresses with third-party developers. The only conceivable argument for such sharing is that such sharing is “necessary” — but that immediately returns us to the arguments discussed above.
Google widely promises to protect users’ private information. Google makes these promises equally in mobile. Having promised protection and delivered the opposite, Google should not be surprised to find users angry.
Some app developers defend Google’s decision to provide developers with customer details. For example, the Application Developers Alliance commented that “in the Google Play environment the app purchaser customer data (e.g., name and email address) belongs to the developer who is the seller” — arguing that it is therefore appropriate that Google provide this information to app developers. Barry Schwartz of Marketing Land added “I want to be able to service my customers” and indicated that sharing customer names and emails helps with support and refunds. Perhaps there are good reasons to provide customer data to developers. But these arguments offer no reason why Google did not tell users that their details would be sent to app developers. The Application Developers Alliance suggests that anyone uncertain about data sharing should “carefully review the Google Play and Google Wallet terms of service.” But these documents nowhere state that users’ information is provided to app developers (recall the analysis above), and in fact the documents indicate exactly the opposite.
Meanwhile, sharing users’ details with app developers risks significant harms. Nolan noted two clear problems: First, a developer could use customer contact details to track and harass users who left negative reviews or sought refunds. Second, an attacker could write malware that, running on app developers’ computers, logs into Google’s systems to collect user data. While one might hope app developers would keep their computers secure from such malware, there are tens of thousands of Android developers. Some are bound to have poor security on some local machines. Users’ data shouldn’t be vulnerable to the weakest link among these thousands of developers. An attacker could devise a highly deceptive attack with information about which users bought which apps when — yielding customized, accurate emails inviting users to provide passwords (actually phishing) or install updates (actually malware).
Moreover, Google is under a heightened obligation to abide by its privacy commitments. For one, privacy policies have the force of contract, so any company breaching its privacy policy risks litigation by harmed consumers. Meanwhile, Google’s prior privacy blunders have put Google under higher scrutiny: Google’s Buzz consent order includes twenty years of FTC oversight of Google’s privacy practices. After Google violated the FTC consent order by installing special code to monitor Apple Safari users whose browser settings specifically indicated they did not want to be tracked, the FTC imposed a $22.5 million fine, its largest ever. Now Google has again violated its privacy policies. A further investigation is surely in order.
A full investigation of Google’s activities in this area will confirm who knew what when. Though Nolan’s complaint was the first to gain widespread notice, at least three other developers had previously raised the same concern (1, 2, 3), dating back to June 2012 or earlier. An FTC investigation will confirm whether Google staff noted these concerns and, if they noticed, why they failed to take action. Perhaps some Google staff proposed updating or clarifying applicable privacy policies; an investigation would determine why such improvements were not made. An investigation would also confirm the allegation (presented in an update to News.com.au reporting on this subject) that prior to October 2012, Google intentionally protected users’ email addresses by providing aliases — letting app developers contact users without receiving users’ email addresses. Given the clear reduction in privacy resulting from eliminating aliases, an investigation would check whether and why Google made this change.
Even before that investigation, Google can take steps to begin to make this right. First, Google should immediately remove users’ details from developers’ screens. Google should simultaneously contact developers who had impermissible access and ask them to destroy any copies that they made. If Google has a contractual basis to require developers to destroy these copies, it should invoke those rights. In parallel, Google should contact victim users to let them know that Google shared their information in a way that was not permitted under Google’s own policies. Google should offer affected users Google’s unqualified apologies as well as appropriate monetary compensation. Since Google revealed users’ information only after users purchased paid apps, users’ payments offer a natural remedy: Google should provide affected users with a full refund for any apps where Google’s privacy practices did not live up to Google’s commitments.