GDPR - first party analytics cookies Does the first-party issued cookie, under control of, and only accessible by the first party requires visitor consent? Given the conditions bellow: Cookie is used to uniquely identify anonymous visitor (random visitor ID); Cookie is persisted for the duration of the session; Cookie can not (easily) directly be linked to a user (e.g. there is another technical session cookie that stores user ID for authentication purposes, but the two are issued by separate systems, and have no relation except that they are stored in the same browser); Cookie is used to track and relate behavior of the visitor (pages visited, buttons clicked, general behavior stuff. etc.). The most sensitive information I can imagine stored using this identifier would be resolved Country/City, tops (no IP stored). The rest is just usage information related to the website. Data stored with the identifier held by the cookie never leaves first-parties control, it is stored on servers controlled by the site owner. Clearly this all needs to be written down in privacy policy, but do I need explicit consent for such a cookie also? In theory, someone having access to both session cookie and "analytics cookie" could relate the two, but that is highly non-trivial.
The GDPR only require explicit (hard) consent if you use the cookie to store personal data. Given the conditions you cite, the data you store is not personal data, so this cookie does not require consent. In theory, someone having access to both session cookie and "analytics cookie" could relate the two, but that is highly non-trivial. You may have to do DPIA to demonstrate that this is non-trivial, or that you have mitigation in place to mitigate staff abusing such access. But provided things are as you say, the "analytics" cookie does not require consent.
The GDPR does not mandate specific features, but that any processing is lawful and transparent etc. So what would be the purpose of storing a revision history? Once that is clear you can work out an appropriate legal basis (e.g. a legitimate interest) and then figure out which data subject rights apply. For example, let's assume that there is a security interest in keeping a revision history, so that (a) mistaken edits can be rolled back, and (b) the user can be notified of possibly unauthorized changes. This would be a legitimate interest primarily of the account holder, secondarily of you as the system operator. Of course, such security requirements have to be proportional, but I'd see that as given when there's a payment method on file. You are required to apply appropriate safety measures and to apply the data minimization principle. E.g. is it necessary to store this revision history for all eternity? No, one or two months will likely be sufficient. Who should have access to this data? If the purpose is to defend against unauthorized access, it could make sense to only give out this data on request, and otherwise only make it available to support and security staff. Now we can discuss how this interfaces with rectification or deletion. That the user is able to rectify their data themselves is very good. However, that doesn't imply a prohibition on keeping a revision history: the revision history indicates what data was stored at what point in time, and is by definition correct. This assumes that you are not using the revision history for any other purposes. When the legal basis is a legitimate interest, a request for erasure has to be preceded by (or implies) an objection (opt-out) to further processing. The objection must weighed against the legitimate interest: the objection can be denied when there are overriding grounds to continue processing. This might be the case for a security purpose: if someone with unauthorized access can just erase their traces, the purpose cannot be achieved. But perhaps the user could opt out when they create their account? Or opt-out later, but with some delay to still achieve the security purpose at the time of opt-out? In any case, erasure is required when the data is no longer necessary for its purpose – this ties back to picking an appropriate retention period, as discussed above. So it's not really possible to provide a general answer, and it really depends on the specific purpose you are trying to achieve.
From the GDPR's definitions: ‘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; This blurred image would be &quot;information relating to an identified ... natural person (‘data subject’).&quot; It does not matter whether the person can be identified using the information in question. Therefore, the answer to your question Under GDPR, does blurhash of a profile picture count as personal data is yes.
For land ownership records and other similar scenarios such as business directors, the requirement for these to be public will be in legislation rather than a contract - this provides the legal basis, see GDPR Article 6(1c). Additionally when government departments are doing it they also have 6(1e) as lawful basis: "1. Processing shall be lawful only if and to the extent that at least one of the following applies: ... (c) processing is necessary for compliance with a legal obligation to which the controller is subject; ... (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;" -- GDPR, Article 6(1c,e). I'm not familiar enough with the specific legislation that will apply here but pretty sure this will be the case, and having said this you may well find public registries also become less public going forward. The reason ICANN has come under fire, is partly because under GDPR privacy is a protected fundamental right and therefore to comply personal data should be kept private by default and privacy never something you would be required to pay extra for. Any contract ICANN have in place with their registrars will not override legislation, it is in fact the other way around. "2. The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons." -- GDPR, Article 25(2). This doesn't stop ICANN from maintaining a register of domain name owners (registrants), but it does mean they can't just publish all records upon request to anyone anymore - whether people will be granted access to personal data will now depend on if they have a lawful basis for this, and in these cases their processing of the personal data will be limited to those purposes. Being nosey doesn't count! "When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of the contract." -- GDPR, Article 7 (4) - Conditions for consent. What this means essentially, is that if the consent is conditional for the contract it will not be treated as freely given, and therefore not valid - it will no longer be acceptable to contractually bind the provision of a product or service with consent to publish personal data or any other form of processing such as marketing mailing lists. Looking now at the specific points you have raised: "GDPR article 6 allows for processing of personal data on a contractual basis (section 1b)" Whilst this is true, this is only part of it - it doesn't allow for unlimited processing for any purpose and sharing it with any people, if you look at Article 5(b) it states that the information is collected for specific explicit legitimate purposes. Each purpose requires its own legal basis and needs to be compatible with the principles of GDPR. Without consent, ICANN currently does not have a legal basis to make the WHOIS records public for EU citizens and should have adopted some technical controls to require them to opt-in if they wish to be included in the public register. They're coming under fire for non-compliance having been given 2 years to prepare and change their systems/processes. "processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;" Again whilst this is true, not all processing is necessary for the performance of a contract. In the same way people must give consent to receive marketing communications, they must freely give consent for their information to be shared/published (separate to the contract for provision of service) in the absence of other lawful basis for this processing. "Also section 1c, processing is necessary for compliance with a legal obligation to which the controller is subject;" There is no legislation which requires them to publish the personal data of domain name registrants. In this paragraph 'legal obligations' refers to those required by legislation (i.e. statutory obligations), not contracts (or non-statutory obligations) which are covered under Article 6(1b). "And finally section 1e, processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;" ICANN has no official government-assigned authority, and publishing the personal data globally is not in the interests of the data subject's or others' welfare or well-being - this is what is meant by 'public interest'. As far as I can see what ICANN are actually doing to comply seems to be accepted by the European Data Protection Board, they are only 'under fire' as you say because they are late in doing so. The deadline was 25th May 2018 and they had 2 years to prepare like all other organisations.
The ePrivacy Directive Cookies are governed in the EU by the ePrivacy Directive which was first passed in 2002, and revised in 2009. However, if a site places a cookie, and later reads the cookie and stores an indication of the cookie content, this may be personal information and thus also subject to GDPR rules. (Other privacy laws, such as the CCPA, may also impose requirements on cookie use, when they apply.) Note that the so-called &quot;EU cookie law&quot; is a directive and not a regulation. This means that it is up to the various EU countries to implement it in their national legislation, and different countries may implement it in different ways. It would be the actual laws in individual EU countries that would be binding on website operators, and I am not going to try to find and analyze all the various laws on the topic. Paragraph 25 of the directive (linked above) reads: However, such devices, for instance so-called &quot;cookies&quot;, can be a legitimate and useful tool, for example, in analysing the effectiveness of website design and advertising, and in verifying the identity of users engaged in on-line transactions. Where such devices, for instance cookies, are intended for a legitimate purpose, such as to facilitate the provision of information society services, their use should be allowed on condition that users are provided with clear and precise information in accordance with Directive 95/46/EC about the purposes of cookies or similar devices so as to ensure that users are made aware of information being placed on the terminal equipment they are using. Users should have the opportunity to refuse to have a cookie or similar device stored on their terminal equipment. This is particularly important where users other than the original user have access to the terminal equipment and thereby to any data containing privacy-sensitive information stored on such equipment. Information and the right to refuse may be offered once for the use of various devices to be installed on the user's terminal equipment during the same connection and also covering any further use that may be made of those devices during subsequent connections. The methods for giving information, offering a right to refuse or requesting consent should be made as user-friendly as possible. Access to specific website content may still be made conditional on the well-informed acceptance of a cookie or similar device, if it is used for a legitimate purpose. This should mean, if implemented straightforwardly, that cookies, beyond those absolutely essential to the operation of a site, can only be placed if a user is notified of the intention to place them, and freely consents. This can be done once per user, on an initial session. Users are supposed to be provided with provided with &quot;clear and precise information&quot;. I do not think a simple statement that the site uses cookies fulfills this. At the very least the purposes for which cookies will be used should be provided. The directive does not make clear what level of detail about individual cookies such a notice must provide. The notice described in the question neither describes the purpose of cookie placement, nor does it offer any meaningful choice to accept or reject them. As such, I do not think it would be compliant with the directive. If cookies are read back (which is after all pretty much the point of having them) and can be potentially identified with an individual, then under the GDPR (article 6) there must be a lawful basis for processing them, and the interaction above would not be enough to establish consent as a lawful basis. There might be some other basis that does not require consent, however. Interpretations from others This page from cookiebot explains some of the history of the directive, and how it contrasts with the GDPR (which is a regulation, and so is directly applicable without the action of national legislatures). This page from The Verge discusses recent changes in the directive and the guidelines for applying it, and criticizes how it has been complied with, and ignored, by many sites. Cookies and the GDPR This page, &quot;GDPR, and the ePrivacy Directive&quot;, from GDPR.EU says: ... cookies, insofar as they are used to identify users, qualify as personal data and are therefore subject to the GDPR. Companies do have a right to process their users’ data as long as they receive consent or if they have a legitimate interest. Passed in the 2002 and amended in 2009, the ePrivacy Directive (EPD) has become known as the “cookie law” since its most notable effect was the proliferation of cookie consent pop-ups after it was passed. It supplements (and in some cases, overrides) the GDPR, addressing crucial aspects about the confidentiality of electronic communications and the tracking of Internet users more broadly. To comply with the regulations governing cookies under the GDPR and the ePrivacy Directive you must: Receive users’ consent before you use any cookies except strictly necessary cookies. Provide accurate and specific information about the data each cookie tracks and its purpose in plain language before consent is received. Document and store consent received from users. Allow users to access your service even if they refuse to allow the use of certain cookies Make it as easy for users to withdraw their consent as it was for them to give their consent in the first place. That page also describes the proposed ePrivacy Regulation which, if passed, will replace the current directive, and links to drafts of it. Conclusion The site described in the question probably does not comply with legislation implementing the ePrivacy directive. Depending on where it is hosted and targeted, and what it does with cookies that it sets, it may fail to comply with the GDPR as well. There has been very little enforcement of the directive so far. This may change in the future, particularly if it is replaced by a regulation, as has been proposed.
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.
Yes, you can use such eye tracking if you obtain consent in a suitable manner. But obtaining consent is going to be very difficult for you. The processing activity in question occurs within the context of an EU establishment of the data controller. Thus, GDPR applies regardless of where the data subjects are located. Under GDPR, any processing activity needs a clear purpose and a legal basis. Typical legal bases are necessity for performing a contract with the data subject, legal obligations, a legitimate interest, or consent. Conditions for consent are listed in Art 7 GDPR. Once your have a purpose that is covered by a legal basis, you can collect the minimum data necessary to achieve the purpose. For example, let's assume that the purpose is a scientific study for which gaze tracking is necessary. The study's subjects can be informed about the context of the study, about how the data will be used, and can then be asked for consent for proceeding. Of course, participation in the study is only possible when consent is given. This is perfectly fine as far as the GDPR is concerned. But things might be more difficult when data is used for a different purpose, for example in order to track user interests in a web shop. You do have a legitimate interest in optimizing the website, but this interest likely doesn't outweigh the user's privacy interests. Legitimate interest always requires a careful balancing test. If the user cannot reasonably expect the data collection to happen, that is an indication that consent would be a better legal basis than legitimate interest. Accessing a camera feed means accessing information stored on the end user's device. Per the ePrivacy directive, this requires consent regardless of whether the information in question is personal data. Cookies, mouse pointer tracking, or eye tracking with a camera are all equivalent in this regard. Consent must be specific, informed, and freely given. It is an unambiguous indication of the data subject's wishes, and must involve some clear statement or affirmative action. Prior to starting the eye tracking, you must provide sufficient information about what is happening, and must make it possible to easily decline consent. You cannot bundle unrelated consent together (e.g. eye tracking consent + cookie consent). You cannot make access to a service conditional on unrelated consent. E.g. a web shop does not need camera access, but an augmented reality does. Still, consent must be specific so consent for AR purposes can probably not be used to authorize eye tracking, which might need separate consent. Browsers do not grant camera access by default, and instead show a permission dialogue where the user can allow access or block further requests. This permission dialogue cannot replace your compliance obligations such as providing the necessary information so that the user can make an informed choice. Since GDPR requires that consent is freely given and can be declined, you might find it difficult to convince anyone to give consent to this fairly invasive tracking procedure. You might be able to incentivize consent e.g. with small discounts on a web shop, but the incentive must remain small enough that there really is a free choice between giving or declining consent. The EDPB has issued guidelines that are relevant to your scenario. These guidelines are not law, but are well-reasoned official interpretations that are frequently cited by courts. Guidelines 05/2020 on consent Guidelines 3/2019 on processing of personal data through video devices Practically speaking, I doubt you will find eye tracking to be useful. First, you can likely achieve your purposes through less invasive means. Recall that the GDPR only allows you to process the minimum data necessary to achieve a purpose. Second, eye tracking is difficult for technical reasons. Bad lighting and weird angles make it difficult to obtain a useful feed. Cameras might be in different positions relative to the browser window, so that the eye tracking would have to be calibrated before acquiring data. Eye tracking typically involves processing the video feed on the user's device, but this is computationally expensive that will make the website unusable on lower-end devices, in particular mobile devices. And of course, many PCs don't have a camera in the first place.
This depends on the context – GDPR rarely restricts the use of specific kinds of data (see Art 9) but instead regulates the processing of this data, and the purposes for which it is processed. Personal data is any information relating to an identifiable person (Art 4(1)). So to show that some information is not personal data, you must show either that it doesn't relate to the identifiable person, or that it's not possible to identify the person. Whether a person is identifiable depends on the means of identification that are reasonably likely to be used, taking into account the cost and effort of these means (Recital 26). This recital also mentions that singling out a person is a kind of identification. If you have lots of birthdays so that there are no unique birthdays, or if the birthdays are stored without contextual information that would allow identification, this can indicate that it's not personal data. Some examples to illustrate my views: Scenario 1: you are collecting statistical data in a shopping mall and are collecting birthdays from passer-bys, without any additional information. This information is anonymous and not personal data, since you have no reasonable means to identify the persons. Scenario 2: in an office, there's a publicly visible calendar on the wall with the birthdays of all staff members. However, the calendar doesn't say whose birthday it is. This information is likely personal data, since it's reasonably possible to infer the correct person based on contextual information. At least HR would also have the birthday for all staff members on file, so that the company clearly has the means to identify anyone. (This doesn't mean such a public calendar is illegal, just that there must be a legal basis.) It is more difficult to determine whether information also relates to an identifiable person, i.e. whether this information is about that person. This depends not just on what the information is, but how the information is used. AFAIK there has yet to be EU-wide guidance by the EDBP, but the ICO has listed some hints. I think that a birthday of an identifiable person will almost always relate to that person.