Making the case for "Privacy-Aware Design"

On January 28, Data Privacy Day encouraged everyone to make protecting privacy and data a greater priority; a good trigger to start a long-planned series on some things I have been working on over the last year.

With “Privacy-Aware Design”, I aim to create a discussion around privacy as encountered by interaction designers on the UI/UX level.

I consider it important to acknowledge that the protection of users’ information is not just rooted in the service concept (data collection, sharing, visibility) or purely an engineering challenge in the background (encryption, access control, data storage in general), but that privacy is also deeply affected by design decisions on the user-facing interfaces of internet services.

The hamburger sandwich of website privacy

For illustration purposes, I sometimes use the metaphor of a hamburger sandwich to describe the levels at which privacy is ensured (or put at risk) in an online service:

It provides three levels to be looked at: the two halves of the bun that are holding the sandwich together, representing the conceptual and engineering aspects of an internet service, and the patty in between, standing for the user interface and user experience - including its easily overseen privacy traps on the interface level.

I. The concept

First up, looking at the upper half of the bun, there is a variety of conceptual aspects in regard to privacy. A lot of the public discussion on privacy in and around social network services or websites hovers around this level, for instance:

• What information does a service collect from its users?
• What are the terms and conditions the service provider applies to user-owned information?
• Does the user have control to restrict the visibility of their personal information and content?
• Is the user always aware of whom they are sharing information with?
• How is information from different sources compiled into one profile?
• Is it possible for the user to completely erase all stored data?

II. The backend

The bun’s lower half, to stay with the metaphor, covers a lot of the big technical questions behind the creation of an online offering - the core digital infrastructure a site or service is built upon and covers questions such as:

• How and where is the information stored?
• What are the encryption methods used for data storage?
• Is the transfer of data between the user and the backend protected? (see my earlier writing on why HTTPS should be considered a compulsory feature of any SNS design)

III. The interface level

Yet, in between these backbones of internet service concept and data management, there is a whole other layer where user privacy is affected by how things are designed and built at the interface where the user interacts with a service. While there is general awareness for most of them, frequently discussed as isolated issues, there is a need to see them as an entity.

Many of the issues from this “hamburger patty” of the privacy burger are typically discussed from the perspective of how concerned individuals can protect themselves by privacy-proofing their browser (e.g. “You don’t want to be tracked? Disable tracking in your browser!”).

However, they all are ultimately issues created through the design of contemporary websites, which should make them a topic for a design-focussed debate.

From self-contained web pages to patchwork quilts of third party elements

Still 10 years ago, the browser of a user visiting a website would generally load all its content and required software from the site’s server. With all files being loaded from the same place, only its provider would have the ability to track a user.

Since then, a lot has happened. The use of standardized elements (e.g. JavaScript libraries) and their centralized storage has become commonplace and a variety of services provide otherwise expensive functionalities for free or at marginal fees (from content hosting to social features).

In summary, this means that both visible (videos, images, functionalities) and invisible (scripts, fonts) elements are loaded from third-party servers; in addition, usage statistics are often tracked by an external system as well.

This approach has many benefits, which is the main reason for their wide adaptation:

• For the provider, there are significant savings as parts of the service can be ran on external infrastructure and without the need to develop and deploy complex solutions for common tasks (e.g. not having to establish a video streaming server and using YouTube embeds instead; small websites would not even be able to offer such content otherwise).
• For the end user, the centralized infrastructure often provides faster load times (as much of the external code might be shared with other websites and therefore held in the local browser cache) and smooth integration with major services many people use (like SNSs, media services etc.).

The outsourcing of website parts and functionalities leads to the situation that the third-party provider is able to track who is using a website that makes use of their embedded services. The easiest of examples: whenever a user opens a website with an embedded YouTube video, Google (as the owner of YouTube) can collect information about the computer accessing a website otherwise completely unrelated to Google.

This already manifests a privacy problem as is (on a side note, Google also gains insight about the website itself: how often is it being accessed, from where etc. - therefore creating also a “privacy” issue of sort for the website owner). Yet, it grows into an even bigger issue once such third party service providers have their product embedded in a critical amount of websites and - in the worst case scenario - even have major parts of the web’s user base registered with them.

With a reasonable market share or, even more so, with having a large number of subscribers who have identified themselves to the provider, the embedding of content or code into other websites turns into a giant data collection engine. Maybe the most successful instance is Facebook, who managed to get their “Like” buttons etc. embedded into such a huge share of websites that they both have good insight into any website’s user numbers and into their own users’ browsing behaviour, even when they are not logged in.

Feeding the hungry data leeches vs. providing privacy to users

Since this debate is about the user interface, it is obviously closely connected to user experience: fast loading times of script libraries and fonts provide for a fast and responsive website, the ability to watch linked videos within a website helps to avoid opening up ever new browser tabs, the instant availability of sharing buttons is good customer service; analytics help to understand the users better and improve the service.

And naturally, there are strategic interests involved as well: hosting code libraries and content elsewhere helps to keep costs down, embedding content instead of linking to it keeps the users on the site and the more sharing buttons are provided the higher the likelihood that some users are going to click on them; analytics provide valuable insight for the service development.

The issues presented above may easily lead to the belief that the most radical cure - hosting everything “in house”, replacing embedded content with links, removing social media features and stopping to use professional analytics - would be the best solution. But apart from indeed eliminating the privacy issues, this would be several steps backwards into a web from ancient times.

Luckily, there are smarter ways. There are plenty of concepts, ideas and even turnkey solutions to design user interfaces that preserve the majority of the conveniences of a decentralized design strategy while reducing the amount of data third-party infrastructure giants are allowed to collect about website users.

Coming up: an in-depth look at the issues

Following this introduction, I am going to investigate the issues of the “hamburger patty” in a series of posts over the upcoming weeks. In my investigations, I present the issues at hand, show approaches to overcome them and discuss the implications for the “Privacy-Aware Design” of websites in regards to:

• website analytics (published 2014-02-28, see Privacy-Aware Design: Replacing Google Analytics with a decentralized solution),
• social media integration (published 2014-03-13, see Privacy-Aware Design: Opt-in alternatives for social media sharing),
• externally hosted scripts and fonts,
• the embedding of third-party content, and
• the leakage of private information in media files.

As a disclaimer, it also needs to be highlighted that, while the intention of this work is to provide constructive starting points for more privacy awareness, it is obvious that the issues are deeply interwoven with the internet industry in general and there is no easy one-size-fits-all way out, particularly beyond small-sized web presences (for which I will try to demonstrate that most of the challenges can already be solved today).

All of this is work in progress for research purposes, any commentary is highly encouraged and you may subscribe here if you want to follow the upcoming posts on Privacy-Aware Design.