Is it legal to ignore &quot;Do Not Track&quot; for data subjects who fall under the GDPR? The "Do Not Track" (DNT) flag is an optional header field in HTTP requests sent by web browsers to web servers. It requests that the website not track the user, or not track the user across different websites (the ambiguity remains unresolved, according to Wikipedia). The GDPR provides a number of lawful bases for processing personal data, one of which is consent. If a website is relying on consent for collecting data about the user, would it therefore be a breach of the law to ignore the user's expressed preference in the form of the DNT flag? I ask because it seems that DNT is widely ignored, at least in the US. As I am in the EU, and have DNT set in my browser, I wonder if anyone who tracks me across the Web is thereby breaking the law.
The GDPR actually does require you to follow DNT in Article 21: In the context of the use of information society services, and notwithstanding Directive 2002/58/EC, the data subject may exercise his or her right to object by automated means using technical specifications. I think this is quite explicit.
As always, it depends. However, it is by no means certain that any public facing hobby project, such as a web app, is exempt from having to comply with the GDPR. Since the GDPR is only a few days old, we have of course no case law based upon the GDPR itself yet. However, when considering this, one should take the following two facts into consideration. 1. The "personal use exeption" in the GDPR is not new. The personal use exemption is unchanged from the article 3(2) of Directive 95/46/EC. (There as a lot of lobbying for removing "purely" from the sentence – but drafters wanted to keep it.) 2. Case-law under the previous regulation restricts the scope of the exception The ECJ has ruled on the scope of the personal use exception in two cases: C-101/01 C-212/13 In both these cases, the ECJ took an extremely restrictive view, and concluded that the personal use exemption did not apply to the processing done by these individuals. In C-101/01 it can be argued that the hobby project as a blogger was connected to the controllers professional activity (she was a catechist in a local church, and blogged about her work. including her colleagues). But in C-212/13, there no such connection to professional or commercial activity. Here, the controller operated a CCTV to protect his home, but set it up to also capture public space, and that was enough for the ECJ to decide that the personal use exception did not apply. Discussion Case-law based upon Directive 95/46/EC is in no way binding for a future court that need to rule based upon the GDPR. We need to wait for case-law decided under the GDPR to be able to have some degree of certainty about the scope of the "private use exception" under GDPR. However, given what we know about how the ECJ has ruled in these cases in the past, I think it is hazardous to think that just because what you are doing on the web is just a "hobby project" not connected to professional or commercial activity, you are exempt from complying with the GDPR. Conclusion IMHO, you may be exempt, or you may not be exempt. I think it really depends on your activity in your hobby project, and to what extent this project processes the personal data of other people than yourself.
Since you are from Europe, GDPR applies to all your processing activities per Art 3(1) GDPR, regardless of where the users are located. If you would like to avoid GDPR compliance, you would have to manage your business from abroad so that you no longer have an European establishment, and would have to avoid offering your services to people who are in Europe. So let's assume that you have no European establishment. Then, GDPR can only apply per Art 3(2) to those processing activities that relate to offering goods or services to people who are in Europe. For determining this, IP-based geolocation is indeed common. Very likely, you do not need consent for this. GDPR does not require consent for everything, just a legal basis. There are six potential legal bases in Art 6(1), though the relevant ones are consent, necessity for performing a contract, legal obligations, and necessity for a legitimate interest. For things like security checks, it would be common to claim a legitimate interest. Complying with GDPR can hurt revenue. However, data subjects have a right to data protection, but you do not have a right to a particular business model. Similarly, paying taxes can &quot;hurt revenue&quot;, but it's not really optional. If your business model can't deal with GDPR compliance (or with taxes), it might not be a sound business model. In Europe, many newspapers have since moved from advertising-only to a consent-or-pay model. That is, the user is given a choice: You can read articles without tracking if you buy a subscription. You can access articles for free if you consent to tracking. The legality of this is hotly debated. In principle, such an approach can be compliant, but the details are problematic, for example that you can only buy subscriptions rather than individual articles, and that these subscriptions are often orders of magnitude more expensive than what would be earned through ads. But this might actually be easier to solve for a mobile application than for a website, due to the availability of in-app payment and micropayment infrastructure. In any case, GDPR limits how much you can &quot;encourage&quot; consent – per Art 7(4), you cannot make access to your service conditional on consent. There must be a way to use your app without consenting to anything, unless that consent is actually necessary for the app to work. For example, consenting to camera access is necessary for a QR code reader app to work. It is extremely unlikely that ads would be necessary in this sense. Users also must not suffer detriment for declining or withdrawing consent. From this, the EDPB has developed the concept of &quot;permissible incentive&quot; in their guidelines on consent. In this post, &quot;Europe&quot; means EU/EEA/UK as appropriate.
The 'right to be forgotten', as currently being applied throughout the European Union (EU), does not come from the General Data Protection Regulation (GDPR), which will come into force 25 May 2018. Rather, the current basis exists in the Data Protection Directive, 95/46/EC, article 12(b): Right of access Member States shall guarantee every data subject the right to obtain from the controller: [...] (b) as appropriate the rectification, erasure or blocking of data the processing of which does not comply with the provisions of this Directive, in particular because of the incomplete or inaccurate nature of the data; This was one of the main points upon which the Court of Justice of the European Union (CJEU) decided Google Spain v Agencia Española de Protección de Datos (AEPD) and Mario Costeja González, the judgement which allowed for individuals to ask for search engines to remove results containing personal data. The CJEU explained that the 'right to be forgotten' was not absolute and should take into account economic considerations as well as other rights (paragraphs 85 - 88). The GDPR, article 17, for purposes of contrast, has a more robust and explicit right of erasure than currently in force: Article 17 Right to erasure (‘right to be forgotten’) The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies: [...] Shortened for clarity GDPR, article 17 fleshes out much of the lack of specifics that the Directive's article 12(b). It should be noted that the UK's Data Protection Act 1998 is a transposition of the Data Protection Directive. This means that the full effect of the rights and obligations in the Directive are contained within the Data Protection Act 1998. Furthermore, the interpretation of the rights and obligations of the Data Protection Directive by the CJEU are highly influential on interpretation of the Data Protection Act 1998. This is due to the European Communities Act 1972, s 3(2) which states: Judicial notice shall be taken of the Treaties, of the Official Journal of the Communities and of any decision of, or expression of opinion by, the European Court on any such question as aforesaid; and the Official Journal shall be admissible as evidence of any instrument or other act thereby communicated of any of the Communities or of any Community institution Even without the above provision, it would be extremely likely that British courts would take into account Google Spain, given that the foundation of the Data Protection Act 1998 is the Data Protection Directive. The most likely outcome is for British courts to uphold the interpretation in Google Spain and allow for data subjects to request removal from search engines. Of course, it is not entirely possible to know without a test case, but it is doubtful any major search engine would attempt to deviate from the current situation as there is currently legal certainty. The Data Protection Act 1998 will still be in force after the future Brexit agreement and is certainly not contingent on continued EU membership. Update The current DPA will be repealed when Brexit comes in to play and will be replaced by a new one. Read more about the new data protection bill on the ICOs web site, which is based on the GDPR with certain derogations and additions.
Update: On 1 October 2019 the CJEU ruled in Case C‑673/17 (Verbraucherzentrale Bundesverband vs. Planet49 GmbH) that cookies require explicit consent regardless of personal data is being processed. (Where the exceptions don't apply). (paragraphs 68-70 of the ruling). That does probably invalidate my answer below. However, because I have based my answer on information provided by the Dutch DPA, I will not update my answer until that DPA has responded on this. Basically, your thoughts are all correct. The Dutch DPA (Autoriteit Persoonsgegevens) has written a manual how to use Google Analytics compliant with the GDPR without having to ask for consent. But unfortunately it is not available in English. Based on Art. 28 GDPR, you need a Data Processing Amendment with google. Open the settings menu from Google Analytics Go to Admin Choose Account Settings Scroll down to the data processing amendment Open it Accept it Click Save Anonymize your visitors IP Address. A full IP address is considered personal data. It is possible to remove the last octet before it is processed by google. Add { ‘anonymize_ip’: true } to the tracking code on your website Create a screenshot of the change, so you can prove later at which date you made this change. Disable Data Sharing with google. By default Google uses the data for 5 different purposes. Each of them would require consent from the visitor of your website. So you need to switch that off. Open the settings menu from Google Analytics Go to Admin Choose Account Settings Scroll down to the data sharing settings Uncheck all checkboxes (Google producs &amp; services, Benchmarking, Technical support, Account specialists and access for sales experts) Click Save Disable Data Collection for Advertising. This has to be disabled at a different location, for the same reason as the previous step. Open the settings menu from Google Analytics Choose Property settings Choose Tracking info Choose Data collection Turn off these two options (remarketing and advertising reporting) Click Save Disable the User-ID feature. This is probably turned off by default. But it is important to keep it turned off. So you need to verify this. Open the settings menu from Google Analytics Choose Property settings Choose Trackinginfo Choose User-ID Disable it Click Save Even though you don't need consent to use Google Analytics, you still need to inform your users, for example by adding a few lines to your privacy policy explaining: You are using Google Analytics cookies. You have a data processing agreement with google. You have enabled IP anonymization/masking. You have disabled data sharing. You are not using any other google services in combination with Google Analytics. The Autoriteit Persoonsgegevens still recommends to offer an opt-out for Google Analytics, but it would not be required. As the Autoriteit Persoonsgegevens is a DPA as defined in chapter 6 of the GDPR, you have to assume their advice really is GDPR complaint. In the past they also had performed other investigations to the privacy policies of google.
In order to process data (which includes storing data), a data controller must establish one or more of the lawful bases contained at Article 6(1) of the UK GDPR. Briefly, those are: a) Consent of the data subject b) Necessary for performance of a contract with the data subject c) Necessary for compliance with a legal obligation d) Necessary to protect vital interests of data subject or another person e) Necessary for public interest or exercise of official authority vested in the controller f) Necessary for controller's legitimate interests Clearly a) and d) don't apply. As you've settled the debt, it seems unlikely to me that b) or f) apply. That leaves c) and e). A common example under c) would be a requirement by Companies House or HMRC to keep accounting records for a certain period of time. Some public bodies may also find it necessary, under e), to retain records which they need to be able to carry out their other functions. It seems highly unlikely to me that either of these would justify retention for your &quot;lifetime&quot; however. I would start by sending them a written demand to have your data erased under Article 17(1). Make sure you also specifically request that they provide you with all the information (and in particular the purposes of the processing) under Article 15(1), and that, in the event that they refuse to erase your data, they explain the reasons why pursuant to Article 12(4). Their response on these points will be helpful in establishing whether there is a lawful basis. Your next step after that is either to complain to the ICO or to apply to court for a compliance order under Section 167 of the Data Protection Act 2018. The former is free while the latter is not and carries risks of cost if you are unsuccessful. If you opt for one of these steps, make sure you cite the relevant provisions of the GDPR and explain why you think there is no lawful basis for the data retention (including by referencing any response you received from them). &quot;I have read GDPR guides on how to request erasure, but I don't really feel this applies- I want to have my account deleted, not the track record of the loan and repayment&quot; It doesn't matter whether we are talking about your account or your track record. What matters is whether the account constitutes personal data, which it almost certainly does, per the definition at Article 4(1): &quot;‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); 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;&quot;
GDPR gives you a lot of flexibility here to choose either DPA. From Art 77: Without prejudice to any other administrative or judicial remedy, every data subject shall have the right to lodge a complaint with a supervisory authority, in particular in the Member State of his or her habitual residence, place of work or place of the alleged infringement if the data subject considers that the processing of personal data relating to him or her infringes this Regulation. However, the DPA from the company's country would be designated the lead supervisory authority for this investigation. If multiple DPAs are involved, they would coordinate with each other. There is no EU body that you could contact directly. But if the different DPAs have a dispute regarding this investigation, the EDPB would provide a consistency mechanism. This mechanism has been used in the past e.g. to force the Irish DPA to correctly apply the GDPR against companies from the Meta group, like WhatsApp and Instagram. Though it might slow things down, it could be advantageous to have multiple DPAs involved, precisely so that the investigation is double-checked. If the lead supervisory authority declines the case, this would also enable the other DPA to do its own investigation. So, it would be a good idea to lodge a complaint with the DPA of your home country, and let it forward the issue to other DPAs as needed. However, contacting the DPA in the company's country would also be fine, especially if you are fluent in the relevant official language, and/or if you live in Ireland.
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.