The A to Z of compliant apps

A is for Apps (no surprise there)

Apps create new challenges in terms of data protection compliance. The small screen and desire for quick and simple functionality means obtaining specific and informed consent may be more difficult than on a desktop. The technological practicalities, combined with the often low-budget, quick-to-market nature of app development means data protection compliance is generally fairly low across the industry, and even organisations with stringent privacy policies and detailed data collection notices on their website frequently ignore the issue when it comes to their app.

However, as tablets and smartphones become the primary means by which consumers access the internet, there are signs that data protection in apps may not be sidelined for much longer. Earlier this year, the Article 29 Working Party (made up of representatives from all the EU Data Protection Authorities), published an opinion on apps on smart devices.

In this alphabet, we examine the Working Party’s recommendations and discuss some of the practical options for app developers to achieve higher levels of data protection compliance.

B is for Business case

The Working Party recommends that app developers consider the purposes for which they will be processing personal data at the very start of the app development process. Since data minimisation and purpose limitation are fundamental principles underpinning the EU Data Protection Directive (95/46/EC), app developers should consider in each case whether they need to collect a particular dataset from the user.

Apps can be written and made available to the public in a matter of days, and sometimes the software developer may not have fully considered the functionality of the app – adding extra means of data collection which are not necessary. Having a well thought out business case, which includes data protection considerations, before the development stage will enable app developers to create an app which only collects the minimum amount of data necessary. This has the dual advantage of complying with the data minimisation principle and reducing risk exposure in terms of the data handled.

C is for Controller

EU law in general only imposes obligations on the “data controller”—the legal person who determines the purposes and means of the processing. A question which therefore arises in the fragmented world of app development is, who is the controller?

The Working Party identified four main parties who may be processing personal data in the context of apps: app developers, OS and device manufacturers, app stores, and third parties (mostly advertising networks).

This note focuses on app developers, i.e. those who create apps and/or make them available to users. In most cases, since they determine what the app does, the app developer will be a data controller in respect of the personal data collected by the app. Subject to discussions around jurisdiction, app developers will therefore be responsible for complying with the requirements of EU data protection law.

D is for Data

Specifically, “personal data”, defined in the Data Protection Directive as any information relating to an identified or identifiable natural person. The vast majority of apps collect and process some form of personal data. Sometimes this is data voluntarily provided by users (e.g. a name or email address), sometimes it is collected from the device (e.g. geo-location or a Unique Device Identifier), and sometimes it is generated by the app itself (e.g. a purchase history).

Under the Data Protection Directive, data controllers must have a legal basis for processing personal data. In the case of apps, the principal basis will be that in Article 7(a): that the data subject has unambiguously given his consent. The Working Party emphasises that this consent should be freely given (i.e. revocable), specific and informed.

It is worth briefly mentioning here that the users of the app may not be the only data subjects. For example, apps which process photographs may well have personal data relating to third parties, and phone address books certainly will. In these examples, the user would most likely be considered the ‘data controller’, but fall outside the scope of the Directive because of the ‘household activity’ exemption in Article 3(2). Nonetheless, app developers should be extremely cautious about processing this third party data for their own purposes (e.g. using a photograph in an advert for its app, or contacts for marketing purposes).

E is for ePrivacy Directive

Even if an app is not collecting ‘personal data’ from the user’s device, it may still be subject to the ePrivacy Directive (2002/58/EC), as amended – also known as the “cookies law”. Article 5(3) of the ePrivacy Directive requires prior consent to the “storing of information, or the gaining of access to information already stored” on a user’s device. The requirement applies to any information being stored and/or accessed, not only personal data.

Furthermore, the ePrivacy Directive has potentially more expansive jurisdiction that the Data Protection Directive, since it applies to all services offered in the European Economic Area. So if the app is made available in the EEA, regardless of where the app developer is based, the ePrivacy Directive will apply. (See “J” for discussions about the jurisdiction of the Data Protection Directive).

The ePrivacy Directive therefore provides a further legal obligation on app developers and app stores to seek consent to both the download of the app (being information stored on the device), and access to any information on the device (see “D” for discussion of consent as a lawful grounds for processing). This consent will only be valid if the user has been given “clear and comprehensive information” about the processing.

In practice, if enough information is provided to the data subject, consent under the ePrivacy Directive and the Data Protection Directive can be merged.

F is for Function creep

