Date:

Mobile Apps: Data Heaven Or Privacy Compliance Hell?

Unless you've been living a hermit lifestyle for the last decade, you won't have missed the mobile application revolution that has come with the rise of the smartphone and tablet computing. Apps drive a considerable stream of data, often hugely powerful data. Much of this data gives great insight into consumer behaviour. All of it is of interest to digital marketeers.

With this data comes legal responsibilities though, and the world's privacy regulators (not unusually for the world of law) are playing catch up.

We digest the EU's most recent privacy guidance in this area, and set out our top tips for staying on the right side of the law.

Background to the EU guidance

The current privacy and data protection rules in the EU are driven by two key pieces of legisation, the EU Data Protection Directive and the EU e-Privacy Directive. This legislation is implemented in the UK through the well known Data Protection Act 1998 (DPA), and the less well-known Privacy and Electronic Communications (EC Directive) Regulations 2003 respectively. (The latter regulations gave us the much derided new cookies laws in May 2012, we'll refer to them here as the Privacy Regs).

All of this legislation is overseen in the UK by the Information Commissioner's Office (ICO).

In order to help co-ordinate privacy and data protection regulatory practice across Europe, the EU has a general guidance body comprised of representatives of all of the 27 Member States' regulators (e.g. the ICO). This body is called the Article 29 Working Party (A29WP), named after the Article in the EU Data Protection Directive under which it is established.

The A29WP's guidance is not legally binding on any regulator, is sometimes a little controversial and there are differences in practice between what it advises, and what the ICO actually does. Nonetheless, its work is thorough and often the best guide we have to go on as to the ICO's likely stance on particular issues.

Our top tips below are based on the A29WP's recent "Opinion on apps on smart devices" published on 27 February 2013.

Quick note on our top tips

The A29WP guidance covers both app developers and their customers, and appstores (Apples iTunes, Google Play and the like). As most organisations don't own an appstore (!) our tips are aimed at app developers and their clients who want to commission apps to release to end users.

Top tips

1. Much (if not all) of the data you collect will be DPA-regulated personal data.

A mobile device's operating system (OS) has one or more application programming interfaces (API's) which allow apps to access the device's sensors, for example a gyroscope to measure direction, altimeter, accelerometer, compass, camera, and microphone. The OS also allows apps to assess the location of the device through a combination of GPS, wifi and phone mast triangulation. They also create the way in to the device's other apps, and the user's self-created data, for example their calendars, contacts and messages.

As soon as any of this data is linked back to the user directly, e.g. by name or email, or even indirectly, e.g. through the phone's unique device ID, all of this data is "personal data", and is regulated by the DPA.

The organisation that commissions and then uses the app in its business (in the sense of making it available to end users), has the responsibility to comply with the DPA. Technically, they control the purposes for which and manner in which personal data is being used, making them what is known as the "data controller".

For this reason, it is important that organisations appointing developers to create and then run apps for them have a good written contract to regulate how this happens and make sure it is done in a compliant fashion. If the developer makes a privacy mistake, their client will feel the consequences. Having a written contract is also a compliance requirement under the DPA itself!

2. The "new cookies laws" are badly nicknamed. They apply to apps.

This point is the main reason we mentioned the Privacy Regs above.

Quite rightly, the UK has fixated on the cookies / web tracking implications of the Privacy Regs and the requirement to obtain consent where these are being used, hence the nickname "new cookies laws".

If you read these Regs though, you will not find any reference to cookies or even tracking technologies in them. Instead, they refer to a user's consent being required before "information" is placed on a device or accessed from a device.

In this context, "information" means just that: any information of any kind, so if you develop an app to access information on a smartphone or tablet, however generated, you need the user's prior consent for the app to do so. Similarly, if your app needs to place information onto a device, you also need prior consent to that happening: there are no exceptions.

(This consent requirement is completely separate from the more widely known requirements for consent under the DPA.)

3. "Consent" = An "agree" button

The A29WP don't treat apps in the same way the ICO have treated cookies. Implied consent is all the rage in cookie-world, hence the plethora of cookie banner notices which disappear once you keep using a site. For apps, the A29WP see the "agree" button as king.

This approach is in keeping with the general appstore and mobile OS led approach, e.g. Apple's iOS 6 privacy and location service settings features - and arguably a growing trend in apps themselves. In that sense it is not out of step with "market practice", the age-old excuse many digital developers use to argue against including obvious privacy features in any digital medium.

