Background of the TTDSG

One of the reasons for which the TTDSG was passed is the fact that the former German implementation act for the Directive on Privacy and Electronic Communications (Directive 2002/58/EC) ('the ePrivacy Directive') was hardly in line with Article 5(3) of the latter. The Federal Court of Justice ('BGH') had to 'bend' the wording of the German provision regulating an exemption of the need to obtain consent for cookies in its judgment on the 'Cookie-Einwilligung II' case. Otherwise, the BGH would have had to declare the provision inapplicable due to conflicts with Article 5(3) of the e-Privacy Directive. In the 'Cookie-Einwilligung II' case, the BGH decided that a user not consenting to the use of cookies is equal to a user objecting against the use of cookies. For a data protection professional, this result sounds at least odd, if not even wrong.

Following this judgment, the German regulator wanted to make the legal situation clearer by changing the provisions on access of information stored on devices and storing information on user's devices. However, the new Section 25 of the TTDSG is mainly the wording of Article 5(3) of the e-Privacy Directive copy-pasted into national law. Legal certainty is therefore not really achieved.

The TTDSG was not introduced merely to change provisions on cookies and similar technologies, but also, as the full name of the law reveals, to change provisions regulating telecommunications. However, the Guidelines only cover aspects relating to the national implementation of Article 5(3) of the e-Privacy Directive.

Background of the Guidelines

Before the judgment of the BGH, the DSK already published guidelines relating to the storage of information on a user's devices and accessing information stored on devices. In this publication, the German authorities took the standpoint that the German exemption from the consent requirement was in conflict with Article 5(3) of the e-Privacy Directive and therefore inapplicable. As the judgment of the BGH shows, it was a completely reasonable argument to assume the inapplicability due to 'objection' and 'consent' being something completely different and referring to different legal bases under data protection law.

The old guidelines advised companies to apply the legal basis under the GDPR to both the access to or storing of information on a user's device and the afterwards occurring processing of personal data. The new provisions of the TTDSG now require companies and data protection authorities to separate between the access to, or storing of, information on a user's device regulated in Section 25 of the TTDSG on the one hand, and the processing of personal data only in scope of the GDPR on the other hand.

Selected aspects covered in the Guidelines

The Guidelines are 33 pages long. They are generally well written and a helpful asset for data protection professionals wanting to understand the authorities' views on highly relevant aspects of using cookies and similar technologies on websites, in apps, or other technologies. Even cars are understood as being a user's terminal equipment. The Guidelines are therefore also relevant for any storing of, or access, to information stored in a board computer of a car. The following sections provide a summary of selected aspects touched upon in the Guidelines.

Scope of applicability of the TTDSG

The TTDSG only applies to the storing of information or to gaining access to information stored in the terminal equipment of a subscriber or user. The GDPR applies to any processing of personal data occurring afterwards. Even when the information accessed or stored is personal data, the TTDSG applies exclusively as it is the lex specialis. In contrary to the GDPR, Section 25 of the TTDSG only protects the privacy of users, not their right to protection of personal data enshrined in Article 8 of the Charter of Fundamental Rights. Section 25 of the TTDG applies to any storage and access to information stored in the terminal equipment. This means that any form of devices with a 'communication function' can be in scope of this provision. However, according to the Guidelines, there needs to be some sort of connection over the internet. Otherwise, Section 25 of the TTDSG does not apply. This is for example the case for company-internal intranets.

According to the Guidelines, 'gaining access to information stored' requires that the user does not transmit the browser information actively on its own. When information, such as the browser version, language used, referral URL, and public IP-address (commonly referred to as log files), is transmitted to a website operator when a user accesses the website, the processing of this information is not covered by the TTDSG. The processing of such information falls within the scope of the GDPR as long as personal data is processed. The TTDSG is only relevant when the operator actively (for example, via java scripts) accesses the information and does not simply receive it from a user.

Legal basis under the TTDSG

The applicability of Section 25 of the TTDSG results in consent being needed more often than for data processing under the GDPR, because not all legal bases under Article 6(1) of the GDPR are part of the TTDSG. The DSK emphasises that under the TTDSG there are only two forms of legal bases. Either consent is required, or no consent is required. There is no need to gain consent where either:

• technical storage or access is done for the sole purpose of carrying out or facilitating the transmission of a communication over an electronic communications network; or

• storage or access is strictly necessary in order to provide an information society service explicitly requested by the subscriber or user.

