BLOCKCHAIN ECOSYSTEMS IN A GDPR LEGAL COMPLIANCE PERSPECTIVE:

______________________

INTRODUCTION

Case II assesses the German ruling 16 O 341/15 as a contribution to the future interpretation of the regulatory framework set out in the GDPR. The case focus is built upon the Conditions of Consent found in Article 7 GDPR. The German ruling will be briefly summarized, cf. section I, and then contribute to, inter alia, the scope and conditions of consent found in Article 7 and the explicit requirements, cf. section II. Section II’s main focus shall be the “default settings issue”. The specific problem regarding effective consent protocols is then underlined, cf. section III. The advantages of a blockchain ecosystem in regards to consent transactions are sketched up, cf. section IV. Lastly, I will showcase how blockchain technology can decentralize consent distribution viably, cf. section V. The purpose of this paper is to construe the specific conditions for consent, ultimately breaking them down to a concrete example. This will naturally translate the conditions into aspects recognized in real world businesses and hopefully provide the reader with an understanding of the conditions for consent.

I. BRIEF SUMMARY OF THE GERMAN RULING 16 O 341/15

The Federation of German Consumer Organisations (VZBV) brought the suit, stating that Facebook does not provide the users with sufficient information about the scope of the consent and thus against German consumer law. More specifically, VZBV found that the consent does not apply to the default settings, as the settings diverge from the specified purposes found in the consent. Thus, the Landgericht Berlin declared the consent and Terms of Service invalid. Facebook stated that they would appeal the case and referred to their current GDPR compliance initiative. Now, the ruling does not concern the GDPR. However, it will most likely contribute to the understanding of future Data Protection issues, cf. section II & III, due to the community of law in EU (see, e.g., the Brussels 1 Regulation).

II. CONDITIONS FOR CONSENT: DEFAULT SETTINGS

Article 7 outlines the conditions for the data subject’s consent. According to paragraph 1, “(…) the [data] controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data.” As the German ruling 16 O 341/15 shows, this cannot be demonstrated by referring to a set of default settings. Hence, the data controller needs to more specifically monitor the protocol and consents to ensure that they comply to the requirements set out in the GDPR. This issue shall be further addressed in the sections III-V below, where a blockchain solution will be introduced in section V. If the data controller wants to process personal data authorized by a data subject consent, the consent shall be clearly distinguishable from others (unambiguous), specific, intelligible and in an easily accessible form (see Article 7 (2) and Recital 32 GDPR). Furthermore, the consent shall be freely given (see Article 7 (4) GDPR). To determine if a consent is freely given, the consent must undergo a specific further assessment. If, e.g., a consent is given to a data controller who also happens to be the data subject’s employer, certain points talk towards the consent being freely given. This is of course due to the fact that an employer has a position of “contractual dominance”, as the employer/data controller would be able to put pressure on the employee/data subject in that current relation regarding the consent distribution, which means that the data subject would have no genuine free choice and thus be unable to decline without detriment (see Recital 42–43 GDPR). Moreover, if a certain service pre-ticks a box on its portal, the consent shall not be considered freely given which supports the overall disregard towards these types of dispositions in the regulatory paradigm of EU and the German ruling 16 O 341/15. A consent can however be given by, inter alia, marking a box in a set of settings, if it is provided as a “(…) clear affirmative act (…)” (see Recital 32 GDPR and above). It is thus recommendable that the data controller ensures the data subject’s consent by providing several tick-boxes that each state their specific purpose(s) to accommodate unnecessary disruption (which would hinder GDPR-compliance and make the data controller subject to administrative fines).

If the service provided by the data controller involves the processing of sensitive data, the data controller must furthermore ensure that the consent is explicitly given (see Article 9 (2) (a) GDPR). If Union or Member State law, such as a social security law, prohibit sensitive data (defined in Article 9 (1) GDPR) processing in certain ways, the data controller must seek authorization to process the data elsewhere (in Article 9) (see Article 9 (2) (a) GDPR).

III. WHY A VIABLE CONSENT PROTOCOL IS THE KEY TO FUTURE SUCCESS

As stated in the aforementioned German ruling 16 O 341/15, Germany (i.e. representing EU, cf. section I and II) does not consider default settings a consent. This will force data controllers that, e.g., engage with blockchain networks to accommodate the GDPR enforcement date with correct procedural preparation. A requirement that can be resource heavy for the unprepared data controllers is, inter alia, the data subject’s right to withdraw a consent as easily as it was distributed (see Article 7 (3) GDPR), cf. section II, as the data controller might need to rethink the very business procedure. A demand for viable “consent-distribution” solutions will thus arise. The data controller shall be liable for ensuring compliance with the regulatory framework of the GDPR. The purpose of ensuring the correct specific consent is mainly to prevent a business devastating fine of 20.000.000 EUR or 4% of the total worldwide annual turnover of the preceding financial year (see Article 83 (5) (a) GDPR). Another (often disregarded) effect is how that business will be publicly degraded as an unreliable institution that does not meet the EU standards. This will certainly demolish the remaining parts of a business (given that there are viable alternatives to the services provided).

IV. HOW A BLOCKCHAIN OPTIMIZES THE PROCESS

As outlined in Case I, section III, a blockchain is a distributed ledger/peer-to-peer trustless network that automatically manages the verification of records. Moreover, a blockchain network can provide a transparent automated system of trust that can ultimately facilitate an administration protocol that complies with the GDPR, as it is secure by design (see Article 25 GDPR). This provides the data controller with an interesting and very viable alternative to current consent procedures.

A specific use case is outlined and illustrated in section V just below.

V. “THE CONSENT NETWORK”

Data controllers would have to a) dedicate enormous amounts of resources to collect and process consents manually, especially due to the amount of information passed back and forth between the parties or b) risk being hung out like Facebook did in the above-mentioned German ruling 16 O 341/15 and thus risk a fine as outlined in section III. A consent network would automate this process and redefine the standard of convenience (for the data subject/customer) and trust (between both parties) without compromising with the Conditions for Consent.

The data subject’s consent is encrypted into a blockchain block which will be accepted in the blockchain network’s consensus model. The data subject thus has the ability to easily distribute the consent to relevant institutions that he/she wishes to engage with. When agreed upon, the data controller would direct the data subject to its block on the blockchain by passing over an authorization to do so. The data subject would then transfer its consent-block to the block belonging to the data controller. The data subject would thereby naturally own the personal consent block and will thus be able to strictly control its distribution. The withdrawal of consent as set out in Article 7 (3) GDPR would only require the data controller to transfer the consent-block back to the data subject, and is hence easily conducted, as the process would be almost entirely automated and controlled in an immutable tamper-proof environment. Furthermore, the data controller would have easy access to demonstrate that the data subject has consented to the processing of his or her personal data (see Article 7 (1) GDPR).