After reading Case C-40/17 and Case C-210/16 I still cannot figure out why GDPR would require "joint controller" decision.

Wouldn't it be much simpler to decide that e.g. in "Fashion ID" case, the Facebook cannot set cookies if Facebook hasn't acquired consent from the end user? That would allow embedding Like buttons on any page at will and Facebook could only track the users that have already given consent for Facebook. Technically facebook would have been able to run their own JavaScript code on the host page so they could have implemented the consent query on any page if they really wanted to set cookies only after getting consent.

This would also immediately solve questions such as Who's liable for GDPR compliance when embedding/hosting a self-contained 3rd-party website/service? and Who needs to implement Cookie Consent for embedded content? because in both cases the host that wants to set non-necessary cookies would need to independantly verify they already have been given consent for those cookies. As GDPR doesn't define how such content must be acquired, there could be an UI on the host domain document and then the acquired consent must be explicitly transferred to 3rd party. In practice, the transfer cannot be just "it's okay" but "user has given consent for trackingdomain.com via domain example.com at yyyy-mm-dd with log id abc123ef" because GDPR requires that the user must be able to retract the consent later and entity doing the processing must be able to specify the origin for the consent.

Is the current ruling just caused by the interpretation that embedding any content via URL is considered implicit consent for the whole domain?

In practice, this would practically prevent 3rd party cookies for any services the user hasn't expicitly visited previously.

1 Answer 1


The rulings you refer to are not primarily about cookies or consent. They are about pages who use Facebook services, and claim that Facebook would be the sole data controller. As the ECJ has ruled, this is not the case: causing or contributing to Facebook's processing of personal data can establish a joint controller role. Thus, the admin of a Facebook page ends up being co-responsible for the correct use of cookies on that page, and the embedder of a Facebook like button ends up being co-responsible for sending visitor data (such as IP addresses) to Facebook.

You are correct that joint controller situations are messy and potentially difficult to navigate. But the “joint controller” concept reflects the reality of the legal situation that more than one person/entity can meet the definition of a “controller” for a particular processing activity.

It is possible to avoid joint controller situations, for example when processing activities are structured suitably, or when one party engages the others as data processors. Of course, it would be contrary to Facebook's interests to act as a data processor because FB wants to use the personal data for their own purposes, not solely for the other controller's purposes.

Some detailed notes:

  • The Fashion ID case does not involve the setting of cookies, it applies more generally to any personal data a browser might send while making a request.

  • Both of these cases are not about Facebook's responsibilities, but about the responsibilities of data controllers that use Facebook's services. You can't just embed/use third party services and argue that you're not responsible for compliance.

  • GDPR does not require explicit records of consent to be stored. Doing so might even violate the data minimisation principle. The GDPR has the weaker requirement that “the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data” (Art 7(1)). This could perhaps be demonstrated indirectly, e.g. that it is not possible to trigger the processing activity without giving consent.

  • The controller of a page embedding content does not have influence over the use of cookies by that embedded content and would not typically collect consents for that content.

  • Instead, embedding pages typically collect consent for the loading of third party content, e.g. “click to show content from twitter.com” or a greyed-out Facebook icon with a toggle next to it. This page (about the Fashion ID ruling) has a wonderful example with an embedded YouTube video:

    a blurred-out placeholder for a YouTube video player embedding, with a consent dialogue up front

    Source: https://www.verbraucherzentrale.de/wissen/digitale-welt/datenschutz/eughurteil-likebutton-von-facebook-nur-mit-info-an-nutzer-12029


    The video is currently deactivated to prevent unwanted data transfers to Youtube. To activate, please click the link! This will transmit data, but we can't provide information on their type, scope, and purpose.

    Link: show video

  • There is no such thing as implicit consent under the GDPR. Consent must be indicated unambiguously. Art 4(11) defines consent as “any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data”.

  • It is quite likely that, were Facebook to set cookies via embedded Like buttons or to use Like buttons to create profiles of users that are not Facebook members, that Facebook would be acting illegally. The lack of suitable consent would be a concern. But that matter was not being litigated in the cited cases.

  • If I've understood correctly, a static HTML page using <iframe> to embed Youtube video might be breaking GDPR according to the above rulings. This is technically similar to Facebook Like button except Like button can run its JS code in the host document and Youtube has to run its JS code within iframe container. Commented Sep 10, 2020 at 14:38
  • @MikkoRantalainen yes that is my understanding – an iframe embedding third party content raises GDPR compliance questions. But not necessarily illegal, this depends on the context.
    – amon
    Commented Sep 10, 2020 at 14:55
  • Yeah, that's my reading of the above cases, too. However, that really doesn't make any sense because nearly all pages load e.g. some common libraries such as jQuery from CDN and technically CDN serving JS library is identical to Facebook serving JS code for the Like button implementation. Commented Sep 11, 2020 at 10:24
  • 1
    @Mikko Just because everyone is doing it doesn't mean that it is right. While there are technical measures to control the content of external resources (subresource integrity), this doesn't alleviate the problem that the HTTP request fetching the resource discloses personal data. Some CDNs may have privacy policies that can make them a data processor in the sense of GDPR Art 28, but I found it easier to stop using random CDNs back when GDPR came into force in 2018.
    – amon
    Commented Sep 11, 2020 at 11:10
  • 1
    @Mikko Yes, what the embed provider like Youtube does is probably not OK – the data controller for that processing has to fulfil the accountability obligations. Feel free to lodge a complaint against YT/Google :) This answer is less about embed providers and more from the perspective of a site operator who uses embeds. CDNs don't generally require consent, instead CDNs should be data processors. Nitpick: the GDPR distinguishes “consent” from “explicit consent” which is only required for Art 9 special categories of data and Art 49 international transfers.
    – amon
    Commented Oct 21, 2020 at 9:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .