GDPR Information and consent I am building a game that stores score/level on the local device and uses non-personalized AdMob. Do I need to inform the user about storing the score locally? Do I need consent for using non-personal AdMob? Do I need to ask for the age? How should I handle kids? Can I disallow a user from using the app if consent is not given?
Do I need to inform the user about storing the score locally? No, there is no need as long as you don't transmit, store or process any personal info. It's doubtful that the score could be considered personal info, but you're not sending it to your servers in any way, so you don't seem to be processing it anyway. Do I need consent for using non-personal AdMob? You have to check this with AdMob, but usually, if it is non-personal, they shouldn't be processing any PI, so you're clear without informing. Do I need to ask for the age? How should I handle kids? Again, you're not processing any PI, so regarding GDPR there isn't any problem. Can I disallow a user from using the app if consent is not given? If you needed consent, no, it would be unlawful to block a user for not giving consent, unless it is impossible to provide the service without it. See recital 43: Consent is presumed not to be freely given if [...] the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance.
The European Convention on Human Rights has an article about privacy (article 8). Note that this is from the Council of Europe, which is not the same as the European Union: non-EU member states such as Russia, Turkey, and Azerbaijan are also part of the Council of Europe and therefore the ECHR. I'm not sure if you first have to go to a lower court, but the European Court of Human Rights is the authority on this (commonly mistaken for the European Court of Justice, but they are distinct entities). According to this ruling of the ECtHR, it is not illegal to monitor your employees' communications per se. However, the monitoring has to be: for legitimate purposes ("the employer had only accessed the account in the sincere belief that it contained only messages of a professional, not personal, nature"), proportionate ("it was the only possible way available"), and communicated to the employee (or, if the monitoring is not announced, at least the restriction on personal use should be communicated, for example through company policy). In the European Union, there is also the GDPR, but this does not change much. It applies to your employer the same as any other organisation and basically says that they have to be reasonable about it: collect only what they need, for a legitimate purpose, and tell you about it. I think you should be able to request a copy of any data they collected about you, ask a human to review an automated decision, and your other usual rights. They don't need your consent to start collecting data, as Esa Jokinen already commented: "GDPR doesn't even require consent to handle PII data, but the consent is just the last option when there's no other legitimate reason to process the data." In fact, your employer probably cannot ask you for consent: because of the employer–employee imbalance of power, the consent would probably not be considered to be freely given (where this article mentions "The GDPR states", I think they are referring to recital 43).
According to my knowledge I am not allowed to share other people's full name nor phone number nor email address without their permission. That is not correct. According to GDPR Article 2: This Regulation applies to the processing of personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system. This Regulation does not apply to the processing of personal data ... ... (c) by a natural person in the course of a purely personal or household activity; GDPR Recital 18 states in relevant part: (2) Personal or household activities could include correspondence and the holding of addresses, or social networking and online activity undertaken within the context of such activities. Personal data that is not processed by &quot;automated means&quot;, for example data which is transmitted verbally, by hand writing, or by manually sent email, is not covered by the GDPR. Data which is used by a natural person for &quot;personal activities&quot; is also not covered. Consulting one's personal lawyer might well be a personal activity unless it is a business matter. Even if such a transfer of data were in scope for the GDPR, consent of the data subject (DS) is not the only available lawful basis. GDPR article 6 permits any of several possible lawful bases to be used, particularly paragraph 1 point (f) which reads: (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Also possibly relevant is point (c) which reads: processing is necessary for compliance with a legal obligation to which the controller is subject; In short, providing one's personal lawyer with the names and addresses of relevant people in connection with a legal issue is not at all likely to be prohibited by the GDPR, nor to require the consent of the people whose names and contact info are provided. However, a comment by user PMF reads: The Data Protection laws are mostly for companies, not for individuals. This is an overstatement. The laws do apply to natural persons as DCs, although enforcement is largely targeted at businesses, particularly large, for-profit businesses.
Nicknames, usernames, or gamer tags are definitely personal data under the GDPR. You are operating under a very narrow definition of “identifying”, which is understandable since the definition of personal data in the GDPR isn't overly enlightening at first glance: […] an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person; — GDPR Art 4(1) However, this definition does show that “identifiable” should be interpreted rather broadly. For example, indirectly identifying data is still identifying data – there doesn't even have to be a strong identifier like a name, passport number, or street address. It is also not necessary that identification enables you to determine the real world identity – identification is anything that allows you to single out a person, or to combine data into a profile of that person (compare Recitals 26 and 30). In any case, an online username or user ID is clearly an identifier and will fall under one of “a name, an identification number, […] an online identifier”. If in doubt, ask your data protection authority for guidance. You've correctly understood that you will need a legal basis to process this data, and that legitimate interest could be that legal basis. This doesn't have to be your own interest, so a community interest would be OK. You need to balance the user's rights against this interest. You have performed this balancing and have found that the interest outweighs these rights. You've noted that such leaderboards are a cultural norm and are generally expected, which strongly weighs in your favour. However, legitimate interest is not a free pass but just means an opt-out solution (right to object per Art 21). You should also inform users that the leaderboard is accessible publicly when they join your server (transparency principle per Art 5(1)(a) as detailed by the information obligations in Art 13). In particular, you should use a “message of the day” or welcome message functionality to link to your privacy policy. You should also be aware that other rights such as the right to access, erasure, and data portability apply. As an alternative to legitimate interest (opt-out) you could also consider consent (opt-in), though this results in slightly different data subject rights and is more difficult to do correctly. But I'd agree that legitimate interest is more appropriate here.
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.
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.
Alice's business sells database management software. Organisations buy or licence the software, deploy it on hardware they control and use the software to help store and, process and analyse 'personal data' within the meaning of GDPR. Alice's business has no access whatsoever to the personal data being stored and processed by those organisations. In respect of that personal data, GDPR is not engaged by Alice's business. The business is neither a 'controller' nor 'processor' of that personal data. Who does the data protection law apply to? - European Commission Who does the UK GDPR apply to? - Information Commissioner's Office
No, a company cannot suspend your GDPR rights – contracts can't override the law. Your rights as a data subject apply as long as your personal data is being processed. However, there is no requirement in the GDPR that they fulfill your data subject rights through a self-service mechanism like a “download my data” button. They can require you to use another support channel. (But Google offers infamously bad support.) In some cases, the service may legitimately decide that they cannot give you access to the data, for example if they believe that you are not the actual data subject (e.g. if they think that you hacked the account). The right to access must not adversely affect other people (Art 15(4)). If they have doubts about your identity, they can require further information to verify you (Art 12(6)). If your requests are excessive or unfounded (if you are spamming them), they can also turn down the requests (Art 12(5)).