Courtesy cliparts.io

Pokémon Go and Location Privacy

There is one species Pokémon that even the most dedicated of Pokémon Go players are unlikely to ever catch, and that of course makes it all the desirable.

Privachu like to be left alone to go about their lives. They are not unfriendly and can be quite gregarious. They are also not as rare as one might think given how difficult they are to get hold of. What makes Privachu different from all other Pokémon, is that they choose when and how to reveal themselves, rather than just broadcast their location to anyone that might want to find them. And of course they will only reveal themselves to others they trust not to pass the information on to people they do not want to be found by.

OK, they don’t exist really, I’ve just made them up (though if anyone from Niantic wants to create Privachu, I am willing to be reasonable on the royalties – do get in touch).

Pokémon Go, the augmented reality mobile location based game, is currently taking the world by storm, but has been the source of some significant concern around the amount of personal data collected by the app, and how this may be shared. This is especially important because it is played largely by children.

Much of the early privacy concern focussed around the fact that users appeared to be required to give Niantic, the company behind the game, full access to their Google account (one of the main ways of registering in the game), which would include all their contacts and any documents stored in Google Docs.

However, it was fairly quickly revealed that this was actually the result of a configuration error, which was rapidly corrected, and that Niantic did not make use of or tried to access any of the extra information it didn’t need to verify the identity of the player. Nevertheless, even this short lived issue might have impacted millions of people and should provide a summary lesson in putting privacy thinking at the heart of the user experience design process.

The long term privacy issues with Pokémon Go however clearly focus on the location issue. Of course location based digital services have been around for at least as long as the smartphone itself. Aside from the obvious ubiquity of connectivity, location driven services are the smartphones killer app, the one that makes it worth all the investment in many ways.

What is perhaps different about Pokémon Go, is that it is not simply collecting location data – but it is actively incentivising large numbers of people to visit particular locations where Pokémon can be caught.

Yes there are big questions around the privacy concerns of sharing (selling) of location information with third parties, and those questions are already giving rise to investigations, notably in the USA and Germany.

What I think is more interesting is – how are decisions made about where to place PokéStops, and what Pokémon are to be found there? There is a huge potential here for a kind of targeted manipulation, the encouragement of particular audiences and profiles to visit specific locations. Niantic would be crazy if they didn’t see the potential in selling this capability, and I would be very surprised if on some level they are not already either doing it or thinking about doing it. There will be a powerful profit motive for it. Want to drive more visitors to your location? Pay for a particular Pokémon to make an appearance, or your competitor will.

Then of course there are also the unintended applications of the data. There have already been stories of crimes, even a murder, linked to the location data elements of the game. How long before the first major hack is uncovered?

Pokémon Go is going to be an interesting privacy story for quite some time I think. Not simply because of its huge popularity, though in no small part because of that, but the use of location data is only going to grow over the coming years, and the issues are only going to get more complex. The popularity of Pokemon Go and the huge data it generates, will almost certainly make it a pioneering proving ground for both the problems, and hopefully the solutions.

Meanwhile, if you’d like to know where to find Privachu, you will have to wait for them to reach out, when they have learnt to trust you.

General Data Protection Regulation Top Ten Issues

The ink is barely dry on the draft, but the  EU General Data Protection Regulation (GDPR) looks set to change the regulatory environment for personal information not just in the EU, but around the world. Its aim is to create a legal infrastructure for the use of personal data that is fit for purpose, both today and in the future.

The GDPR was designed to increase legal certainty with regards to information flows both within the EU’s borders and beyond. It also introduces stronger consumer protections, with requirements for greater transparency and accountability about how data is used by businesses, not-for-profits and governments alike.

This is intended to give individuals increased trust in data practices.  Consumer research in the last few years has shown consistently high levels of concern and lack of trust in this area, and this is believed to be a potential brake on the future growth of digital technologies.

However, in order to achieve these goals the GDPR does come with some stings in its tail. It places much greater requirements on businesses to communicate effectively with customers, and obtain much clearer consent for the use of their data.  Organisations also have to provide customer choice mechanisms, and there is a greater emphasis on documenting data processing activity. And then of course there are the fines.

At over 200 pages it is a very wide ranging instrument.  However, for those who haven’t had time to read it yet, these are what we think the top 10 issues for most organisations will be.

1.  A broader definition of Personal Data

