Privacy by design calls for data governance to be designed into technology systems in which they operate. But if we can embed it into the code of digital public infrastructure that is deployed at scale through society, it could be far more effective.
This is a link-enhanced version of an article that first appeared in the Mint. You can read the original here.
If you are a regular reader and are wondering why this looks different it's because its coming to you from Paragraph, a Web3 newsletter. Based on feedback I might make this permanent.
The main challenge with data governance is effective enforcement. Our approach, so far, has been to pass laws that constrain the amount of data in circulation and the uses to which it can be put. We did so in the belief that all it takes to protect individual rights is to limit the volume of data in circulation and get businesses to agree to use it narrowly.
This approach, has, however, been unsuccessful. Modern businesses are aware of the benefits that accrue to them if they maximise the data under their control. As a result, their incentives are oriented in the exactly opposite direction to that in which these laws want them to move.
This is why modern businesses are constantly trying to find ways around these regulations - stretching the limits of how much data can be collected and the purposes for which they will be used.
Laws are ineffectual when there are strong incentives to evade them. Since they have to be expressed in words, businesses can choose to interpret them in ways that skirt around the edges of what is permissible - to continually increase the ways in which data can be monetised. Regulators, on the other hand, are constantly playing catch-up, trying to shut these loopholes down - even though they know that for every on they close a new one will pop up.
Privacy by Design
It is perhaps in response to this game of regulatory whack-a-mole that the concept of Privacy by Design was born.
Rather than requiring compliance through covenants, this builds privacy directly into the design of the technology. It forces organisations to adopt a more privacy-first approach to client engagement - instead of looking to maximise the data they can use and collect.
Here's a talk I gave at DesignUp 2022 that might help you understand it better:
As much of an improvement as this is over the more traditional regulatory approach we are accustomed to, its success is still dependant on data businesses actually implementing these measures. Doing so is, as we have seen, fundamentally opposed to how their incentives are aligned.
This is where India's techno-legal approach can offer a useful alternative. By incorporating regulatory principles directly into the code of infrastructure built in the public interest, it obliges all entities that use it to comply with those regulatory stipulations. Since the code is designed and managed by the government or operates under the supervision of a regulatory framework, it can be constantly re-oriented to address efforts made by participants to subvert its operational objectives.
But India's digital public infrastructure has, additionally, been built according to a set of design principles that, give regulators new ways in which to achieve their regulatory objectives. It is worth discussing how.
Take for example, the principle of interoperability. All of India's digital public infrastructure has been built to be modular, extensible and interoperable. This is allows the infrastructure to interact with the systems of private and public entities in a technical manner that ensures optimal re-usability and integration.
But this interoperability also serves another purpose. Where regulatory principles can been embedded into a given modular digital building block, every other digital public infrastructure that relies on that building block to perform a given function will automatically follow those principles. As more and more such building blocks are built, all infrastructure assembled using these elements will implicitly have these principles embedded into their functioning.
Regulators can use this to their advantage, infectiously achieving regulatory objectives through the technical design of individual building blocks.
Another example of regulatory design is the federation implicit in the structure of most Indian DPIs. By ensuring that data remains where it was collected instead of aggregated into a single common repository, Indian DPI takes advantage of the data security that is inherent in federated design.
All data systems are vulnerable to breach and accumulating data in one place intensifies that. Keeping data at the edges where they currently reside and designing the system so that it is possible to easily access it when required considerably reduces that risk.
This also has the added advantage of mitigating concerns around the use of data for surveillance. When data is pooled into a common repository it makes easier for it to be used to derive inferences about all to whom that data pertains. Ensuring that the data remains federated makes it that much harder to do so. Having federation built into the design of the DPI in this manner, mitigates these concerns.
Finally, most Indian DPI are described in terms of protocols - specifications that articulate how they should be built without actually getting into the details of platform design. It is then left to participants in those ecosystems to incorporate them into the technology systems that provide the services that the DPI was designed to offer.
This approach has parallels to what I have written about often in this column - the notion of principle-based regulations as a way to address the challenges of governing fast moving technologies. By implementing a protocols-based approach, Indian DPI have incorporated the concept of principles-based regulation into its design.
As the conversation around DPI gains traction it is important that we reflect on these additional aspects as well. It is only through an appreciation of how these elements work together that we will be able to design effective data governance solutions.
If this email was forwarded to you by a friend, please consider subscribing. You will save her having to do this again, week upon week.