Managing Mobile App Consent

Managing Mobile App Consent

Overview

Mobile applications present unique consent challenges: platform-level permission systems (Apple ATT, Android runtime permissions), advertising identifiers (IDFA/GAID), SDK-level data collection by third-party libraries, and limited screen real estate for consent interfaces. Compliance requires coordination between GDPR/ePrivacy requirements and platform-specific privacy frameworks.

Apple App Tracking Transparency (ATT) Framework

Requirements (iOS 14.5+, enforced April 2021)

Apple's ATT framework requires apps to request user permission before tracking across apps and websites owned by other companies. Key aspects:

• NSUserTrackingUsageDescription: Apps must include a purpose string in Info.plist explaining why tracking is needed.
• ATTrackingManager.requestTrackingAuthorization(): Must be called before accessing IDFA or performing tracking.
• IDFA Access: The Identifier for Advertisers (IDFA) returns all zeros unless the user grants ATT permission.
• Tracking Definition: Apple defines "tracking" as linking user/device data from your app with data from other companies' apps/websites for advertising or sharing with data brokers.

CloudVault SaaS Inc. ATT Implementation

Purpose String (NSUserTrackingUsageDescription): "CloudVault uses this identifier to measure the effectiveness of our advertising campaigns and provide relevant ads. You can change this in Settings at any time."

Pre-Permission Prompt (shown before ATT dialog): CloudVault SaaS Inc. displays a custom pre-permission screen explaining the value exchange before triggering the system ATT dialog:

"Help us improve CloudVault by allowing measurement of our advertising. This helps us understand which ads brought you here and improve our marketing spend. Your data is never sold. You can change this choice in iOS Settings at any time."

[Continue] → triggers ATTrackingManager.requestTrackingAuthorization()

ATT States and Handling

Android Permission Model and Privacy Changes

Android 13+ (API 33) Ad ID Changes

• AD_ID Permission: Apps must declare com.google.android.gms.permission.AD_ID in AndroidManifest.xml to access Google Advertising ID (GAID).
• Google Play Requirements: Apps targeting children must not access GAID.
• User Reset: Users can reset or delete their GAID in Android Settings.

Android Privacy Sandbox (In Development)

Google's Privacy Sandbox for Android introduces:

• Topics API: Returns coarse-grained interest topics (replaces FLoC for mobile)
• Attribution Reporting API: Privacy-preserving ad attribution (similar to SKAdNetwork)
• FLEDGE: On-device ad auctions without cross-app tracking

CloudVault SaaS Inc. Android Implementation

xmlCopy code
<!-- AndroidManifest.xml -->
<uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

GAID is only accessed if the user has granted consent for advertising purposes through the in-app consent flow. If consent is not granted, GAID is not read.

In-App Consent Flow Design

First Launch Consent

Copy code
App First Launch
  │
  ├─► Step 1: Welcome screen with privacy summary
  │     "Welcome to CloudVault. Before you get started,
  │      let's set up your privacy preferences."
  │     [Set Up Privacy]
  │
  ├─► Step 2: Layered consent screen
  │     ├─ Purpose 1: Analytics [Toggle, OFF by default]
  │     │   "Help us improve CloudVault by sharing anonymous usage data"
  │     │   [Learn More] → detailed Art. 13 information
  │     │
  │     ├─ Purpose 2: Advertising Measurement [Toggle, OFF by default]
  │     │   "Measure which ads brought you to CloudVault"
  │     │   [Learn More] → detailed information + ATT context
  │     │
  │     ├─ Purpose 3: Crash Reporting [Toggle, OFF by default]
  │     │   "Share crash reports to help us fix bugs faster"
  │     │   [Learn More] → data types, retention
  │     │
  │     └─ "You can change these at any time in Settings > Privacy"
  │
  ├─► Step 3: Record consent decisions
  │     ├─ Per-purpose consent records (standard fields)
  │     ├─ Platform: iOS/Android
  │     ├─ OS version, app version, device model
  │     └─ SDK consent propagation (see below)
  │
  ├─► Step 4: Platform-specific follow-up
  │     ├─ iOS: If advertising consent granted → trigger ATT dialog
  │     └─ Android: If advertising consent granted → access GAID
  │
  └─► Step 5: Proceed to app
        └─ SDKs initialized based on consent state

SDK Consent Propagation

Third-party SDKs in the CloudVault mobile app must respect user consent:

SDK Initialization Pattern

SDKs must not be initialized before consent is obtained. CloudVault SaaS Inc. implements a "consent gate":

1. App launches → load only essential SDKs (no tracking)
2. Consent flow completes → read consent state
3. For each SDK: initialize only if corresponding purpose is consented
4. If consent is later withdrawn: disable SDK data collection (where SDK API supports it) or defer to next app restart

IDFA and GAID Handling

Key Regulatory References

• GDPR Article 5(3) via ePrivacy Directive — Consent for device storage access
• GDPR Article 7 — Conditions for consent (apply to in-app consent)
• Apple ATT Framework Documentation — App Tracking Transparency requirements
• Apple App Store Review Guideline 5.1.2 — Data Use and Sharing
• Google Play Developer Policy — Advertising ID and User Data
• CNIL Mobile Privacy Guidelines (2023) — Mobile-specific consent requirements
• EDPB Guidelines 05/2020 — Consent in mobile context