As we predicted earlier, the scope of what constitutes ‘personal data’ has explicitly been broadened to include any information ‘relating to’ an individual. This specifically includes ‘online identifiers’ so cookies and the advertising IDs seen in the mobile eco-system will be caught up, along with anything that contributes to identifying an individual, or links to such identifying information. This has some widespread implications for online tracking in particular.

2.  A higher bar for consent

Whilst the final text shied away from explicit consent as a requirement, except when special categories of (sensitive) data are concerned, there is still much emphasis on gaining consent through active user mechanisms like tick boxes.

A key part of the test of the validity of consent is whether consumers understand what they are agreeing to, and are given a meaningful choice. There is also a significant shift in the burden of proof.  You will need to be able to provide evidence that you obtained consent from specific data subjects, which is going to require much better record keeping for many organisations.

3.  Data Protection Officers

Although not a universal requirement, many organisations will be required to appoint a Data Protection Officer (DPO) to oversee data uses and ensure compliance with the law. They will be mandatory in the public sector, but for private sector organisations the key test will be whether the organisation is involved in “systematic monitoring of data subjects on a large scale“, however it is not clear at this time how ‘large scale’ will be interpreted.

Earlier, more detailed, requirements for the skills and experience of the DPO and guarantees over their employment, have been dropped but a key issue in the short to medium term will be a lack of the right people to fill such roles.

DPOs however can be outsourced, which may create a market for new services, especially to cater for the needs of smaller businesses.  The DPO responsibilities can also be given to someone alongside other work within the organisation, as long as this does not create a conflict of interest.  So training existing staff into the role could be a viable option for many.

4.  Transparency and Accountability

The GDPR scraps the need for controllers to register with their Data Protection Authority (DPA), but replaces this with a requirement to both better inform data subjects about practices and rights, and to keep records that can be made available on request – such as in the event of a data breach or a compliance complaint.  Such records are about demonstrating that the organisation has thought through the impact of its systems and processes, and made informed choices about how to comply with the GDPR.  The Data Protection or Privacy Impact Assessment (PIA) is one example of such documentation.  It is intended that a PIA will show that an organisation has considered the risks associated with its particular personal data practices, and taken reasonable steps to control or mitigate them.

There are also new requirements on the level of detail that organisations must provide to data subjects about their practices, as well as a need to make sure that this information is both accessible and easy to understand. In particular there is a need to explain the logic behind decisions made on the basis of analysing personal data – which may have particular significance in some sectors that have relied on such processes being largely secret. Organisations are also expected to inform subjects about their rights and how to exercise them.

5.  Data Protection by Design and Default

Although references to this have been cut back in comparison with earlier versions of the text, the GDPR contains requirements that the design of systems and processes are required to give consideration to compliance with the principles of data protection. Particular emphasis is placed on the ideas of only collecting data necessary to fulfil specific purposes, discarding it when it is no longer required, and protecting data subject rights.

It also sets up the possibility for the development of certifications and codes of practice that organisations can follow to help meet these requirements.  Keep an eye for these as they develop.  In particular we expect DPAs to get involved in this area.  They will be losing their registration fees and therefore needing new sources of income.  In the UK the Information Commissioners Office (ICO) has already been developing this idea, so expect it to continue. Trade bodies are also likely to have a role to play here.

6.  The Right to Erasure and Data Portability

These new data subject rights are likely to pose challenges for many organisations. The right to erasure is a clarification of the much talked about ‘right to be forgotten’.   Although the circumstances when the right can be exercised have been made clearer, the balancing against other rights and obligations is still needed.

The right to have a copy of your data in a machine readable form to transfer to another provider may be difficult at first, but it could also lead to better systems interoperability in the longer term – which is already a growing technology trend.  In particular this provision may facilitate the development of the market for ‘personal data stores’, an idea that has long been talked about, but not yet fully realised as providers have struggled with sustainable and scalable business models.

7.  Removal of Subject Access Request Fees

Data subjects have a right to know whether or not an organisation is processing their personal data, what that data is and the purposes of the processing.  The GDPR removes the ability to charge an upfront fee for providing such information, and there is a risk requests will increase as a result of this, pushing up costs.  Current allowable fees don’t exactly cover the cost of  a Subject Access Request (SAR), but are seen as a deterrent to time wasters.  If companies are no longer able to charge fees, it is feared this could open the floodgates to many more SARs.

Companies will be allowed to charge for subsequent copies of the same data, which may reduce the risk of this to some extent. However, it may be worth investing in making sure you can respond to such requests as efficiently as possible, which will not be easy in many cases.

