“Every organization, no matter of its size or level of maturity should think about Privacy as soon as possible”, smiles Ian Oliver, Senior security researcher at Nokia Bell Labs and opening speaker of the Privacy Engineering conference. Like the author of Privacy Engineering – A Data Flow and Ontological Approach, almost all of 14 speakers who expressed their view during this one day track hosted by apidays Paris on December 9th, agreed on that point: Privacy matters should be taken as seriously as security concerns and integrated in the product design.

@youtube
Ian Oliver, one of the first to call himself a ‘Privacy Engineer’ on the state of the art of Privacy Engineering

Think Privacy “by design”

Thinking “Privacy by design” since the beginning is the path chosen by Dashlane, a password and data manager. Following the philosophy of the zero-knowledge architecture, “even employees of the company can’t access or decrypt the data” stored by the users in the IT systems, guarantees the CEO Frédéric Rivain. “Implementation is more complex but it helps protect privacy, protect systems against attacks and reduces the risk of data breaches. For a password manager, this kind of architecture is mandatory, but every product could benefit from thinking as we do,” he adds.

@youtube
Every developer and architect should get inspiration from password manager on their way to handle privacy

Especially since privacy should be implemented in all the products and services that a company provides. “Privacy or compliance is not only for the website or the cookie management…,” warns Romain Robert, qualified lawyer in IT law at the non-profit organization NOYB (Non Of Your Business) which filed 422 complaints against websites that, according to the association, implements dark patterns to force users to accept cookies. “A company must ensure compliance everywhere, including, for example, in the SDK they create,” the legal expert reveals.

@youtube
GDPR applies to all personal data no matter which kind of system process them, warns the qualified lawyer in IT law Romain Robert

Think Privacy by Design as soon as possible

Ian Oliver emphasizes the need to develop a new mindset in terms of privacy. “GDPR is not a matter of compliance, he argues. It is a risk management matter” Because data rarely are personal by themselves. They can become personal in some context and so could fall within the scope of a law or a regulation.

GDPR is not a matter of compliance. It is a risk management matter – Ian Oliver, Senior security researcher at Nokia Bell Labs

That’s why the engineer urges developers, architects and legal teams to work on privacy early in the development process. This early thinking makes it easier for a company to adapt its systems and be compliant to privacy regulations which appeared all over the world (CCPA in California, APPI in Japan, PIPEDA in Canada, PIPL in China…) this last few years: “Compliance is a horrible world we should get rid off because, if systems are engineered for privacy, we will never hear that term again”.

Every product could benefit from the Privacy by design principle – Frédéric Rivain, CEO Dashlane

But Privacy can also be implemented afterwards. For example, the software engineer and entrepreneur Gaël Duval is currently developing /e/OS, a fully deGoogled mobile operating system based on Android. “OS from Apple or Google send personal data to their servers, he says. At the /e/foundation we work on removing all trackers from Google services. When one of this service can’t work without this trackers, we replace it by an open source equivalent.” The project has already convinced 12 000 users and collected more than 100 000 euros on crowdfunding platforms, proof of the growing interest of users in privacy-friendly services.

@youtube
The software engineer and entrepreneur Gaël Duval answers the question: what does it mean to remove Google from Android?

Euphemism: Privacy is not easy to implement

During the Privacy Engineering conference, many speakers also remind the audience that implementing privacy is not an easy thing. And that is a euphemism. In the current state of existing tools, designing privacy compliant products is difficult, maintaining them is hard and testing them is a nightmare. It is so complex that, for example, “the vast majority” of the companies studied by Alias – CODE IS LAW in their “GDPR Data Portability: The Forgotten Right” report “didn’t respect this GDPR right”, François-Xavier Cao, CTO, CPO & co-founder of the start-up says.

@youtube
The co-founder of Alias, François-Xavier Cao, presents the conclusions of the ‘GDPR Data Portability: The Forgotten Right’ reports.

“One of the reasons for this failure is the lack of tools to help companies handle their privacy concerns,” the PhD candidate at University of Lille and specialist of European legal framework perspectives for APIs adds. An observation shared by Guillaume Montard, Founder and CEO of the Data security risk platform Bearer: “DPOs, for example, encounter difficulties during the data-mapping process. Some of them ask questions to the teams and report the answers in an Excel. It is long, not scalable, and it can’t follow the evolution of the systems.”

@youtube
Guillaume Montard, CEO of Bearer, explains how to handle data privacy in the era of cloud native app

In fact, “GDPR is the most quoted text in the Term of Services of APIs”, according to Monica Posada, senior researcher at the Joint Research Center of the European Commission, who studied more than 4000 API’s Term of Services. “I think it could be a relevant idea to conduct studies to verify that what is written in this Term of Services reflects reality,” she adds. Because quotations are only declarative, they are not necessarily correlated to the reality of the computer systems of companies. Companies that still struggle to achieve GDPR compliance.

