D3.8: Study on protocols with respect to identity and identification – an insight on network protocols and privacy-aware communication

Title: DESIGNING PROTOCOLS WITH OR WITHOUT PRIVACY EXPERTS

Protocols are the foundation of information and communication technologies (ICT). According to Lessig, protocols belong to the major regulators which have a profound impact on society and whose implications must be considered (Lessig 1999). This applies for all implementations of protocols, forming the architecture of ICT and providing today’s possibilities for usage. In addition, the specifications of protocols already play a role as they are the blueprint not only for implementations thereof, but define interfaces to other specifications and implementations. 

If protocols, i.e., their specifications and/or their implementations, are faulty, the applications on top usually cannot eliminate the mistakes, but often even intensify the consequences. As previously argued, linkability between different uses of protocols – possible by cross-layer analysis, possibly even by hidden identifiers – may already cause privacy threats which can yield undesired consequences for the individuals concerned (cf. Hansen, Meissner 2007). Considering the complexity of the area and the massive influence of protocols on the Information Society, a privacy and linkability analysis should be performed during the design phase of each protocol. Art. 20 of the Directive 95/46/EC deals with “prior checking” which should be carried out when the processing operations are “likely to present specific risks to the rights and freedoms of data subjects” (EU-DPD 1995). In particular outside the European Union, e.g., in Canada, the United States, Australia and New Zealand, a similar procedure is also known as “Privacy Impact Assessment”. Taking this seriously, privacy experts would have to be involved right from the beginning in each design process of communication protocol specifications. 

The general participation of Data Protection Authorities (DPAs) and other trusted parties in the technology design process for better trust and trustworthiness was proposed by Köhntopp and Ruhmann who, as employees of a DPA, had first-hand experience determining factors regarding possible privacy impact assessment (Köhntopp, Ruhmann 1999). However, a limiting factor is the lack of resources of DPAs concerning budget for personnel, for travelling and participating in meetings where protocols are being specified as well as lacking skilled staff in all areas of research and development of protocols.  

There are various reasons for not seeking participation of privacy experts when designing protocols: 

1. Specification work on protocols is usually application-driven where primarily functionality requirements are the focus. Privacy requirements are often regarded as a secondary objective which comes into play at a later stage. 

2. Naïve implementations – and also specifications – are often privacy-invasive, e.g., centralised storage of data, unique identifiers, and lots of debug information according to what engineers and computer scientists learn in their training. In many cases privacy-enhancing components add complexity in the design process. 

3. The work is mainly performed by technologists and implementers instead of legally skilled people who are aware of national or – with international protocols – even global legal regulations. 

4. The language of specifications is not always easy to understand for laymen, lawyers or also people skilled in technology assessment. This is a severe obstacle to their involvement. 

5. The complexity of today’s ICT world with all its interdependencies is hard to cope with for everybody. Thus, a thorough analysis of protocols in an early stage may not cover all privacy-relevant issues arising from the interplay with other existing or upcoming protocols and applications. 

Indeed during the last decades very few DPAs were involved when protocols were specified, and those involved usually participated only in the design of specific protocols and languages focusing on privacy and data protection (such as P3P or EPAL, as introduced in Section ). However, all kinds of protocols have been discussed and criticised in the privacy community, e.g., because of shortcomings concerning important privacy concepts such as data minimisation, transparency or the user’s self-determination, but usually after the finalisation of the specification process and without a serious attempt to modify the specification or even stop the implementation or use of a protocol.