8.  Reporting Data Breaches

Data controllers will be required to report data breaches to their DPA, unless it is unlikely to represent a risk to the rights and freedoms of the individuals concerned. However this qualification may be difficult to judge, so in many cases, it will be safer to notify. The notice must be made within 72 hours of becoming aware of it, unless there are exceptional circumstances, which will have to be justified.

Where the risks to individuals is high, then the data subjects themselves will also need to be notified, although a specific time scale is not specified for this.  It is also worth noting that the DPA can instruct an organisation to inform data subjects if they haven’t already, so we can expect to see further guidance on the circumstances when it would be correct to do so.

9.  Fines

The GDPR very deliberately raises the bar in terms of the ability for DPAs to issue fines for breaches of the rules.  They can go as high as 4% of global turnover.  Not only are these designed to ensure data protection becomes a board level issue, by taking into account worldwide revenues, they seek to side step attempts by multinationals to engage in fine-avoidance business structures.

It is also worth noting that fines can be levied without the necessity to demonstrate harm – although the largest ones will likely be reserved for cases where data subjects have directly suffered damages.

10.  Data Processor Responsibilities

Organisations that only process data on instructions from their client are not directly covered by the current data protection regime.  Their actions were assumed to be governed by agreement with the customer who would be the data controller, and therefore directly responsible for the actions of the processor. However this all changes under the GDPR, and processors now have direct legal obligations and responsibilities.

In particular this means that processors can in certain circumstances be held directly liable and be required to pay compensation to a data subject. It will therefore become very important to establish the contractual relationships and liabilities of the different parties in a controller/processor relationship, and the costs of some services by processors may rise to offset additional risks and insurance costs.

 

We hope you find this useful.  In future posts we will look at more details of what you can do to prepare, as well as looking into each of these areas in more detail.

In the mean time, if you have any questions and would like to know more about how the GDPR might effect your business, do get in touch and we will be happy to help.

Building Websites on Privacy by Design Principles

One of the many significant changes being introduced by the European General Data Protection Regulation (GDPR) is the requirement to adopt principles of privacy by design (PbD) when creating or revising processes or technology.

Given that websites are regularly being re-designed and developed, often by out-sourced agencies, it is quite likely that when the requirements become law, web development projects will be the biggest, most immediate category of impacted software development activities.

Websites are also often the first and only point of contact between an organisation and its prospects and customers, who are also usually the most numerous category of data subject.  The website therefore sets the tone for the brand and its attitude to privacy principles.

With this in mind, it is rapidly going to become important to have an understanding of what this will mean for web design. This article provides a brief overview of the issues the businesses and web designers will need to think about.

Overview of PbD

Much more than an empty phrase buried in a long legal document, Privacy by Design (PbD) was a concept started by respected Canadian privacy regulator Ann Cavoukian back in the 1990s.  It provides a framework set of seven principles to guide development of new systems and processes handling personal information.

In brief, following these principles means building privacy into the design of a system as the default setting, ensuring personal data is kept secure and destroyed when it is no longer needed, providing users with transparency and meaningful choice with respect to the use of their data, and avoiding unnecessary trade-offs between privacy and other interests.

More detail is available here (PDF).

Looking at these principles, it is easy to see that the vast majority of websites would fail even the most lenient test of their application. More than that, when presented recently with a requirement for a partial implementation of these principles, pushed on to them through the law, many website owners exhibited a strong resistance to the principles.

I am of course talking about the ePrivacy Directive, aka cookie law.  The requirement for consent for the use of cookies embodies the PbD principles of privacy by default, transparency and meaningful choice.

More than 4 years after first coming into effect, although more and more responsible companies are moving in the direction of greater privacy choices, the law is given little more than lip service by millions of other sites.

More than that it is frequently derided by web professionals, many of whom have as little understanding of the law, as they accuse law makers having of technology.

The Impact on Website Design

A privacy by design approach to web design and development needs to take into account the two broad modes by which visitor privacy is impacted:

  • Volunteered personal data
  • Automated personal data collection

The volunteered data part is relatively easy, and many websites tackle this reasonably well, although there are a few things to look out for.  It is the automated bit that presents more challenges.  We will however look at both.

Volunteered Data

The most obvious source of volunteered data is when visitors submit their information through web forms.  Though on the surface this is a straight forward case of getting consent through a privacy policy and checkbox, there are a few things to consider:

