Apple’s important mandatory requirements affecting iOS apps are about to kick in, and Google’s new requirements for publishers and advertisers have just gone into effect. Accurately implementing these requirements calls for close cooperation between the legal, privacy, and ad ops teams.

Apple’s Privacy Manifests

At WWDC 2023, Apple announced privacy manifests, signatures for SDKs, and required reason APIs. In early 2024, Apple began requiring a privacy manifest for every new or updated app and every third-party Software Development Kit (SDK) in the Apple App Store. The privacy manifest must include four pieces of information:

1. The type of data collected by the app or SDK.
2. How the data collected will be used by the app or the SDK.
3. Whether the data are linked to the user.
4. Whether the data are used for tracking, as defined by Apple.
   

What are Privacy Manifests, and what benefits do they provide?

Privacy Manifests are an important tool for third-party SDK developers and app developers to communicate critical information about their privacy practices with app developers and Apple. Privacy manifests describe in detail their use of data and select system APIs, called “required reason APIs,” which may require collaboration with legal teams to ensure accurate reporting. Data categories include Contact Information, Health and Fitness, Financial Information, Location, Search History, User Content, Purchases, and a category for Other Data Types not covered in one of the defined categories. The data collected in each category should be assigned a defined purpose in the property file. Example purposes include: App Functionality, Analytics, and Third-party Advertising. A defined “other purposes” category exists as a catch-all. 

Privacy Manifests provide several benefits once defined. First, they build on App Tracking Transparency (ATT) in that any network requests to any of the tracking domains made when the user has chosen not to be tracked will automatically fail. Building this into the platform ensures that apps or SDKs cannot accidentally violate user consent because it will actually be impossible for the app to complete the network request. App developers who are unaware of the tracking third-party SDKs do may no longer have to worry and can simply state which tracking domains they know they need to use.

Second, privacy manifests allow developers and Apple to know why third-party SDKs and apps are using select system APIs. This is possible because every developer must specify their reason for needing to use these system APIs. Functionally, this reason is specified in a similar manner to data categorization and use described above. Instead of defined data categories and purposes, developers must select a defined reason for using any of the APIs defined in the developer documentation of the privacy manifest feature.  These requirements will start being enforced on May 1st.

The goal of the “required reason” API feature may be intended to prevent software fingerprinting, which is a type of tracking that uses differences in preferences, settings, and hardware capabilities to uniquely identify users. Consider the use of an API that returns information on how much space is left on the file system. This could be done to ensure the space available is enough for a large network transfer, but it could also be done as a data point to uniquely identify a device. The former is an acceptable reason that can be specified as such in a privacy manifest, whereas the latter may raise privacy implications or violate platform guidelines.

Third, organizations implementing privacy manifests can generate a Privacy Report by automatically combining the application’s privacy manifest with all of the privacy manifests of the third-party SDKs used by that app. The report is a PDF that describes data and API uses broken down by category (e.g., contact information, health and fitness, etc). It does not replace Apple’s Privacy Nutrition Labels in the App Store, but can be used by organizations as a reference when making those assessments. 

Finally, Apple has defined and will maintain a list of third-party SDKs that require a privacy manifest and an application signature. Developers have had to be extremely cautious in adopting new SDKs because they are responsible for all the code in their app as well as the code in third-party SDKs included in their app. The goal of combining privacy manifests with an application signature is to improve the privacy and security of the software supply chain by helping developers determine when data practices have changed and respond appropriately to those changes. For example, developers may choose to update their Privacy Nutrition Label or replace a third-party SDK that no longer has acceptable data practices.

How should developers prepare for this update?

App developers who want to remain in the App Store must prepare a Privacy Manifest. Some aspects of the privacy manifest will be quite straightforward, like uses of data and APIs that are part of the software’s core functionality and clearly fit into the defined categories. Other aspects may not be immediately obvious. Therefore, developers should be proactive in reaching out to the appropriate people within their organization to ensure they provide the most accurate categorization possible. The goal is clear: the privacy manifest should be a comprehensive report on all data used by the application, but it is not prose text, just a categorization of data collection and usage rationale based on the available defined categories and purposes available in the Privacy Manifest specification.

