Applications on mobile devices
Mobile collect large volumes of often intimate data via sensors (location, audio, video) and stored data (contacts, photos). Devices are rarely shared, so data links more confidently to the owner. Downloading an app and accessing stored data trigger the ePrivacy consent rule. The app developer is usually the controller; but where an app runs purely on-device (edge computing) and sends nothing back, the developer is 'unlikely' to be a controller (ICO). Consent must be granular, and data minimisation / data protection by default apply.
Because apps can only read cookies set within the same app, advertisers track across apps using identifiers like a MAC address or device fingerprinting - and accessing stored info triggers the ePrivacy prior consent requirement. The developer is usually the controller; ad providers may be controllers in their own right; app stores / OS / device makers may be controllers if they log app interactions.
| Scenario | Likely status |
|---|---|
| App collects data and sends it to the developer's servers | Developer is a controller |
| App runs purely on-device, sends nothing back (edge) | Developer 'unlikely' to be a controller (ICO); WP29 says responsibilities 'considerably limited' |
| Ultimate test | Whoever determines the purposes and means is the controller, wherever the processing happens |
Consent for processing not essential to the app's function is generally invalid if required to use the app. Consent must be specific - granular per processing type - and the app should keep working as much as possible if a permission is denied (e.g. still show shop locations even if location is refused). For intimate location data, legitimate interest usually fails and consent is required (WP29).