The site must be clear about all the potential uses for the data, not just the uses the subject expects or is providing their details for.  Where any of those uses might be additional to the core reason the ‘privacy as the default’ principle would require data the subject opt-in to those additional uses, and not just to all future uses, but each specific use.

Even where opt-in consent has been obtained, there would also need to be an easily accessible option/control mechanism to opt out again at any time.

What happens to the submitted form data is another crucial design issue.  Is it emailed, sent to a CRM, stored in the website database? It is common for all three to happen, resulting in multiple copies of the data.  But if you are sending the data to another system – leaving it in the web database is an unnecessary security vulnerability, which many sites are exposed to. If you are not using the data operationally in your site (such as for logging in), clear down the data submitted through forms on a regular basis.

Not all volunteered data is captured directly through web forms however.  Can people set a language preference on your site? Do any interactions result in content being personalised? This could be considered volunteered personal data.  How are people notified about this? How is the information saved, for how long?  These are all valid PbD considerations.

Automatically Collected Data

This is generally the largest volume of data generated from your website.  Much of it happens through the use of cookies and other mechanisms which are set and read by the various applications your website uses.

In Europe there are specific rules around visitor consent and the use of cookies.  We will not go into the detail of those requirements here except to point out that by applying privacy by design thinking to the use of cookies, you will likely also to be largely compliant with the cookie rules.

Of course not all cookies contain or can be considered as personal data.  However the extended scope of the definition of personal data under the GDPR means that many types of cookies will likely fall directly and clearly in scope of the new rules.

In particular, cookies that act as unique device or user identifiers – such as those used for online tracking and user login, are likely to be considered as personal data under the EU GDPR.

This will therefore mean a need to evaluate all elements of your website that set cookies, identify whether these carry personal data.  The next stage would be to consider whether privacy-friendly alternatives exist, or if not, how to implement user controls.

This has particular implications for technologies that set third party cookies.  In particular it would no longer be possible to make the argument that ‘we are not responsible for third party cookies’. PbD requires site owners to shift the focus from cookies per se to decision to use the underlying technology. No website owner can realistically say ‘we are not responsible for the technology we add to our website’

A PbD approach to site design therefore requires that every bit of the technology infrastructure of a site will need to be evaluated for its impact on privacy, and require the provision of suitable default settings, notice and control.

PbD principles would suggest that you can’t just add a standard Facebook Like button to your pages by default. You would need to ask users to opt-in to such features, whilst also making sure that they are aware of the privacy implications of doing so.

This also holds true for a vast array of technologies and services that are provided by third parties as scripts and code embedded into pages.  Analytics, videos, music, discussion forums, and of course advertising – all of these page elements are typically served up from separate host domains that are more or less invisible to the average visitor.

All of the most common examples of these services involve some level of personal data collection. A requirement to follow PbD principles means giving consideration to the impact of these throughout the process of development.  This is no easy task as many technologies designed to be integrated into other sites, are not clear about their data collection practices.

The Impact on the User Interface

PbD requires a thorough examination of the architecture of a website and its privacy impacts. It also requires mechanisms for visitors to be able to make realistic privacy choices.

This of course means that there is a need for interfaces to support such choices.  And this may be one of the greatest challenges for web design.

The kind of notices that we have seen arising from attempts to comply with the cookie law will not readily suffice – they are neither granular enough nor present enough choice.  What will be needed is more dynamic interfaces, showing and hiding content and functionality based on choices made.

Such interfaces are not uncommon – the best web design already configures content and services around users, this is what ‘personalisation’ is. However, interface personalisation is generally not clear to the user, especially when and why it occurs.  Privacy by Design means not only making the fact of personalisation explicit, but providing explicit choices to visitors about whether or not it should take place.

Allied to this designers will also have to take into account whether or not they want to give access to content and services to people who make privacy choices that go against the economics of the services being provided.

So if a visitor comes to a free news site, which is paid for by privacy invasive advertising, yet chooses not to have the advertising, designers will have to decide if they should not be given access to the content.

Conclusions

The aim of this article has been to raise just a few of the issues that are going to face the web design profession once the new European data protection rules are finalised.

Clearly of course these are not just decisions for ‘designers’ in the traditional sense – they are also examples of some fundamental questions for digital strategy.

The new law will mean there will be no getting away from questions like these when it comes to a new web build.  So the time is also fast approaching when some answers will be needed.