Google’s Consent Mode v2

Google began enforcing changes to its advertising platforms in Europe starting March 2024. These changes require publishers to update to Consent Mode version 2 in either a basic or an advanced configuration.

A brief history and description of Consent Mode and Consent Mode v.2

Consent Mode was released in 2020 as part of Google Tag Manager, a tool available to publishers using Google Advertising services that provides publishers with an optional set of controls for advertising and analytics tags. Consent Mode helps publishers to communicate user consent status to Google such that it can guide future interactions with any person, such as tracking or advertising. Consent Mode works with Consent Management Platforms (CMPs) to provide more options to publishers seeking to comply with European data protection regulations in their advertising technology stack, including advertising and analytics tags for both Google and third parties. Google Ads also supports the IAB’s Transparency and Consent Framework (TCF), and recommends implementing either TCF or Consent Mode to communicate consent, but not both. If both are implemented, Google respects the most conservative setting communicated, and their recommendation to implement only one of these two options is driven primarily by performance considerations.

In late 2023, Google released Consent Mode version 2, an update that was designed to provide more nuance in recording an individual’s preferences as well as in reaction to legal updates in Europe. Specifically, Consent Mode version 2 introduces two new parameters: ad_user_data, which captures consent for personalized advertising, and ad_personalization, which captures consent for remarketing. These parameters do not have an impact on how tags operate on the publisher site and only communicate how user data can be used for advertising to Google.

By way of comparison, the parameters from Consent Mode version 1 are ad_storage, which enables the storage of identifiers for advertising on both web and mobile platforms, and analytics_storage, which enables the storage of identifiers for analytics on both web and mobile platforms. So, one way to think about these changes is to think of the tags from Consent Mode version 1 as qualifiers for which identifiers can be stored and the tags from Consent Mode version 2 as instructions for Google on how to process the data collected.

With the new parameters introduced in Consent Mode version 2, Google also introduced two new configurations: a Basic configuration that prevents any loading of Google’s tags without user consent, and an Advanced configuration that loads Google’s tags prior to user consent but only sends a cookieless ping until user consent is obtained. The Advanced configuration can be customized for each advertiser tag. Sites based on Consent Mode and seeking to ensure that tags are always available to collect information with consent must implement either Basic or Advanced Consent Mode version 2 configuration.

Check-in with your CMP to review further implementation details. OneTrust has more details on their integration, as does Sourcepoint. Google’s support documentation contains pointers to configuring other CMP integrations.

What should publishers using Google advertising services do to comply in response?

First, publishers hosting a site with users in the European Economic Area (EEA) should, at an absolute minimum, implement Consent Mode version 2 in its Basic configuration.

If you have done nothing else, a Basic configuration of Consent Mode is a relatively quick way to ensure that you are not collecting data without user consent. 

Second, publishers can create an Advanced configuration with their advertising and marketing team. Advanced configurations are capable of more nuanced privacy controls that may more efficiently achieve advertising goals. This approach can include AI modeling, templates for different consent management platforms, and per-advertiser configuration of tags. The details of a custom configuration are outside the scope of this post, but an Advanced configuration may prove to be the best option available for many publishers.

Summary

European data protection requirements and related DPA enforcement and court decisions continue to shape the technology and policy interactions between different stakeholders in the ad tech ecosystem. Obligations that large platforms have under DSA, DMA, and other EU digital strategy developments will continue to drive new platform obligations. Google began enforcing Consent Mode v2 in March, and Apple will start fully enforcing their privacy manifest requirements on May 1st. Both of these features will be implemented by developers, but both of them have legal implications that likely require detailed privacy review.