The second exemption is way more relevant for companies and consequently also in the focus of the authorities' assessments in the Guidelines. In cases where cookies and similar tools are used for multiple purposes, companies need to pay attention to only use them for more than one purpose if either all of those purposes are exempted from the consent requirement, or if none is exempted. Otherwise, the multi-usage of one cookie for purposes requiring consent and purposes not requiring consent at the same time, according to the Guidelines, results in the need to obtain consent for all purposes. This is true even for those purposes that as a stand-alone solution would not require consent.

Explicit requests

For companies to rely on the exemption in Section 25(2)(2) of the TTDSG, their users need to explicitly request an information society service. According to the Guidelines, the scope of functions requested by users must be assessed in each individual case from the perspective of users with an average level of understanding. Within the Guidelines, the DSK explains that for determining the services explicitly requested, companies should consider the following:

• establishing granular definitions of which function of the service requires which specific storage and access of information on the end device; and

• determining whose primary interests this function serves: of the provider, the users of the website, the integrated third-party service provider, or third parties.

In the context of services 'explicitly requested' by the user, the Guidelines stress that the mere use of a service does not mean that a user requests all kind of functionalities which a user may in practice not use at all. According to the DSK, it is not possible to look at a website as a service as a whole, because service providers would then be able to decide what kind of storage of information and access to information would be necessary and the user's requests would be undermined.

The German authorities differentiate between 'basic functions' of a service and 'additional functions' to make it easier to assess what is requested by a user. This is a very important 'invention' made by the German authorities. Basic functions are those that are inseparably important for the entire service offered and to some extent result from the nature of the services offered. Basic functions are therefore always requested by users via them using a service.

The Guidelines provide the following example on search engines: 'the basic service of a search engine is that when a search term is entered, matching web pages are found on the internet and listed as search results via hyperlinks'. According to the Guidelines, basic functions are in principle explicitly requested by users via them accessing and using the service already. The storage and access necessary can be done without consent. Interestingly, storage or access for fraud prevention and security is also part of the basic service. The DSK states that tools used for those purposes equally benefit the controller and user, and are therefore part of the basic service.

In contrast to the basic functions, users explicitly request 'additional functions' only when they actively start using the function and not already via accessing the service provided. Examples listed in the Guidelines are clicking on a chat bot, creating a wish or watch list, or filling out a form.

According to the Guidelines, a user of a web shop, for example, only requests the function 'shopping cart' when a user puts an item in the shopping cart and not already by the mere use of the website. The publication also addresses tools for measuring and analysing visitor numbers and A/B testing. Those tools are not per se part of the basic service. To determine if they are part of the basic service and therefore do not require consent, it matters whether the specific purposes of the functions, which have to be considered in a very granular way, are carried out in a user-oriented manner. This is one aspect for which it becomes visible that the authorities consider whose primary interests a function serves.

Strict necessity

Only were a company can demonstrate that an information society service was explicitly requested by a user, it can further assess if the strict necessity is also given. With reference to the legislative justification of Section 25 of the TTDSG, the DSK stresses that 'strictly necessary' must be interpreted from a technical perspective. Some data protection professionals traditionally do not agree that necessity needs to mean in technical terms, and not, for example, also economic necessity. However, according to the opinion of the German authorities, it is not possible to argue that the use of cookies and similar technologies is necessary from a business perspective. The Guidelines explain that for determining what is strictly necessary, companies should generally consider the following:

• time of storage: when may the information be accessed or stored?

• content of the information: what information is stored or accessed?
• duration of information storage: how long is the information stored on the end devices and for how long can it be accessed?
• readability of the information: for whom is the information accessible and usable?

According to the Guidelines, the criterion of necessity has temporal, content-related, and personal dimensions. The time of storage (when?), the duration of the cookie (for how long?), the content of the cookie (what?), and the setting domain of a cookie that decides who can read the information (for whom?) must always be considered. The access to the terminal equipment and the access to the information must be reduced to the necessary minimum with regard to all dimensions to be ‘strictly necessary’.

An example of a statement made regarding the temporal dimensions is that shopping cart cookies do not need to be set before a user puts something in the shopping cart. The same counts for cookies used for payment functions. The authorities conclude that normally cookies should only be required for a session, and not longer. One must say that this is probably too general to be true. According to the Guidelines, however, something else only counts regarding registered users. It is also stated that unique cookie IDs are often not strictly necessary: 'for example, it is not considered necessary that a cookie with a unique ID is stored long-term and can be retrieved for storing consent or for load balancing. The same applies to storing settings for language or background colour. This does not require a unique identifier, such as a unique user ID, but rather the storage of a non-identifying specification, such as "background-colour: black" or "language: de" is sufficient'.

Philipp Quiel Counsel
[email protected]
Piltz Legal, Berlin