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: https://www.privacybydesign.ca/content/uploads/2009/08/7foundationalprinciples.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:

1. Volunteered personal data
2. 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.