Apple iOS14 Changes: ‘Your App’ May No Longer Mean ‘Your Data’

Ben Isaacson Lucid Privacy

Data-Driven Thinking” is written by members of the media community and contains fresh ideas on the digital revolution in media. 

Today’s column is written by Ben Isaacson, Principal at Lucid Privacy Group.

By now, you should be well aware of Apple’s imminent changes to its App Store terms that will require consent for ‘Tracking’ iOS users across apps and websites, kicking off with the release iOS14.5 in the next month—or so.  (Apple hasn’t confirmed a release date, but their reference to ‘Spring’ and prior history of releases within a month of their beta release indicates a March release date.)  

While the advertising and marketing industry is well-versed in getting consent for cookies and email marketing, Apple’s approach attempts to go beyond consent exclusively for their device-specific Identifier for Advertisers (IDFA) to include any data collected or associated with an iOS device, including registered user email addresses. For the first time in the marketing industry, a technology platform is attempting to apply its own self-regulatory privacy principles to the entire world.  

The new challenge for marketers is defining where Apple’s policies end, and their own data rights begin. It should be clear that retargeting an iOS app user with interest-based ads on another iOS app by using a hashed email address or phone number will be restricted without Apple’s ATT consent, but there are many additional scenarios to consider based on Apple’s ‘AppTrackingTransparency Framework (ATT)’ policy language and FAQs, including:  

  • There is seemingly no ‘grandfathering’ of previously collected data. Once you choose to implement the ATT to acquire consent from app users, it is expected to be associated with all data previously associated with that iOS user. While avoiding implementing the ATT altogether may seem like a good way to avoid this conflict, and may also be a possible reason why Google has chosen not to implement the ATT, it is still arguably within the scope of Apple’s policies to enforce uses of any iOS registered user data that is in conflict with its ATT terms.

  • What about ‘non-retargeting’ uses? Another ‘grey’ area of Apple’s current published statements is that their language restricts Sharing a list of emails, advertising IDs, or other IDs with a third-party advertising network that uses that information to retarget those users in other developers’ apps or to find similar users.” There are a multitude of scenarios where iOS registered user data may be used for suppressions, branding, affiliate campaigns or relevant ads that are not based on unique in-app behaviors. The ad industry has invested 20+ years in self-regulatory policy for digital marketing, currently summarized in the well-established Digital Advertising Alliance (DAA) Principles on Interest-Based Advertising.  Now that Apple is wading aggressively in these waters, it would be helpful to signal alignment with these efforts, at least as a foundational principle.  Unfortunately, Apple has made no statement to this effect.

  • The tale of the “dual apper”. One can only imagine the horror from inside Apple HQ when it finds out that there are actually registered users of the same app on both iOS and Android!  What will happen when that “dual apper” receives a targeted ad on their iOS device that was the direct result of “Tracking” from an Android device or with their “dual app” registered user data?  Will Apple remove the advertiser’s app from the app store for this slight even though it is technically not a violation of Apple’s published statements?

  • Does the ATT consent really bundle licensing app data to third parties with sharing data with confidential measurement providers? Strangely, the answer is yes. Apple’s definition of “Tracking’” and the default ATT consent language makes no distinction between licensing, renting, or even outright selling app data from apps sharing confidential information with trusted vendors like mobile measurement providers (MMPs). While the ATT does not change apps’ regulatory requirements, such as compliance with the GDPR or California’s “Do Not Sell My Personal Information” right (which the ATT “consent” does not override), Apple’s approach seems to consider vendors requiring the same consent as data brokers. Like with the passage of the CAN-SPAM Act that enabled sales of email addresses to any “sender,” Apple’s blind spot in their ATT is that they may be enabling a new market for consent-based app data brokerage (and negatively impacting apps’ use of legally-controlled service providers).

No Anti-Fraud Fingerprinting 

Another key aspect of Apple’s policy is their update to the SKAdnetwork, which effectively forces all publishers and ad networks to share ad respondent data with Apple to ‘anonymize’ so advertisers or their MMPs can’t uniquely attribute individual behaviors. While Apple’s intention may be a privacy best practice, it will challenge advertisers' ability  to identify fraudulent ad campaigns, such as the tactics insinuated in the Uber vs Phunware lawsuit. Besides making it harder for advertisers to identify fraud, Apple has ‘doubled down’ on its restriction around device fingerprinting, stating “you may not derive data from a device for the purpose of uniquely identifying it. Examples of user or device data include, but are not limited to: properties of a user’s web browser and its configuration, the user’s device and its configuration, the user’s location, or the user’s network connection. Apps referencing SDKs, including but not limited to Ad Networks, Attribution services, and Analytics, that are found to be engaging in this practice may be rejected from the App Store.”  In other words, even if an advertiser or app attempts to identify and aggregate device-specific data exclusively to identify fraud, Apple may still reject that app (and its MMP) from the app store.

And finally… the consent conflict.  

As we know from compliance with Europe’s General Data Protection Regulation (GDPR), the optimal approach for marketers to acquire consent from users is to  establish four “consent pillars”: 

  • Freely given: The individual must have a real choice, and not through a “clickwrap” consent, or be in any way coerced into providing their assent to that choice.  
  • Specific: The language used and the choices given must be unique, so that disparate uses or activities are not bundled together or confusing. 
  • Informed: Even if it seems obvious, the user must know who is getting their consent, why and for what purpose, and it should not be buried in small font legalese. 
  • Unambiguous: An “unchecked” box. Enough said.  

After grappling with this EU requirement for the past few years, websites have finally reached consensus on acquiring this level of consent for cookies, and we now see this same cookie consent extended to global website visitors. Surely, if this optimal EU-compliant consent were extended through iOS apps to their registered users for “Tracking” email addresses or other identifiers independently of the ATT, Apple would align with this approach?  Unfortunately, Apple has only offered some tangential statements such as this FAQ: 

“If a user provides permission for tracking via a separate process on our website, but declines permission in the app tracking transparency prompt, can I track that user across apps and websites owned by other companies?

Developers must get permission via the app tracking transparency prompt for data collected in the app and used for tracking. Data collected separately, outside of the app and not related to the app is not in scope.” 

From this and other published statements, we can derive many important legal, privacy and compliance questions: 

  • Is Apple’s definition of “permission” the same as the GDPR’s freely given, specific, informed and unambiguous consent
  • Is collecting this form of consent on the web with specificity for app users still unacceptable to Apple?
  • Would Apple restrict iOS apps from getting this type of consent in-app when this approach clearly aligns with the ATT consent, is in compliance with the GDPR/global regulatory requirements and follows well-established industry best practices? If the answer to this is ‘no’, then how is an EU app developer supposed to comply with the GDPR?
  • Would Apple really remove or reject an app update that follows this global privacy best practice?    

On this last point, I would be remiss not to point out that the Interactive Advertising Bureau (IAB) in France has filed a formal complaint against Apple due, in part, to its ATT consent approach not being compliant with the GDPR. Perhaps if Apple enabled consent management platforms (CMPs) to manage the ATT on behalf of apps, then they wouldn’t find themselves responding to the IAB’s complaint and the many other questions presented in this article.     

Enjoying this content?

Sign up to be an AdExchanger Member today and get unlimited access to articles like this, plus proprietary data and research, conference discounts, on-demand access to event content, and more!

Join Today!

 

Add a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>