It is not without its critics though. One of the classic arguments is that simply downloading the app from an appstore is consent enough. This is nonsense in the view of the A29WP, and we would be inclined to agree.

The logic behind this position is fairly straightforward. Someone might like the sound of an app, and love its service, but that is not the same as saying they understand the privacy implications of downloading it and using it. Some users might run a mile if they have the full position explained to them.

So in the A29WP's view, there should be no short-cuts, no glossing-over of the issues. You have to explain your app's information implications, and get a clear indication of consent to them.

4. "Consent" = A "don't agree" button too?

In the A29WP's view, you also have to deal with the unpaletable truth that someone might not give consent, and this means including a "Don't agree" button as well.

Again, this is arguably in line with the way OS are headed, e.g. it is pretty standard in iOS 6, but we can see many developers wanting to draw a line at this point. (We'll duck this thorny issue and leave you to make your own decision on its merits)

We should highlight one key point though. Under the current DPA and present Privacy Regs, you might be able to get away without a "Don't agree" button without too many adverse consequences. Under the draft EU General Data Protection Regulation as it presently stands this may not be so easy. Through this Regulation, the EU are proposing to introduce one of their favourite concepts - imbalance between the parties - into the issue of consent.

The "imbalance" concept runs like this: if you build a massively sought-after offering but then wrap it up with a Hobson's choice on privacy, i.e. an individual can "agree" and use your wildly popular service, "don't agree" and they can't, the "consent" you are obtaining is worthless. In the EU's eyes, unless the data you are using is absolutely inherant to the service, where you have such an offering you should always be able to accomodate dissenters, and turn off the aspects they don't like.

The good news is that the draft Regulations are not expected to become law before 2016, and might be amended in this area before they are passed. 2016 is a long way off in app-world given the app industry itself is not yet a decade old.

5. Be clear about everything for which you (or third parties) need to obtain consent

To illustrate, it is probably worth going full circle back to present practice. You might have an app which delivers a service based on certain core personal data - say someone's contacts. This core data is in effect one data set, for which one consent is required. If a user doesn't like it, they can't use the app.

There is then the possibility of other data sets, which might be used for other, non-core purposes, or more problematic still, purposes which cross over with your core service data, or which are set by third parties. Classic examples of this non-core data is usage and tracking technology embedded in the app, and in-app advertising.

Whether or not consent is required in such circumstances needs to be considered carefully in each case; going back to a point we made above, it all hinges on whether information is being accessed or placed on a user device.

6. You can't ignore the need for a privacy policy

Privacy policies abound all over the internet, and increasingly in the real world too. Yet apps and appstores are all too frequently devoid of them.

For anyone familar with the basics of the DPA this is obviously non-compliant. The first principle of the DPA includes the requirement to provide up front information to all users of a service, explaining the privacy implications to them. This requirement is echoed in the Privacy Regs regarding the accessing and placing of information on mobile devices.

It is also inherant in the concept of "consent". To be effective, consent has to be prior, specific and informed, otherwise a person does not really know what they are consenting to, and the act of pushing that "agree" button is pretty much worthless.

As a result, it is not enough just to put an agree button into an app with little or no context. At the very least some titbits of information need providing with the button itself, and a link to your full privacy policy should be there too. Only that way is consent properly "informed" (see our next point why this is still not necessarily "specific").

This need for an app privacy policy poses challenges. Firstly, the technologies for apps are very different to the web, so the chances are you cannot simply recycle what you have on your website (a common shortcut a lot of organisations would ideally go with). Secondly, the smartphone screen is not large and delivering large amounts of what could be dry legal information can be an offputting user experience. We'd suggest getting your designers in, and your copyrighters, with the aim of bringing it alive; then your user experience app-wide will be great, you'll be compliant, and you'll have probably acheived best practice in making your policy very accessible and readily understood by comparison to traditional legalese.

Finally, you need to think about when to present your privacy policy. For organisations that adopt them, the privacy policy is normally linked to from inside the app. This approach largely reduces the privacy policy to a reference point though, to be read after download and usage (if at all). A better approach is to embed it when seeking consents, especially on initial download and set-up of the app. The A29WP also recommend you upload it to the appstore where this functionality is available, so your prospective users can read it ahead of choosing your app, if they want to.

7. Consider using very specific consent buttons

Unfortunately, an "agree" button referencing a privacy policy does not necessarily equal "consent".

As touched upon above, to be effective, in practice consent should be specific i.e. someone knows exactly what they are consenting to.

Unless cleverly designed so that each individual issue is called out very clearly, and written very precisely, even if a user opens your privacy policy up, chances are they may not appreciate all the issues set out.

The A29WP are therefore of the view that one agree button linked to a privacy policy does not really do the job. The way to go is to have a separate button for each major issue, e.g. you might have one or even of series of buttons to access the core data your app uses as part of its service on initial set up, a second one when (for example) the app first wants to access a user's location, and so on.

The A29WP refer to this approach as "granular consent", and are of the view it should apply to:

  • Location data
  • Contacts
  • Identity details, whether the users name, email address etc but also use of device ID numbers
  • Card and payment data
  • Access to phone call information, SMS, emails
  • Browsing history
  • Social network credentials
  • Biometrics

This approach is in line with the way some apps and OS are already going, however, we would not expect it to go down well with marketing teams and user experience professionals.

Thinking in such terms is a useful litmus test though. If you go through the process of thinking how many agree buttons you would need to comply with the A29WP position, but then consider that this looks horrendous to a user, this should be telling you something about the privacy implications of your app. (You should also remember that in broad terms, proportionality is also a requirement of the DPA. If the data you are collecting feels disproportionate, you may be breaching the DPA.)

8. Don't scrimp on security

The A29WP refer to lots of different security measures as examples of best practice. Not all of them are worth repeating here.

One of the key ones we are often asked about is encryption, and yes data should be encrypted in flight and at rest, on a risk-assessed basis.

The A29WP also recommend:

  • sandboxing (but this is already a requirement for Apple iOS and Android apps).
  • using temporary device identifiers not permanent ones, e.g IMEI
  • encrypting user passwords, and encouraging their strength
  • re-authentication for accessing sensitive data or paid-for services
  • using SMS or email for re-authentication checks.

The key point though is to use good security techniques, including the common practices we all see and are used to in information technology generally. Apps do not receive any special treatment from the law.

9. Don't forget about the bigger DPA picture!

From a legal point of view, the DPA goes much further than the points set out above, so it is important not to focus on narrow app interface issues as we have done here, to the exclusion of the full picture. For example, you'll need to respect subject access requests about app-derived data you hold server-side; this may create some unique issues for you. You'll also need to delete or properly anonymise app-derived data once you no longer actually need it for the purposes set out in your privacy policy (something many organisations struggle with in our experience).

From a commercial point of view, it is also particularly important not to forget the other side of app interactions. If your app drives customer behaviours, e.g. to purchase particular goods at a discount through an evoucher with embedded QR or bar code, any data captured from that behaviour through your other systems, and linked back to the voucher or related app, or other identifiers you hold is also personal data regulated by the DPA. Your compliance actions need to take account of this bigger picture, not just the app itself.

10. The wider world

As a final point, It's worth noting that the A29WP have actually been a bit slow in coming to the app privacy law party.

The Dutch and Canadian data protection authorities have already turned their mind to real-world app privacy issues in investigating WhatsApp, one of the top 5 global apps. Their investigation is particularly useful regarding some of the practical aspects of app security.

In the last month, the US Federal Trade Commission also joined in, publishing a guide for app developers and platforms. This guide follows-up their earlier investigation into Path, a social app, which resulted in an $800,000 fine.

Needless to say the Californians - who after all invented the app world in which we now live - have also issued legal guidance on this subject

Obviously, only the A29WP guidance and Dutch authorities' approach is of real assistance to UK organisations. The market for apps is an increasingly global one though. For organisations who want to play globally, all of the above (and potentially more guidance besides) is relevant.

This maze is not easy to navigate. As should be clear from our top tips, the only way to navigate it even vaguely well is through proper planning and upfront consideration at the design stage ("privacy by design" as the EU like to call it). That is a topic for another day though.

This information is intended as a general discussion surrounding the topics covered and is for guidance purposes only. It does not constitute legal advice and should not be regarded as a substitute for taking legal advice. DWF is not responsible for any activity undertaken based on this information.