@youtube
The researcher at the Joint Research Center of the European Commission Monica Posada presents the conclusion of a study on the Term of Services of more than 4000 APIs

Few and complex tools…

To help companies to respect laws and regulations, some tools are emerging. Catala-lang is one of them. This open source programming language aims at transforming laws into code. “Coding a law isn’t trivial, and the output of your code can have tremendous consequences”, ensures Denis Merigoux, Phd Student at INRIA, the French National Institute for Research in Digital Science and Technology and contributor on Catala-lang. The researcher, who talked about “Programming The Law: Best Practices” also worked with administrations to translate laws defining tax or salary amounts into running apps. He warns: “Bugs, misunderstanding of the texts or bad implementation can lead to real people left without money at the end of the month”.

@youtube
Learn the best practices to ‘code the law’ with Denis Merigoux, Phd Student at INRIA and contributor on Catala-lang

But solutions are emerging

The researcher also gave advices on how to code the law. “One significant thing is to implement the law in open-source projects, says Denis Merigoux. That way, peers can review the code and detect problems.”He continues:“The coder has to try to follow the structure of the law and make one line of code per line of legal text.”

Coding a law isn’t trivial: the output of your code can have tremendous consequences – Denis Merigoux – contributor on Catala-lang

“But one of the most important things is to be able to have a developer peer-coding with a lawyer, to ensure that the implementation is correct, explains Denis Merigoux. To achieve that, you need to use a high level programming language, which can be understood easily by someone with little technical background.

Why ? Because developers and DPOs don’t speak the same language. One will talk about « Personally identifiable information » (PII) use for a « purpose » in the context of a « legal basis » while the other talk of rows and columns in databases. A language clash that led Ian Oliver to « ban PII from tech and legal vocabulary » to create a new common language that fits both tech team and legal team needs.

Not all developers need to be GDPR specialists

Many participants of the Privacy Engineering Conference – such as the former CNIL Senior legal counsel and cybersecurity consultant Amal Marc, the CEO of The Neoshields and founder of the Union of Data Protection Officer Xavier Leclerc, and the Co-Founder and CEO of Leto.legal Benjamin Lan Sun Luk – also agreed on the importance of law and tech collaboration. But they also gave their view on how to enhance this cooperation. One approach under consideration concerns the raising of both DPOs and technical teams culture. Technology culture for the firsts to help them understand the complexity and the reality of the IT systems. And for the others, raising the law culture.

@youtube
To help developers in their quest for infos about GDPR, the CNIL has released a guide for them, presented here by Jérôme Gorin, technologist in the French institution

A statement qualified by the Privacy Architect of Veepee Manfred Touron: “not all developers need to be GDPR specialists but we need at least one tech expert in the company whose role is to be the translator between the technical and the legal, and someone assigned in each technical team to ensure that the topic will be addressed.”

@youtube
Our guest debates on the best ways to fill the gap between developers and DPOs

Or, in big groups, divide the privacy work between highly specialized teams. This is the choice that has been made by Meta (ex-Facebook). For example, one of their team works only on the “Deletion Framework”, which “provides deletion guarantees at the company levels”, the Privacy Engineer Manager at Meta Benoît Reitz says. His goal is to “reduce the product developer’s involvement to a minimum by building on top of a structured data type specification language” that takes into account the local regulations concerning which data can be safely deleted and which has to be kept for legal reason.

@youtube
Benoît Reitz, Privacy Engineer Manager, describes the data deletion framework used at Meta (ex-Facebook)

Lastly, most of the participants agreed on the fact that, as Amal Marc said, “compliance is not black or white.” There are “50 shades of GDPR compliance”, and the good one is the one that is adapted to the company situation. “People need to be careful because there is a real risk of over-engineering to achieve compliance,” Manfred Touron warns. To which Xavier Leclerc answered: “Don’t be more CNILesque than the CNIL itself.”

And we could add: don’t let law teams handle all the burden of privacy and compliance but involve technical teams in the process to create or implement privacy tools. That seems to be the only way to provide users privacy and compliant-first products. That seems to be the only way to be able to make privacy requirements evolving and scaling at the same pace. That seems to be the only way to make the (tech) world a privacier place.

ALIAS – CODE IS LAW aims to automate GDPR (General Data Protection Regulation) for applications developers. We are making GDPR implementation easy thanks to APIs , in order to help companies to be compliant and automate the portability of personal data.

Extraordinary complementary information:

• You can sign up to our Newsletter on Privacy news for techs and lawyers by giving us your email at the bottom of this page
• Stay tuned ! This article will be updated with the videos of the talks from the Privacy Engineer Conference very soon