Personal Data, Social Media and Privacy by Design
Some time ago, we published a detailed article on the significance of the General Data Protection Regulation (GDPR) in our blog. In this article, we will also look at how the changes in data protection affect the development of software. In particular, how developers can build data protection into their products from the very beginning.
For this, we refer to two very helpful articles by Heather Burns in Smashing Magazine, which we briefly summarise here:
https://www.smashingmagazine.com/2018/02/gdpr-for-web-developers/
https://www.smashingmagazine.com/2017/07/privacy-by-design-framework/
The goal of privacy is to put personal data under the control of the individual. Besides the obvious personal data, there are particularly sensitive data such as ethnicity, political and religious attitudes, health data, genetic and biometric characteristics, sexual orientation data, location information, pseudonymised data and, of particular interest in software development, online IDs: IP addresses, usernames, cookies, MAC addresses...
To develop software in a privacy-friendly way, Heather Burns refers to the Privacy by Design framework, which was developed in Canada in the 1990s. Privacy by Design suggests seven basic principles to software developers that make it easier to develop products that comply with the GDPR. These include, for example, that data protection should have a positive impact and the desire for it should not make software unusable, for example by making a social media account mandatory in order to use a service. Another principle is to set data-protecting settings as default and not to assume that the user of a software agrees to share data.
Supporting privacy by design means for developers to have privacy in mind at all stages of development, including and especially after an application is no longer used by a particular person or the application itself is no longer available.
Furthermore, Heather Burns addresses the need for a stronger focus on documentation of privacy measures, as this can be demanded in the event of a dispute. A helpful document here is the Privacy Impact Assessment (PIA), which can be designed as a living document and should be made available to all project stakeholders. Among other things, it contains information on the areas of data collection and storage, security measures, personnel, access rights of the owner of data, legal and threat potential.
To meet the above requirements, Heather Burns recommends introducing coding standards that implement the basic principles of data protection. This should include ensuring that insecure or unnecessary modules in APIs and libraries are not used in the first place.
An important feature of the GDPR is to return control over personal data to the individual – this must be reflected in the design of applications that collect and process personal data – the aim of the regulation is not to prohibit collection and processing – for example, through granular ways to control the collection of individual data points.
Last but not least, it should be noted that violations of the GDPR can result in quite severe penalties; therefore, care should be taken to implement the regulation correctly – as far as possible – from the beginning. Incidentally, the GDPR applies at the place of market, which means that providers who are not domiciled in Europe are also subject to the regulation if they do business in its area of application.