Google Play Privacy & ‘Safety’ Updates
In May, Google announced their Play Store’s new ‘Safety Section’ (more on their title choice later), which appears similar to Apple’s App Store ‘Privacy Details’ (colloquially known as their ‘Privacy Nutrition Labels’). In the Android Developers Blog, Google released details of the new feature. Beginning now, developers are able to begin entering their privacy-specific information into the Google Play Console. In addition, read below about other policy changes, including the upcoming Permission Auto-Reset for ‘hibernating’ apps.
Google Play’s ‘Safety Section’
As this video shows, the feature allows users to see an app’s data practices before downloading, similar to Apple’s Nutrition Labels. Developers will have until April 2022 to be fully in compliance with Google’s safety section disclosures. The self-registration process requires developers to disclose what type of data is collected and stored by an app and how the data is used. It also requires the developer to disclose whether the app (1) has security practices, like data encryption, (2) follows Google’s ‘Families Policy’(more on those policy changes in a future post), (3) requires the data to provide functionality or if the users have a choice in sharing it, (4) had an independent entity validate the security of the disclosure (discussed below), and (5) enables users to request data deletion should they choose to uninstall.
The safety section displays all of this information first with a summary of the app’s practices. A user can tap a summary to see more details about the type of data the app collects and how the app uses that data. For example, as shown below, a user can click on the “Data privacy and security” summary to learn more and can click further (right arrow) to see what each data type is used for. In Google’s example for ‘Shareo’, they chose to feature that the app only collects 8 types of data. By clicking into “Data privacy and security”, the user can see what the 8 types of data collected actually are and click further to see that the “location” data type is used for “App functionality,” “Personalization,” and “Analytics.”
A Word On The Term ‘Safety’
Google’s co-mingling of the terms ‘safety’ with policies related to security and privacy is concerning. Mobile-centric companies like Uber and Facebook have done a great job distinguishing between the tenants of protecting their app users from digital or real-world harms versus their internal data use or data protection practices. The privacy community has also worked hard over decades to create privacy policies, whether they are legal statements or designed for consumer education, which Google is glossing over with the ‘safety’ term. I commend Google for attempting to simplify Android app privacy policies, and adding security as a core component of the updates, but their titling of this section as ‘safety’ is misguided and misconstrues what these self-attested statements are intending to provide to Google Play users. I would also note that many of these self-attested privacy statements will disclose that apps are sharing, licensing, or outright selling user data, which may be viewed by some as antithetical to ‘safety’.
Comparing Google and Apple’s Approaches
When comparing the two app store approaches, Apple’s Nutrition Label is more formulaic. The Nutrition Label is divided into 3 sections: (1) “Data Used to Track You”; (2) “Data Linked to You”; and (3) “Data Not Linked to You.” For each section, the developer must state the types of data collected/used by the developer and/or any third-party partners as well as for what purpose. The main difference is that Apple has predetermined exactly what ‘types of data’ and ‘purposes’ are available for app developers to enter (see below) so a developer must attempt to match their practices with one or more of Apple’s predefined types of data and purposes, regardless of whether there are discrepancies with the term being applied or ‘grey’ areas in how they’re applied (eg; this app may ‘track’ in the U.S., but not in the EU).
While Apple’s Nutrition Label is more laid out than Google Play’s safety section, both require disclosure of data collection and use practices. Both also allow users to see why the data is collected and/or used. Apple calls this “purposes” and Google calls this “What it’s used for.” As of the writing of this article, Google has not announced any predetermined types of data or purposes, but in their recently released video, Google shows “app functionality,” “personalization,” and “analytics” as potential answers to “What it’s used for.”
Apple’s predetermined and predefined types of data collected and/or used.
Apple’s predetermined and predefined purposes for data collection and use.
Self-reporting, pre-approval, and enforcement
Both app stores generally are an ‘honors system’ for self-attestation. As reported in The Washington Post in this article, it appears that Apple does not regularly review the labels with app developers to ensure accuracy. However, Apple will apply their ‘AppTrackingTransparency’ framework policies to apps that disclose in the Nutrition Label that they are ‘Tracking’, but have not yet configured the ATT consent popup in the app itself.
Google Play’s safety section adds a new option for developers to add an ‘Independent security verification’ with their attestation. Presumably, this will be limited to well-known industry standards such as ISO 27001 or SOC II audits, but perhaps will be open for the app developer to choose what to include with any self-attestation. It is also unclear whether Google will expand the scope of the attestations to include privacy-specific (or even ‘safety-specific’) audits, or assessments. Google also plans to hold developer’s responsible for their disclosures by stating that if there is a misrepresentation in a disclosure, Google will require the developer to fix it and if apps don’t become compliant, Google will enforce this policy.
Additional Google Play Store Privacy Updates Coming Soon (link)
Ads Policy: Effective as of October 4, apps that use the Android Ad ID (AAID) will be modified so that when a user opts-out within their Android device operating system settings, they will no longer receive an opt-out signal or refreshed AAID, but instead the AAID will be replaced with zeros. This emulates Apple’s pre-iOS14 ‘Limit Ad Tracking’ feature, which resulted in approximately 30% of user opt-outs prior to the ATT release (and was the subject of a formal EU GDPR complaint by NOYB which will now be moot). Android users will still have a choice to opt-out or reset their AAID, which is a contrast with Apple’s IDFA where no such ‘reset’ is available.
User Data Policy: Effective October 28, Google will be revoking default use for combining ‘personal and sensitive’ information with AAID’s. The policy seemingly only applies when apps combine the AAID with device or user-specific information, as described in their ‘User Data’ policy. In these instances, apps will need to acquire consent, similar to what is required by Apple for all ‘Tracking’, albeit Google will enable apps to provide their own in-app disclosure and consent mechanism rather than utilize a Google-mandated consent mechanism as is the case with Apple’s ‘ATT’. For the most part, this Google policy follows well-established advertising principles adopted by the Network Advertising Initiative (NAI) in their Code of Conduct.
Google prescribes app consent to be akin to compliance with the EU GDPR consent (as opposed the Apple ATT consent which is in conflict with the GDPR);
Must present the consent dialog clearly and ambiguously;
Must require affirmative user action (e.g., tap to accept, ticka check-box);
Must not interpret navigation away from the disclosure (including tapping away or pressing the back or home button) as consent; and
Must not use auto-dismissing or expiring messages as a means of obtaining user consent.
With this change, it is likely more Consent Management Platforms (CMPS) will be engaged to assist Android apps combine their GDPR compliance efforts with Google policy compliance.
Permissions Reset: In December, Google will expand an existing requirement for apps that have requested specific runtime permissions (eg; location) to be opened and used in the prior ‘few’ months (why can’t they be specific?) in order to retain their permission status. The new policy will apply to all apps running on Android 11, and applies to permissions such as location, camera, or media access.
For more information on compliance with Android terms and how it intersects with global laws, refer to this primer by @Termsfeed
