The General Data Protection Regulation (GDPR), which comes into force in May 2018, places greater responsibility for effective information governance, and transparent data flows on businesses that operate Application Program Interfaces (API), and App stores, for example, Google, Microsoft, Apple, and Amazon. In fact, the GDPR requires all parties within an app ecosystem to protect consumer’s data, including app developers, advertisers, data processors, customer identity management platforms and data analytics companies.
This post explores the impact of GDPR on the following:
- The legal status of Device IDs and the privacy risks that the GDPR seeks to mitigate.
- The shortcomings of the existing security and permission model that underpin the Android API platform
- The privacy-corrosive aspects of third party data processing and security risks posed by multi-app collusion, of which consumers are largely unaware.
The GDPR is expected to alter significantly the parameters of the data economy and catalyse the emergence of a user-centric personal information economy.
Legal status of Device IDs and cookies
The specific provisions of the GDPR, which will be harmonised with a revised ePrivacy Directive, creates legal certainty on the status of Device IDs include:
- Recital 30 which defines the status of Device IDs and cookies as personally identifiable information (PII) and therefore subject to fairness, lawfulness, security, data export and other data protection requirements.
- Recital 26 reinforces this position by stating that where data can reasonably be used, either alone or in conjunction with other data to single out an individual or otherwise identify them indirectly, then it is personal data. Use of pseudonymous identifiers (like strings of numbers or letters), which are what cookies typically contain to give them uniqueness, still makes them personal data.
Moreover, the GDPR explicitly recognises the concepts of ‘privacy by design’ and ‘privacy by default’ which means that businesses will now find themselves subject to a specific obligation to consider data privacy at the initial design stages of a project as well as throughout the lifecycle of the relevant data processing.
Device IDs, PII, data processing and user consent
Advertisers use Device IDs to determine if they have already served an ad to a specific user and to retarget and frequency cap them. In effect, these identifiers fulfil the tracking role for mobile devices that cookies play on the web and enable the aggregation of data about a customer’s behaviours, such as app installs and advertisements viewed, into a detailed single profile. A Device ID is the same for all of the apps and browsers on a specific device and can be linked to cookie IDs that track users activities across platforms.
- 87% of free apps and 90% of paid apps did not encrypt data connections and transmission between the app and the developer’s website(s).
Anonymity and re-identification
An app that gathers, for example, health-related data that is linked to a Device ID, will share this information with third-party services that, serve ads or conduct data analytics. A significant number of the entities connected to third-party services have proprietary back-end databases of information. The transmission of a Device ID to a party whose back-end database contains that same ID, plus an Internet user’s name, address, email or phone number, means that a user, who may believe themselves to be sharing sensitive health data anonymously, becomes personally identifiable. The lack of transparency about data flows and the related privacy and security risks to consumers are of concern to the European Commission, which is conducting a public consultation on the safety of apps.
The provisions of GDPR will have implications for companies like Audience Science, Janrain and Gigya, that collate data about Internet users’ online activities, create psychographic and behavioural customer profile data that enable marketers to better target campaigns.
Third party data processors and liability
Under current EU data protection rules, service providers that process personal data on behalf of other businesses cannot be held directly liable to individuals for a breach of data security. If data processors are at fault for data breaches, then it is the data controller that contracted with them who is held responsible for any non-compliance with data protection laws, although the data processor could be liable to the data controller under their contract. The new GDPR addresses this anomaly and includes third party data processors, and applies a two-tiered sanctions regime.
- Breaches by data controllers of provisions of GDPR, which lawmakers have deemed to be most important for data protection, could lead to fines of up to €20 million or 4% of global annual turnover for the preceding financial year, whichever is the greater.
- Under GDPR, if data processors breach their statutory data security obligations, they can be fined up to €10m or 2% of annual turnover, whichever is greater. These requirements are set out in Article 32, which requires processors to “implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk” of their personal data processing.
- Additionally, under GDPR customers will have the right to pursue either data controllers or data processors for all of the compensation owed to them for the damage they have suffered from a data breach.
The provisions of GDPR mean that mapping data flows within app ecosystems and across platforms will become increasingly important.
Data Flows and Multi-App Collusion
The security model that underpins the Android API was built to combat potential attacks (or misuse) one app at a time, i.e. a user’s approval is required for each app installation. Consumers are implicitly led to believe that by approving the installation of each app independently the privacy risks are clear. However, data flows within an app ecosystem are both complex and opaque, due, in part, to the scope for apps to communicate freely with each other to share their permissions, achieving capabilities through malicious multi-app collusion that a consumer is not able to anticipate. A growing number of studies demonstrate that app collusion attacks against the permission-based mechanisms used on Android OS are a serious threat and that private information stored on a smartphone is at risk. Despite research findings highlighting the risks associated with malicious multi-app collusion, consumers are not routinely made aware of the possible implications for their privacy and security.
Abuse of inter-app communication by cybercriminals can result in the manipulation of two or more apps to orchestrate attacks on smartphone owners. McAfee Labs has observed such behaviour across more than 5,000 versions of 21 apps designed to provide useful user services such as mobile video streaming, health monitoring, and travel planning.
Visit Galois to examine these data flows more closely
Three types of threats that can result from mobile app collusion
- Information theft: an app with access to sensitive or confidential information willingly or unwillingly collaborates with one or more other apps to send information outside the boundaries of the device.
- Financial theft: an app sends information to another app that can execute financial transactions or make financial API calls to achieve similar objectives.
- Service misuse: one app controls a system service and receives information or commands from one or more other apps to orchestrate a variety of malicious activities.
The Engineering and Physical Sciences Research Council (EPSRC) has allocated £3 million to UK researchers to investigate ways of countering malicious apps that collude with each other to infect smartphones. The technologies to detect malicious application collusion across an entire app store are beginning to emerge.
API platform providers and app store operators, such as Apple, Microsoft, and Google, will have a greater role to play in information governance and deploying technical measures to mitigate the risks to both consumers and businesses. Implementing new security models will require the inclusion of relevant guides in the Software Development Kits (SDKs) used by developers to build apps for app stores. The responsibility for data protection will also extend to app developers, third party data processors and those companies that track users’ activities both within app ecosystems and across platforms.
There is scope for trusted intermediaries that operate in a manner transparent to consumers to broker the transactions that underpin the personal information economy on behalf of consumers. Trusted intermediaries will ensure that consumers have greater sovereignty over their data, that there are transparent data flows and that the social contract between businesses and consumers is far more equitable. In effect, GDPR will help to catalyse the emergence of an attribute economy.
About the author:
Dr Rachel O’Connell, founder & CEO, TrustElevate.com a Trust Services consultancy that advises businesses on the technical, legal and policy aspects of electronic identity and related services. Recently she was nominated for a Future CIO award. Rachel’s PhD focused on online criminal activity and the implications for investigative strategies. She is the former Chief Security Officer of BEBO, one of the first mainstream social media platforms and frequently speaks at technology events.