ePrivacy Roundtables

I am participating in the works on the ePrivacy Regulation. Last week I have attended ePrivacy Roundtables, organised at the European Parliament. That was an interesting opportunity to exchange opinions, present and exchange views. There were four Roundtables on the following topics: Cookies, Article 8, Consent, Privacy by Design and by Default. In this note I will write down a few of the items I discussed, taking part in all of the mentioned Roundtables as an independent security and privacy researcher. I won’t disclose who was among the other attendees, as the discussions were organized under Chatham House rule.

Cookies

We must go beyond the traditional perception of identifiers. ePrivacy speaks about cookies, but we should speak about identification and tracking. There are many possible ways to identify users on the Internet - for example fingerprinting. Reducing the rules of ePrivacy merely to cookie setting is no longer appropriate.

Article 8

Article 8 is very suboptimal. It sanctions ubiquitous wifi/bluetooth tracking; increasingly used technologies. Among the recent deployment places are airports (Copenhagen, Manchester) or public transportation systems (Transport for London - Tube). The problem with Article 8 is the exception in the point 8.2(b), which - in short - allows tracking without meaningful consent (showing a sign “tracking zone” is not consent). The actually proposed choice for not granting consent in that case is turning off a device (or randomizing identifiers). The problem with this approach is that we’ll soon arrive in a place where tracking will be ubiquitous and choice will be artificial.

In fact, 8.2(b) in my opinion is not in line with GDPR, specifically:

silence, pre-ticked boxes or inactivity should not therefore constitute consent. Personal data should be processed on the basis of the consent given freely by the concerned data subject or some other legitimate basis, consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse

The exception from 8.2b is also incompatible with the European Charter of Fundamental Rights, specifically:

Article 7 - Respect for private and family life

Article 8 - Protection of personal data
Article 45 - Freedom of movement and of residence

So it looks like sooner or later, 8.2b would end up in the European Court of Justice anyway.

We all hate the “cookie notice pop-ups” on websites. ePrivacy intended to fix that. But first, it really doesn’t, and second - it still relies on manual tick-boxes. These days web browsers are powerful and can transfer consent to websites automatically, via the Tracking Preferences Expression signal (also called Do Not Track). This particular solution should be the preferred one and actually written down in the text of ePrivacy to make it unambiguous. It would be a good mechanism, and since it’s developed within W3C - it’s technology-neutral. Not including specific note that the “automatic means of consent” is TPE/DNT creates risks that users will be able to use made-up consent signals and expect these to be honored by websites (which is made possible by ePrivacy at the moment!).

Another place for consent on the web is browser permissions. Sensitive mechanisms (examples: 1, 2, 3) should always be protected with permissions, and their use should always be clear to the users. One point: I disagreed with a view that “since hackers don’t need consent, cybersecurity products don’t need it either”, because obtaining consent here is possible; and with a view that “It’s not possible to ask for user consent by Internet of Things devices” - yes it is possible, just make design reasonable.

End-to-end encryption.

I strongly endorsed writing end-to-end encryption in ePrivacy and making it mandatory where possible. I know my views weren’t isolated. I am also aware of possible amendment suggestions promoting end-to-end encryption. However, I am also aware that there are parties against strong encryption.

Privacy Impact Assessment

It’s as good tool for building user trust and transparency, and at the same time supporting the notion of privacy as a process. It helps designing systems with privacy built-in. But it should not be perceived solely as a compliance tool.

Privacy by Design and by Default

My position here is that ePrivacy concerns technology, so it should speak technology. The technological arm of Privacy by Design is called privacy engineering. New systems and standards should always be developed with privacy in mind - from the ground up. Privacy by Design is not merely about cookie settings and defaults, it a more general paradigm. Privacy by Design is also not merely anonymization. It’s privacy enhancing technologies, it’s privacy impact assessments, it’s good designs. It’s a comprehensive process.

This view is gaining popularity, both in the USA and in Europe. It would be good if ePrivacy would accept it now, and not wait for ePrivacy update, scheduled in three years.