Privacy design requirements for DECODE

For the DECODE project we performed an initial study to chart the initial privacy requirements for DECODE and how they could be addressed in the DECODE architecture. As a point of departure we took the Privacy Design Strategies that we developed several years ago. These strategies translate
the soft legal norms into more concrete design requirements that engineers understand.

Eight privacy design strategies

In fact there are eight privacy design strategies in total, that we briefly describe below together with their ramifications regarding the DECODE architecture.

1. Minimise: Limit the processing of personal data as much as possible.

Explicit selection or exclusion of data items should be done by DECODE nodes according to strict rules, that depend on the specific application at hand.
As an example, data items processed by DECODE should always be tagged with an expiry date. This should happen at the smallest granularity of data items where a distinction between expiry dates is relevant. Any node that encounters a data item whose expiry date lies in the past should discard that data item (and any copies thereof under that node'’ control). This can also be enforced by the smart rules supported by the DECODE architecture.

2. Separate: Prevent correlation of personal data by separating the processing logically or physically.

DECODE’s use of a federated distributed storage based on blockchain technology, where the DECODE nodes each independently contribute their resources (storage and compute cycles) in a controlled manner to the overall system implements the "distribute" tactic a form of distribution/separation.

DECODE in the end provides a platform on top of which many different applications may run simultaneously. Isolation can be achieved by tagging data items with the application they were collected or created for, to avoid reuse of data items for other applications. The smart rules (that typically are at the core of such applications) can be used to force this isolation (by checking the tags of all data items they process), but we note this is a type of isolation ‘by convention’ only that in theory can be bypassed,

3. Abstract: Limit as much as possible the amount of detail of personal data being processed.

There may be a way for DECODE to implement a way to summarise data if it provides a query engine for aggregated data that removes all details and only provides aggregated information. Perturbation can perhaps be used in an ad-hoc fashion to the storage of raw data in some cases.

4. Hide: protect personal data, or make them unlinkable or unobservable. Prevent personal data becoming public. Prevent exposure of personal data by restricting access, or hiding its very existence.

Within DECODE access to data, including to personal data, is restricted based on the concept of entitlements. Only an actor possessing the necessary entitlements can  access a resource.  Entitlements are implemented based on the concept of attribute based credentials, that in fact provide another layer of privacy protection due to the fact that they are unlinkable to individuals (unless, of course, the attributes used identify a person by name or number). Finally, all personal data in DECODE is encrypted.

5. Inform: provide data subjects with adequate information about which personal data is processed, how it is processed, and for what purpose.

DECODE aims to implement this strategy in several ways. First of all, there is a strong focus on open source hard and software, both for the DECODE nodes as the interconnecting infrastructure. Second, transparency and auditability are core technical values. This is exemplified by the use of open blockchain technology for the mediation of all transactions involving personal data. Finally, DECODE aims to deploy declarative and intelligible smart-rules that can be well related to legal taxonomy.

6. Control: provide data subjects mechanisms to control the processing of their personal data.

The main element of control provided to users of the DECODE platform is by expressing entitlement conditions for the access to individual pieces of personal data. A graphical user interface and an intuitive language to express these conditions and the associated entitlements and smart rules will be developed to support the user to exert his or her control.

7. Enforce: commit to a privacy friendly way of processing personal data, and enforce this.

Services provided over the DECODE infrastructure should specify a clear privacy policy. The DECODE infrastructure itself should provide tools for easy enforcement of such privacy policies. This is partially achieved through the concept of entitlements, matching attributes, and the use of smart rules that govern the access to personal data.

8. Demonstrate: provide evidence that you process personal data in a privacy friendly way.

So-called Privacy Impact Assessments (PIA), also for the cases in which this is not mandatory, can be a good tool for assuring certainty, transparency of the processing and fostering trust in the architecture (mainly for public sector bodies and companies who are committed to adopt a PIA). It is recommended to each service provider offering services over the DECODE architecture to perform such a PIA. 

The DECODE architecture itself facilitates this through the use of open blockchain technology for the mediation of all transactions involving personal data, thus providing accountability as a built-in feature.

Conclusion

The eigth privacy design strategies proved to be useful tool to elicit privacy protecting recommendations for the DECODE architecture.

We will review the application of these ideas in the final DECODE architecture halfway through the project, and will propose more fine grained recommendations around that time.