The Working Party cautions against ‘function creep’ by app developers, without seeking further consent from users. Many apps are put on the market quickly, often by start-up companies whose business is still evolving. New updates to apps should not materially alter the information being processed or the purposes for which it will be processed unless the app developer has obtained further consent from the user (i.e. beyond general consent to the update).

The Working Party also recommends that users be given the technical means to verify statements made by app developers about declared purposes, by allowing them to access information about the outgoing traffic on the app. However, it is unclear how practicable this would be – particularly for simple/free apps.

G is for Granular consent

Article 2(h) of the Data Protection Directive requires that consent to data processing be specific. In the context of apps, the Working Party is of the view that asking users to accept a lengthy set of terms and conditions and/or a privacy policy will not constitute specific consent. Accordingly, consent should be sought at a more granular level, enabling individuals to specifically control which personal data processing functions they want to activate within the app.

This obviously has an impact on the software developers, who would potentially need to develop more sophisticated functionality to allow a user to select different options. One good example is the now standard approach of seeking specific consent to access geo-location data on iPhones. This is a model is increasingly being adopted with respect to other forms of data processing.

H is for Handheld devices

Arguably, as use of the internet generally moves to handheld devices, app developers, app stores, OS manufacturers etc., will find it increasingly difficult to rely on the argument that compliance cannot be achieved by apps because of the limits of a small screen. Website operators adapting their pages for handheld devices are faced with similar challenges in terms of maintaining accessible terms of use, privacy policy and cookies consent.

I is for Informing users

In order for the consent to be valid under both the Data Protection and the ePrivacy Directive, the user must have sufficient information about what they are consenting to. The Working Party sets out the minimum information which should be provided to users:

  • Identity and contact details for the controller. The Working Party emphasises that there should be a single point of contact for the app (even where there are a variety of different parties working together on a project).
  • The precise categories of data being collected and processed.
  • The precise purposes for which the data will be processed.
  • Whether data will be disclosed to third parties.
  • How users may exercise their rights in terms of withdrawal of consent and deletion of data.

As a minimum, the app should have an easily accessible privacy policy containing all of the above information. The information should be provided prior to the personal data processing–which essentially means the privacy policy must be available via the app store, in advance of installation. A study in June 2012 found that over a third of the top 150 apps had no privacy policy at all.

The Working Party also suggests that apps which will not process personal data should clearly state this within their privacy policy. However, this begs the question as to why/whether such apps would need a privacy policy in the first place.

J is for Jurisdiction

Where an app developer is established outside the European Economic Area (and does not use equipment to process data in the EEA), can it simply ignore the requirements of the Data Protection Directive?

The Working Party thinks not. They rely on the much-debated argument that the user’s device will satisfy the jurisdictional criteria in the Directive that the controller “makes use of equipment…situated on the territory of the said Member State.” According to the Working Party, “since the device is instrumental in the processing of personal data from and about the user, this criterion is usually fulfilled”. It is difficult to see how apps differ in this respect from a website accessed via a desktop, so this logic could potentially expose all websites worldwide to EEA jurisdiction. However, the Working Party does clarify that “use of equipment” test will not be satisfied where data is only processed locally on the device and not transmitted to a server.

K is for Kids

Children are an enormous market for apps. Similar considerations apply to apps as to websites directed at children, for example in terms of ability to consent, and presenting information in a suitable language and format. The EU Good Practice Principles (implemented in the UK by the CAP Code) contain a specific commitment that online behavioural advertising should not be targeted at children under the age of 13.

However, there are particular aspects of handheld devices which may increase the risks. Parental control is often easier on a desktop or shared device, where websites can be blocked or the computer is kept in a family room. In contrast, parents may have very little visibility of their child’s mobile phone.

There has been several stories in the press recently about “freemium” app games, where children are encouraged to pay for added extras whilst using an app. In April 2013 the Office of Fair Trading launched an investigation into whether these games are misleading, commercially aggressive or unfair—and in particular whether they include “direct exhortations” to children to make a purchase or persuade someone else to make a purchase for them (prohibited under the Consumer Protection (from Unfair Trading) Regulations 2008). Apple has produced specific rules for app developers who are marketing apps in the “Kids Apps” section of its iTunes store. The rules prohibit apps primarily intended for children under 13 from including behavioural advertising, and require such apps to seek parental consent or have a parental gateway before a user can link out of the app or engage in commerce.

