Devtools for Data Privacy — Step 3: An Ontology

Cillian Kieran

7 min read · Oct 29, 2021

Introduction

Continuing on from previous pieces on a shared privacy taxonomy and privacy devtools, In this article, I posit that a shared privacy ontology is the final piece to the puzzle; it unlocks a world of privacy engineering power, including the following key benefits: eliminating the need for privacy code reviews, no more manual data mapping, evaluate risk quickly in CI, and ultimately, privacy practices as interfaces. Here’s how…

Taxonomies, Ontologies and Privacy

If you’re following our work at Ethyca you’ll know that over the past three years we’ve been working with design partners to build an ecosystem of developer tools for data privacy.

In a previous post I wrote about the need for a taxonomy as a basis for a community-agreed way to describe privacy in a tech stack, such that universal tools can be built to solve common problems of privacy. But a taxonomy is just the starting point. It’s the foundation of a comprehensive ontology that can allow any developer to easily describe privacy concepts and behaviors of the code they write and the data they process and store.

Let’s first clarify the difference — a taxonomy describes entities using hierarchical relationships. An ontology is more expressive: it can describe a variety of relationships between entities and their role in a complex system. Ontological grammar should easily declare those roles and relationships, such as “is-a”, “reports-to” and so on.

Why Solving this Problem Matters

If you’ve read my earlier post on why building privacy dev tools matters you already know how important this is. If you’re unfamiliar, I urge you to read that post. To summarize, governments, driven by the general public’s fear of Big Tech, are increasingly regulating software development companies. We’re the new oil, automotive, and financial services industries combined — all of which are regulated. The same is happening to software. As developers we’re in a position to build world-shaping technology, used by millions of people. That means our job now is more like a civil engineer, and with engineering systems for society at large comes tremendous responsibility.

What is an Ontology?

In its simplest form, an ontology is a model that allows you to represent classes ( our taxonomy) and their relationships to each other. In this modelling, we describe the behavior of those entities relative to each other.

For this reason, ontological design is subjective, complex and — in our experience at Ethyca — very iterative. We continue to refine the models and tools to support our language every day as we test new scenarios.

If you’re curious to learn more about ontologies in general, there’s a brief primer on ontologies which you can read here.

Objective of this Privacy Ontology

The objective of any valuable ontology is to create a shareable and reusable knowledge representation of a particular domain — in this case, privacy. This makes understanding and applying privacy for devs very challenging. How can we ensure we don’t misuse personal data if we’re struggling to agree on a definition for types of personal data?

Immediate Benefits of a Privacy Ontology

If you’re a developer who’s had to contribute in any part in data privacy work within your team, you’ll likely understand the benefits of a uniform and agreed-upon privacy grammar, and the benefits are real:

• Obviate the questionnaires for privacy reviews: A definition language for privacy allows devs to describe their code in their projects and automatically parse readable reports for privacy specialists.
• No more manual data mapping and annotation: Instead of having to do this on production systems in runtime environments, a grammar allows devs to describe their datasets and codebase before deployment.
• Quicker in CI approvals: If code is self-described in an understandable format, approvals can be approved against policies set by the organization.
• Privacy by Design at the core: A well-understood ontology provides that knowledge in a simple-to-implement format assuring that you’re quickly and more naturally folding PbD into your dev processes.
• Automated privacy requests: By describing privacy with a well-defined ontology during the implementation process, all new features and datasets are deployed with a metadata layer that allows you to identify the types of data you’re processing.

Future Benefits of a Privacy Ontology

If we can work together to define a standard ontology for privacy that is freely available and easily adopted as part of existing tools in our dev process, the longer-term benefits for engineers are endless:

• Prebuilt privacy libraries and modules: An agreed standard ontology will give rise to libraries for languages and frameworks.
• Semantic privacy CI checks: Policies of what is permitted in development can be written in the ontology and checked against PRs before they’re merged.
• Semantic, fine-grained ACL: It’s possible to enforce individual users’ rights at the db level.
• Privacy practises as interfaces: The privacy behaviors of any system should be exposed as part of the interface.

Summary

In summary, an open standard for privacy grammar would encourage transparency of system design and behavior, as well as simplifying the implementation of privacy for developers. Providing every developer with an easy way to make privacy a basic hygiene factor of good coding practices — that’s what a great privacy ontology does. It’s what we’re working towards, and I’m excited to share more soon.