Cookie compliance with GDPR when cookies don&#39;t collect the PII? We are using Google Analytics and Facebook Login button (Which comes with preset Facebook Analytics). So here is the question with Google Analytics we are not assigning users with GA UserID and IP anonymization is turned on. So GA assigns the Client ID only, which is randomly generated to each visitor of our website. Regarding to Facebook Analytics – Facebook states that they are not collecting Personal Identifiable Information in their Privacy Policy notice “Advertising, Measurement and Analytics Services (Non-Personally Identifiable Information Only).”. So do we still need to get the consent from users as information that both Analytics services collect is not PII?
First, when using profiling third party services (Analytics is "profiling" as defined by the GDPR), your main concern is not such a trivial thing as cookie compliance, but the security of processing I've analyzed Google's IP anonymization in some detail (as part of the DPIA I do for clients). My conclusion is that for most of the web-sites we manage, Google's IP anonymization is adequate to ensure security of processing as required by the DPIA process. However, on some sites that are likely to visited by users interested in what the GDPR calls "special categories of personal data" (Article 9), we either do not use Google Analytics, or we add additional layers of security in case the USA Government orders Google to disregard the stipulations in the DPA and hand over the data (yes, the US Government can legally do that - read the fine print in the Privacy Shield accord). As for Facebook Analytics, I think you've simply misunderstood their policy. Nowhere in that policy document does Facebook say that they "are not collecting Personal Identifiable Information". AFAIK, they collect tons of it, in all sorts of obnoxious and sneaky ways. What they actually say about PII in the context of Analytics is this: We do not share information that personally identifies you (personally identifiable information is information like name or email address that can by itself be used to contact you or identifies who you are) with advertising, measurement or analytics partners unless you give us permission. Let me remind you that one of their "analytics partners" was Cambridge Analytica, so if this promise not to share is true, it looks like a pretty new policy. OK, moving on to cookie compliance. To you (the controller), both Google and Facebook are processors. Given the history of the NSA and the methods it have used and AFAIK still use to get US-based companies to hand over the personal data about Europeans through orders issued by secret FISA courts, plus the fact that total nutcases currently are in charge in the USA, I am not going to rely on the privacy policy of any US-company for protection of personal data. So if I make use of Google Analytics (and I often do, they provide a great service), I always make sure that my users opt-in on that (hard cookie concent), even I make use of their IP anonymization feature (YMMV). As for Facebook, the fact that they promise not to share PII with third parties is irrelevant because they collect personal data. You will always need consent from your users to hand over their PII to Facebook in the first place. This is not optional. PS: If was a user, that consent would never been granted, no matter how great or valuable your site might be. If you have any sort of relationship with Facebook, I'll give you my personal data when you pry it from my cold, dead hands.
The line they'll rely on for GDPR compliance is the first part of that sentence - "If you agree to this during the order process", which suggests that there will be a separate request to opt in to marketing communications at some other time in the process. Check any order documents. There's likely to be a tick box or similar on at least one. If that implies opting out rather than opting in there may be grounds to argue with that under GDPR, but there's nothing in the quoted text that suggests a problem.
The GDPR applies regardless of where and how data is processed. But it is necessary to look at what the processing activities in question are, and who is the controller for these activities by determining their purposes and means. This argument is supported: by the absence of relevant exemptions in the GDPR by the GDPR's broad definition of the data controller by the ECJ's analysis in the Fashion ID case GDPR Exemptions For certain constellations (e.g. controller = natural person, purposes = purely personal or household activities) that processing is exempt from GDPR compliance (see GDPR Art 2(2)). However per GDPR Recital 18, the GDPR would still apply “to controllers or processors which provide the means for processing data for such personal or household activities.” For example, this means that I am able to use WhatsApp to process my friends' contact information for purely personal purposes because I'm exempt from the GDPR with respect to that processing, but Facebook is still subject to the GDPR regarding how they process personal data collected via WhatsApp. Already on the basis of the GDPR providing no exception for processing on someone else's computer, I disagree strongly with the answer you cited (and have already written a competing answer). It seems entirely counterfactual. How to figure out who the controller is. Per GDPR Art 4(7), controller is whoever “alone or jointly with others, determines the purposes and means of the processing of personal data”, although other laws might provide more specific criteria for individual purposes or means. We will return to that definition in the next section. The ICO has provided a checklist to figure out if you're a data controller or perhaps a joint controller. Some of the questions are aligned with the above definition, like “We decided what the purpose or outcome of the processing was to be”. Other questions are there as a contrast to the data processor role, e.g. “We have complete autonomy as to how the personal data is processed”. Analysis of the Fashion ID case (ECJ C-40/17) This judgement provides a detailed analysis of who the data controller is, and is therefore relevant to the question. Fashion ID had embedded a Facebook “Like” button on their website, thus causing the visitor's browser to transmit personal data to Facebook. Fashion ID asserted that they were not the data controller, since they had no control over what data was collected by the Like button and how it was subsequently used by Facebook. Fashion ID relied in part of the argument that they weren't the controller because processing happened on the visitor's computer. This ruling was made on the basis of the Data Protection Directive 95/46 which was repealed by the GDPR. However, since the DPD and GDPR have effectively identical definitions of “controller” and “processing”, the court's analysis remains highly relevant. In the following I'll “translate” all DPD references to the GDPR, in analogy to GDPR Art 94(2). The court found that Fashion ID was a data controller for the processing by the Like button, and that it was a joint controller with Facebook for this processing. However, Fashion ID was only a controller for those processing activities in which they played a part, not for subsequent processing of the data that was controlled by Facebook alone. Relevant details from the Judgment (ECLI:EU:C:2019:629): Paragraphs 65–66: The GDPR tries to achieve a high level of data protection through a broad definition of “controller”. Thus, an overly narrow interpretation that counteracts this goal is incompatible with the law. Paragraph 68: An entity is a controller when it exerts influence over the processing for its own purposes, thereby participating in determining the purposes and means of processing. Compare the GDPR Art 4(7) definition of “controller”. case law: C-25/17 Jehovan todistajat, ECLI:EU:C:2018:551, paragraph 68: “However, a natural or legal person who exerts influence over the processing of personal data, for his own purposes, and who participates, as a result, in the determination of the purposes and means of that processing, may be regarded as a controller”. Paragraphs 67, 69–70, 82: It is not necessary to have a single controller, there can be multiple joint controllers. The joint controllers can be involved to different degrees. You can be a joint controller without having access to the personal data. case law: C-25/17 Jehovan todistajat, ECLI:EU:C:2018:551, paragraph 69: “Furthermore, the joint responsibility of several actors for the same processing, under that provision, does not require each of them to have access to the personal data concerned”. case law: C-210/16 Wirtschaftsakademie Schleswig-Holstein, ECLI:EU:C:2018:388, paragraph: 38: “In any event, [GDPR] does not, where several operators are jointly responsible for the same processing, require each of them to have access to the personal data concerned.” Paragraphs 71–74: Processing can consist of many different individual activities. A controller might only be involved in some of them, and can only be a controller for those activities for which they (jointly) determine purposes and means of processing. Paragraphs 76–79: Fashion ID was able to determine the purposes and means of processing regarding data collection and transmission by the Like button. The act of embedding the button showed that they had decisive influence over the processing: without the embedding, the data processing would not have occurred. To summarize the relevant conclusions: someone is a data controller when they participate in determining the purposes and means of processing for some processing activity for joint controllers, this holds regardless of whether they have access to the data or participate in the processing itself one cannot be a controller for a processing activity for which they cannot determine purposes and means. Conclusion and application to the question This analysis reaffirms my competing answer to the cited answer that it is important to determine who the data controller is. The Fashion ID case shows that is important to perform this analysis on a fairly granular manner, on the level of individual processing activities. For processing on a data subject's computer by a program written by another provider, this means: some processing activities might be solely under the user's control, then they are the sole data controller (or might be exempt from GDPR) for some processing activities, the software developer might decide alone for which purposes and through which means the processing is carried out for other activities, the user and data controller might be joint controllers. This does not require explicit agreement but can result implicitly. This does not require that the software developer has access to the personal data undergoing processing. For example, a spreadsheet application might be used by an end user to process personal data on their own computer (or via a cloud application, with the same conclusions). We can consider different processing activities performed by the software: sorting, transforming, and other processing of the data in the spreadsheet is solely under the end users control, so they are the data controller (if they aren't exempt) collecting usage analytics (where those analytics signals are personal data for which the end user is the data subject) is solely under the software developers control uploading crash reports (where those reports contain personal data from the end user and contain contents from the currently opened spreadsheet) is more complicated. The software developer is definitely a controller. The end user has a dual role here as a data subject and a joint controller (if they aren't exempt) because the crash report processes personal data for which they are the controller.
That GDPR Disclaimer is no protection in some jurisdictions: the applicable laws to that situation in germany for example don't care about the GDPR: Cold calling, mailing, or e-mailing private people to advertise services all is handled by the same law: Without the consent it is expressly illegal under §7 of the law against unfair competition (Gesetz gegen unlauteren Wettbewerb UWG) and such cases are rather Slam-Dunk if the origin can be made out. The punishment can be a 300.000 € fine. The fact that to email someone you need their e-mail address and that e-mail addresses and private addresses are by default considered personally identifiable information is making it worse for the advertizer: Without either an exception (there is none available to cold-emailing) or special allowance of the person the data belongs to, you violate §4 of the federal data protection law (Bundesdatenschutzgesetzes BDSG) just by handling their e-mail address. That's a separate crime from the UWG one, adding up to another 300.000 € fine under §43 BDSG - or even up to 2 years in prison under §44 BDSG! Oh, and if the email does not contain a proper sender's address, that's another chance for a huge fine under the UWG... So, GDPR is your least trouble, if you violate the marketing laws of a country, or their own data privacy laws. A disclaimer means nothing as the act of sending the mail, even to an unintended addressee, is what is illegal and the law as written does not give a damn about 'I didn't want to advertise to that person' when in fact you sent them unwanted advertisements. Oh, and the very repository you suggest? It would violate the very same §4 BDSG and be illegal for processing private data if it was not actively asked to do that by the end user. As a result, that database is useless: It does kick back all people not in its database. Its database is incomplete because only few people give their address to that database as people not aware of the database never add their data on their own. So it regularly violates §4 BDSG with every German citizen's e-mail address it gets and kicks back, and claiming those addresses would be OK, it throws the company trying to check the database under the bus because they rely on data that is impossible to be reliable. tl;dr Don't do cold-(e)-mail marketing. You throw yourself into boiling oil with a lit torch in hand. further reading Other laws banning such behavior I had listed here, and I quote myself: The US has the CAN-SPAM-Act, which illegalizes sending unsocialised advertisements. You may NOT send a mail if any of the following is true: it has no opt-out the email was gained by 'harvesting' contains a header not matching the text contains less than one sentence the adressee does not have any relation to you In fact, you are liable for a 5-digit fine per infringing e-mail in the US. The FTC itself suggests to never buy e-mail lists - as E-mail harvesting or generating any possible e-mail adress itself is illegal.
I don't think you would be responsible for whether your software is used in a GDPR-compliant manner. For GDPR compliance, it is important who the data controller is. The data controller is whoever determines the purposes and means of a personal data processing activity, i.e. the why and how. The data controller alone is responsible for their GDPR compliance. When a data controller wants to run some software, it's the data controller's responsibility to ensure that this software is used in a GDPR-compliant manner (or possibly not at all). Determining purposes and means of processing When someone other than the developer runs a software, the question is who might be a controller: you as the developer, they as the operator, or neither, or both? The operator is clearly a controller: they determine a purpose for data processing (e.g. to manage staff) and have determined means to perform that processing (e.g. to use the software). The developer may or may not be a controller. Clearly, the developer has made choices about how the processing of personal data will be performed, i.e. has determined some means of processing. E.g. the developer has developed a particular architecture, chosen a way to store personal data, and has implemented some security measures. But determining some means is not sufficient to be a data controller, see discussion below. Has the developer participated in determining the purposes of processing? I think this will depend on the specific functionality provided by the software in question. If the software just does what it says and processes the data for the operator's purposes, everything should be fine. If the software also processes data for the developer's purposes, that developer might be a controller. For example, if analytics or crash reports are collected by the developer, that would be a clear indication that the developer would be a (joint) controller. So depending on specific factors, the operator might be the sole controller, or the operator and developer might be joint controllers. Essential vs non-essential means What about the developer determining some means? When does this make the developer a joint controller? The EDPB has created a theory of essential vs non-essential means: 40. As regards the determination of means, a distinction can be made between essential and non-essential means. “Essential means” are traditionally and inherently reserved to the controller. While non-essential means can also be determined by the processor, essential means are to be determined by the controller. “Essential means” are means that are closely linked to the purpose and the scope of the processing, such as the type of personal data which are processed (“which data shall be processed?”), the duration of the processing (“for how long shall they be processed?”), the categories of recipients (“who shall have access to them?”) and the categories of data subjects (“whose personal data are being processed?”). Together with the purpose of processing, the essential means are also closely linked to the question of whether the processing is lawful, necessary and proportionate. “Non-essential means” concern more practical aspects of implementation, such as the choice for a particular type of hard- or software or the detailed security measures which may be left to the processor to decide on. – EDPB guidelines 07/2020 on the concepts of controller and processor in the GDPR, added formatting for legibility Looking through that list of essential means, some might be determined by a software's developer, but I wouldn't expect this to be the case for this kind of open source software. types of personal data: the software certainly sets a framework for processing specific kinds of personal data, e.g. by providing database fields for names, contact details, and schedules. But ultimately, the developer does not control which data is actually collected and filled into those fields – the developer does not cause specific kinds of personal data to be processed with the system. duration of processing: unless the software is programmed with a fixed retention schedule, it should be impossible to argue that the developer has determined the duration of processing. Even then, it would also be the operator who has determined this duration to be appropriate, rather than editing the open-source software to change the duration. But typically, no such retention schedule is enforced, and retention would depend solely on the operator (who can use an admin interface or a database console to erase old records). categories of recipients: typically, the developer does not determine to whom the data in the system will be given. But if the system sends data to third parties by itself, this might change. For example, if the system is pre-configured to store data in an existing cloud database instance, or to a specific analytics server, the developer might be acting as a controller. Here, good software engineering and legal risk minimization coincide. Best practices for web apps state that account credentials and connection strings shouldn't be hardcoded or committed to a repository, and should instead be provided externally (e.g. via environment variables). categories of data subjects: this depends solely on how the software is used. The developer has no way to determine whose data the operator will enter into the system. If the developer isn't a controller, might they be a data processor instead? In a GDPR context, a data processor is whoever processes personal data on behalf of a controller. The developer is clearly not a processor in this scenario because both the “processing” and “on behalf” criteria fail. The developer has no access to the data in the operator's instance, so cannot process the personal data. There is no direct relationship between the developer and the operator. The operator has not delegated authority to the developer so that the developer would be acting “on behalf” of the operator. There is a legal relationship between the two roles (the developer has licensed the software to the operator) but that is entirely irrelevant in a data protection context. The GDPR isn't directly about cookies While the GDPR does cover how personal data can be processed with cookies, the famous “cookie law” is actually separate: those cookie consent requirements stem from EU member state's implementations of the ePrivacy directive. Instead of talking about “controllers”, ePrivacy has concepts such as the “provider of an information society service”. While this role fits perfectly to an operator/provider who runs a web app in a publicly accessible manner, it does not fit a developer who merely makes some source code available. Is the developer even subject to the GDPR? The GDPR can only apply to data controllers and processor who process personal data. As discussed above, the developer is probably not processing personal data at all. Even if the developer were processing personal data, it is questionable if GDPR would apply assuming the developer has no “establishment” in the EU (e.g. an office). Then, the question would be whether those processing activities are either related to offering goods or services to data subjects in Europe, or whether the processing activities involve monitoring the behavior of people who are physically in Europe. Unless the developer is actively targeting European businesses with marketing for this software, the answer is very likely “no”. Could the operator sue the developer for providing software that isn't GDPR-compliant? The operator can sue anyone for any reason, but is probably not going to win. As discussed, the operator is a data controller. They are responsible for ensuring that their purposes and means are GDPR-compliant. That involves selecting suitable software. The data controller would be neglecting their own responsibilities if they just download some random software and start feeding personal data into it. Things might be different if the operator specifically advertises GDPR compliance features but you're not going to do that. It's also worth noting that common open source licenses like the Apache License 2.0 include a warranty and liability disclaimer. To which degree they protect the developer ultimately depends on national laws, but they make it difficult for the operator to make a legal argument that they're entitled to a GDPR-compliant product. See also the related question: Do warranty disclaimers in software licenses carry any legal weight? What can you do? First, don't worry too much. Given how much bad software there is on the internet, surprisingly few developer get into legal trouble for writing source code that's buggy or missing some features. Second, consider choosing a license for your project that includes a reasonable warranty/liability disclaimer. Third, make the state of your project clear in your README file. If someone knows that this is alpha-quality software and that no compliance features were implemented, it's their own fault if they actually use that software.
You probably can't refuse to use such services. The relationship between you and these services is very different when you interact with them as a consumer, versus when these services are provided on behalf of your employer. In the latter case, the service is (or at least should be) bound as a data processor who can only* use your personal data as instructed by the data controller, your employer. Thus, it is your employer who determines for what purposes your data will be used, not the cloud service. Your employer has a legitimate interest in providing a modern and secure productivity suite to its employees, and in requiring you to use such services for efficient communication and collaboration. Of course it would be possible to provide some such services on-premises, but the GDPR doesn't really discriminate between self-hosted and third party services, as long as the third party service is contractually bound as a data processor. To a large degree, this is of course a legal fiction. The cloud services deploy new features all the time, and all that your employer can really do is agree to those changes, including agreeing to new ways for how to process your data. Also, the service provider may act both as a data processor on behalf of your employer for some purposes, but as their own data controller for others. E.g. in Google Workspace (formerly GSuite, formerly Google Apps for Business) Google collects analytics data about how you use their Docs product, and they use it for their own purposes. However, they would only process the document itself as a data processor. This is quite different in the consumer version where Google can use personal data for their own purposes, although within the limits of their privacy policy. Within your work account, you do have some privacy controls, similar to a consumer account. While your employer can set defaults and restrict features, you are not forced to share all data. E.g. in a Google Account, you can “pause” web and app activity (i.e. browsing history) that would otherwise be collected from Chrome browsers while logged in with your work account, or from Android devices that are managed by your employer. This data would potentially be used by Google for Ads, even with a Workspace account (I'm not sure). However, Google Workspace services generally do not feature ads themselves, e.g. the paid Gmail version does not feature ads. The largest real issue with the use of such services by an European employer is the international transfer of data to a non-EU jurisdiction, especially into the U.S. The GDPR offers many alternatives for how such transfers can be protected. In the past, the EU and US had used the Privacy Shield mechanism. However, it was found to be invalid in the 2020 Schrems II ruling, due to concerns about US mass surveillance. Subsequent guidance from supervisory authorities explained that it's not sufficient to use “standard contractual clauses” as an alternative protection, but that additional safeguards have to be implemented, which would effectively deny the personal data to actors in the US. Both Google and Microsoft offer some “data sovereignty” choices that prevent international transfers into the US. However, those have to be configured appropriately by your employer. Thus, instead of asking “can these services be used?” to which the answer is yes, it might be better to ask “is my employer using these services in a compliant manner?”. If you have concerns about such issues, you can contact your employer's data protection officer
Personal data is any information relating to an identifiable person, whether that information is public or not. The student website is definitely processing personal data of faculty. Any website is also necessarily processing personal data of visitors due to technical reasons, even though hosting has been outsourced to a third party. There's always a server, you just might not be managing it yourself. Thus, GDPR applies. Just because it processes personal data doesn't mean that the student website would be illegal. It just means the students are responsible for GDPR compliance of that website. Since the website is controlled by students and not by the university, the university DPO has no say here and the university can't demand the website to be hosted in a particular manner. Nevertheless, the DPO's suggestions might be quite sensible. Typical GDPR compliance steps include: having a clear purpose for which the personal data is being processed having a legal basis for that processing (here, probably a “legitimate interest” which will require a balancing test), see Art 6 providing transparent information to the data subjects providing a privacy notice to website visitors, see Art 13 notifying faculty per the requirements in Art 14 GDPR preparing to fulfill data subject rights such as access, rectification, and erasure when using a legitimate interest, there's also a right to “object” (opt-out) implementing appropriate technical and organizational measures to ensure security and compliance of your processing activities, see Art 24+32 making sure that third parties to which you outsource processing activities are contractually bound as “data processors” to only use the data as instructed by you, see Art 28 if you transfer data to non-European countries, having appropriate safeguards in place Does this sound complicated? It can be complicated. The point is that the internet is no longer the lawless Wild West. Just because you can easily publish a site with personal data, doesn't mean that you should. The GDPR is about requiring data controllers to find an appropriate balance with the rights and interests of the affected persons. Of course there are countries with less regulation, but there are also countries with fewer taxes and that isn't necessarily good for society. The easiest way to avoid these responsibilities will be to stop publishing the site as students – and instead taking up the university DPO's offer to have the university run the site. Which is less fun, of course, but the adult thing to do. If this motivates you further: note that the data controller (the people responsible for the site) must publish their contact information in the privacy notice, typically name + email + street address. The GDPR contains no exceptions that would help here. There is an exception for purely personal or household activities. But if the website would be available to the general public, it would be difficult to argue that this is purely personal. There's also case law such as the Lindqvist case requiring a narrow interpretation of that exception. In Art 9, the GDPR does mention that some restrictions are lifted if the data subject made the information public themselves. But that isn't relevant here, because Art 9 is only about extra-protected sensitive data, e.g. health information, union membership, or sexual orientation.
Since the Steam ID contains or may contain enough information for it to be possible to link your account to you as a physical person, it would definitely be considered "personal data" according to Article 4 of the GDPR. However, by agreeing to the DOTA2 terms of service, you have given consent for them to show your information to other players (or at least that is included in most terms of service I have read for other games. I have not read the one for DOTA2 specifically). Replays are an interesting corner case. If download of replays are only possible for other players or if the wording of the ToS says that you consent to displaying your user ID to anybody, that would mean that they would have covered their bases. As long as they comply with other parts of GDPR, like "the right to erasure" (Article 17) that is. If the API is accessible to anyone and not covered by the ToS you might have a case. If you only want to remove the traceability between you and the replays, you can always evoke Article 17 and delete your account.