L is for a Layered approach

As with websites, a layered approach is recommended as a good way of informing users without overloading them with detail, and is particularly suited to a small screen. For example, an app introduction could provide an overview of the processing, a ‘privacy section’ of the app could provide further information, but still at a relatively high level, and a link to the full privacy policy on a webpage would then hold the full information (but this should still be formatted for a small screen).

M is for Mandatory vs optional data

The Working Party recommends that users should be advised when provision of data is optional (for example uploading a photo to a profile) and when it is mandatory.

N is for Notice

See “I” for details of what information should be included in a data collection notice. There are obvious difficulties with presenting all of this information on a small screen—hence the advantages of a ‘layered approach’ (see “L”). Furthermore, the Working Party appears to question the validity of providing it only by way of a privacy policy.

Accordingly, app developers may want to consider other steps to inform users. Some apps have adopted a short introduction to the app which plays when it first downloads. As well as teaching users about the functionality of the app, this can be an extremely useful opportunity to provide information about data processing. Other alternatives include boxes which pop-up when the user first starts to enter the data, but which can then be easily closed by the user once they start typing.

One point to watch out for when implementing these mechanisms is that the user should be able to access this information again. This requirement could presumably be met by providing a link to the privacy policy from within the app.

O is for Operating System and device manufacturers

The Working Party emphasises that Operating System (OS) and device manufacturers may also be data controllers where they access personal data for their own purposes—such as the smooth running of the device or security.

In the context of apps, the OS and device manufacturers will be responsible for the API which allows the processing of personal data by apps on the handheld device. These parties must therefore ensure the device has sufficient security controls to ensure that an app is only able to access the data which is necessary for the functioning of the app. The Working Party also states that this access should be easily revocable.

P is for Privacy by design and privacy by default

Both ‘privacy by design’ and ‘privacy by default’ will become mandatory if the current draft of the proposed Data Protection Regulation is implemented. This would require app developers to embed privacy controls in the app from the outset—to ensure that the rights of data subjects are protected, and guarantee purpose limitation and proportionality. (See also “B” for Business Case.)

Apps appear to be perfect candidates for encouraging these twin concepts. Apps are never considered ‘finished’ but are constantly being developed, updated, and replaced with new versions; consequently, app developers should be able to avoid the problems faced by some more traditional software developers of trying to later ‘bolt-on’ adequate privacy mechanisms.

Potentially, as users become more aware of the value of their data and the amount being collected over the internet, privacy controls (and in particular security) can become a selling point for apps. The Working Party advocates app stores implementing a ratings system for privacy (similar to that currently used for general ‘popularity’).

Q is for UniQue Device Identifiers

Okay, so a bit of a cheat on the alphabet here. It is important to be aware that unique device and customer identifiers are considered personal data under EU law. This stems from the Article 2(a) definition that an “identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number…”. Consequently, a number of apps which would not on their face appear to be collecting personal data (e.g. simple games), may still be data controllers if they collect UDIs from users.

An admittedly now somewhat out-of-date study by the Wall Street Journal in December 2010 found that 56 of the 101 most popular smartphone apps were sharing these identifiers with advertising networks, often combined with information about the user, without the user’s knowledge or consent. Some of these apps were passing on the UDI alone, but others were sending gender and age information alongside the UDI.

In order to be compliant with EU data protection law, app developers should inform users and obtain consent prior to sharing this information with third parties (see also “T” for Tracking).

R is for Retention periods

App developers should consider the specific timescales for which they will retain personal data. The perhaps more “disposable” nature of handheld devices means data retention may pose more of an issue than where data is accessed only via a PC. For example, users may lose their device, switch to a new one, or pass on their device to someone else, and their data should not remain indefinitely accessible on the old device.

In most cases retention periods will depend on the nature of the data and the purposes of the app. For some apps, the data itself need only be stored for a certain period (e.g. a route planner might only need to retain location data for as long as it takes to reach a destination). Other apps may wish to retain historical information whilst the app is regularly in use, but still consider deletion where the user has not the used the app for a certain period. For example, if a user has not accessed the app in one year, the user should be alerted and given the opportunity to either retrieve their personal data or have it permanently deleted. Obviously some apps (e.g. those related to Christmas), would only expect to be accessed on an annual basis, and so could have longer inactivity periods.

It is less obvious how the notification could be implemented for apps where a user does not provide an email address and has selected not to receive “push” notifications.

S is for Security

App developers should not rely on the OS or device manufacturers to protect the user’s data, for example by way of device pin codes or remote destruction. Handheld devices are easily lost or stolen, and so careful thought should be given when developing an app where the user will stay logged in, or where there is no login process at all. This is obviously of particular concern if the app may contain financial or sensitive personal data.

Part of the reason for the extreme success of apps is their simplicity and user-friendly interfaces. App developers are always looking to reduce the number of click-throughs—so requiring users to enter lengthy usernames and passwords each time will frequently not be favoured. As an alternative, developers could consider short pins or further verification for only those parts of the app which contain sensitive personal data. For example, a shopping app would not need a verification process if the user was only browsing or adding to a basket or wish-list, but clearly would do when it came to making a purchase.

T is for Tracking

App developers (particularly those marketing free apps) frequently rely on advertising to generate revenue. This is yet another reason why collecting information about the user is often vital to the success of an app.

However, the Working Party advises that the requirement for specific consent also applies to tracking. Accordingly, the default settings provided by Operating Systems and apps should be set to avoid tracking. Users must then ‘opt-in’ to tracking. One issue raised by the Working Party is that the ‘Do Not Track’ tools which can be downloaded onto desktop browsers are not yet generally available for handheld devices. Users concerned about tracking therefore have significantly less ability to prevent tracking of their internet use on their smartphones or tablets than they do on their desktops.

If the EU’s data protection authorities were to enforce this requirement for specific consent for tracking, this would presumably have significant ramifications in terms of advertising revenues (since it is questionable how many users would ‘opt-in’ if given the choice).

U is for Updates

It is good practice to provide regular updates (and encourage users to regularly install these) in order improve the app’s technological security measures. App developers should be aware of continuing developments in terms of hacking and security threats and, as necessary, update their technology to combat these.

However, updates should not process new personal data, or process personal data for a new purpose, without seeking further consent from the user. A general consent to the update will not constitute consent for the purposes of data processing (see also “F” for Function creep).

V is for Vagueness

Consent should be specific and informed—so app developers should avoid vague data processing purposes such as “business development” or “research”.

W is for Withdrawing consent

In order for consent to be considered “freely given” under the Data Protection Directive, it must also be revocable. A user must therefore have the ability to withdraw their consent to the specific processing at any time. Where consent has been sought at a granular level, the ability to withdraw consent should also be available at this level—so when a user has specifically consented to geo-location data being accessed, they should not have to delete the app if they change their mind.

Once the consent has been withdrawn, the data controller can obviously no longer rely on it as a lawful ground for processing the data: it is therefore unlikely to have any lawful grounds for retaining such data on its own systems, and so should delete it. There will, of course be exceptions, for example in relation to payment information which may need to be retained for their own business records.

X is for EXercising your rights

The Data Protection Directive grants data subjects various rights as regards the processing of the personal data, including rights of access, erasure and rectification.

The Working Party stated that the minimum information provided to app users should include how users may access their rights in terms of withdrawal of consent and deletion of data. This suggests that information about subject access requests and rectification can perhaps be made available elsewhere, e.g. by way of a privacy policy or a link to a full website. A word of caution, however, in that there is some inconsistency in the Working Party’s position here; elsewhere in the opinion, it advises that “apps must clearly and visibly inform users about the existence of these access and correction mechanisms”.

In terms of best practice, access tools should be available within the app itself or via a link to an online feature, so that users can get access to their data instantly—as opposed to having to submit a manual request to the app developer. Where an app supports a website, the more features which can be included in the app in terms of data correction and deletion the better, instead of requiring an app user to visit the website to benefit from these functionalities.

Y is for Yes or No: having a genuine choice

Consent implies that a user has a genuine choice as to whether to allow the processing. This means that app developers should avoid relying on users only having the choice to withdraw their consent at a later stage (e.g. by deleting the app or changing a default setting). This is particularly the case for apps which collect data automatically from a device from the outset.

It is not uncommon to see apps where the user is only given the option to say “Yes”, or reach a ‘dead-end’ within the app. Ideally, during the app introduction/notification process, there should be an opportunity for the user to decline or delete the app.

Z is for Zombies.

There are over 4,000 Zombie-related apps on the Apple app store (“Plants vs. Zombies” being my personal favourite).