The Data ownership for an automated server running for years prior to GDPR Regulations Let's go back to the early 2010's. A group of researchers get together to build a collaborative data repository. A server is set up to receive data for aggregation and processing from various nationwide medical centers collecting survey data. This server is automated to receive and transmit data to/from servers at certain times using crontab jobs. If you're no computer expert, you can think of this like an alarm-trigger which will run a certain job without any human intervention at certain times in a day/month, provided that the device is powered on and is not blocked off from hardware resources. So in theory, this server could continue to run the same jobs for decades to come, with no human ever interacting with the device itself. Now, a number of studies are conducted using data collected by this server, over the course of the next few years, with scrupulous adherence to any and all red tape. Ethics committees, patient concerns, you name it! Such was the case until about 2016 when the researchers who were using the system diverted their attention to other projects for a time. Unfortunately for those researchers, this was also around the time that the GDPR was passed, bringing a lot of new requirements that data owners/controllers have to adhere to. The year is now 2021, and the researchers find themselves under investigation for allegedly having breached data regulations. But interestingly there has been no action on the part of these researchers for years! The machine-scheduled data collection/transmission jobs have continued to run all this time, but there has not been any update to this data in years. If anything, a good portion of the code has been commented out; so the network requests aren't really doing anything besides establishing connections. The data did follow an anonymization rule. But the biggest issue this research group now faces, is that they are not able to determine who controls the data. Remember, this system has been self-automated in the confines of a university room for ages. And since it was a collaborative project, the person heading the data was designated only informally, from time to time. And without having ever appointed an official data controller, they find themselves in a difficult position, unable to point to an authority or entity responsible for the data. I understand that these researchers are (likely) immune from retroactive prosecution, but can anyone here tell me how the researchers can hope to build a case in their defense, when the prosecution expects of them to fulfill roles which had never been appointed?
There are a number of misconceptions in this question. Firstly, the regulatory environment did not drastically change when the GDPR came into force in 2018. Previously, each EU member state had its own laws implementing the 95/46/EC Data Protection Directive. The GDPR harmonizes these laws, and replaces them with a single EU-wide law. However, the GDPR is largely identical with the DPD. In particular, both laws have the same definition of a controller. Secondly, the data controller is not a position to be designated, like a Data Protection Officer would be. A controller is whoever – alone or jointly with others – determines the purposes and means of processing of personal data. Whether someone can decide the purposes of processing is a matter of fact, not a matter of formalities. There can be more than one controller. Most likely, the institution hosting the research group is the controller. For individual researchers, the important aspect would be to demonstrate that they've fully complied with their institution's procedures at all times – that they acted as agents of the controller, not as controllers of their own. The institution might have a more difficult time mounting the defense if its technical and organizational measures were inadequate. For example, keeping an unattended server running for five years without security updates borders on gross negligence – so there should have been a procedure so that each system has a clear point of contact who is responsible for administrating the system. The controller should also have inventoried its systems and processing activities at the latest in preparation of GDPR, e.g. for an Art 30 record of processing activities. Your question suggests that no one could be at fault because no one did anything, but inaction and failure to fulfil responsibilities can also be a violation of law. If the institution wasn't convinced that this server was GDPR-compliant, the correct approach would have been to shut the server down, not to continue the processing of personal data. Of course, the controller may be able to demonstrate that this breach of GDPR was very minor, for example because the personal data was pseudonymized and because other technical measures (like firewalls) would have prevented unauthorized access.
The critical part is the nature of the relationship between you, the website provider, and the provider of the material you embed. If the embed-provider acts as your data processor, then things are generally fine. The GDPR does not really distinguish between personal data processing activities that you perform yourself versus activities that you've outsourced to third parties. However, you would remain responsible for compliance. This also means that per Art 28 GDPR, you will need a contract with that embed-provider (sometimes called a “Data Processing Agreement”, DPA). This contract stipulates that the processor will only use the personal data as instructed by you, but not for their own purposes. With the Google Fonts case, it must be highlighted that Google does not act as a processor for this service. Google does not offer a DPA that covers the Fonts CDN. While Google promises that it doesn't use the personal data collected in this context in any nefarious way, there are zero contractual guarantees for website providers. So we have to consider the scenario when the embed-provider is an independent data controller. We as the website provider have no control over what the embed-provider does with the collected data, our control only extends to whether or not we cause the website to disclose data to that third party. But this is still processing as personal data (see also the CJEU Fashion ID case), and we need a legal basis for this data sharing. In the Google Fonts case, the court in Munich found that there was no legal basis for using Google's CDN. There was no consent, no contractual necessity, and no necessity for a legitimate interest. After all, these fonts could all be self-hosted. (Technical remark: and given how modern browsers enforce cache isolation and provide HTTP/2, serving fonts from your main domain is probably faster anyway). Consent management services will typically act as your data processor. You don't need a legal basis for “sharing” data with them, because the processing remains under your control. As far as the GDPR is concerned, loading a script from your processor's servers is equivalent to loading a script from your own servers (which you're probably hosting via a another data processor anyway). Sometimes, the necessary data processing agreement is already part of the standard terms of service, sometimes it's a separate document that has to be signed. Figuring this out is your responsibility as the data controller, before deploying the service. Art 6 GDPR doesn't say that you always need consent. It says that you need a legal basis, for which paragraph 1 enumerates six choices. For a lot of use cases, a “legitimate interest” will be appropriate, though it requires a balancing test. Sometimes, other laws mandate that you use a particular legal basis. For example, the ePrivacy Directive says that you must get GDPR-consent when accessing or storing information on the user's device (such as cookies), unless that access/storage is strictly necessary to provide a service explicitly requested by the user.
Not going to hold up. Dutch Supreme Court confirmed 2012-09-21 in LJN BW6135 that arbitration is still covered by the the right to an independent judge, as established in Golder v UK, ECHR 1975-02-21, nr. 4451/70. Stack Exchange can't decide the rules themselves. (The Dutch case confirms that sector-wide arbitration is in fact legal, with regard to a standard arbitration clause commonly used in the Dutch building sector. The arbiter was found to be independent in that case precisely because they weren't picked by the builder involved.) The GDPR is only indirectly relevant, but the fact that it's mentioned does mean that there is an indisputable intent to provide services to EU consumers. (See section 23 of the GDPR, or its national equivalents). As such, you can't hide behind a US business address. If you intend to do business in the EU, it's under EU laws - all of them. You can't say that only the GDPR applies, and not other rules. I'm having a bit of a problem finding a source, but I'm fairly confident that consumers have the right to sue at their own, local court, overruling the default of suing in the court where the counterparty is located. Finally, I have the right under national law (Dutch: BW 6:236 start and sub-n) to strike the arbitration clause up to 30 days after the conflict arises, and demand a court decision. That's not 30 days after I accept the "Public Network Terms", that's 30 days after the arbitration is invoked. Dutch law explicitly allows arbitration abroad, and arbiters may apply foreign law, but as written the arbitration clause has no legal basis in the Netherlands, and any arbitration resolution would therefore not be considered valid. You may wonder if it matters to Stack Exchange that the arbitration decision would not hold in the EU. Well, consider a clause like Indemnification, which demands the user indemnifies Stack Exchange. That's a pretty empty demand if it's not enforceable.
Please note that Google Analytics do not anonymize the data you collect on its behalf unless you configure it to do IP-anonymization. If you use Google Analytics and do not use this feature, you need to have a DPA (Data Processing Addendum) in place with Google in order to comply with the GDPR. This is a real hassle, so unless you absolutely need fine-grained demographic data, it is strongly recommended that you use IP-anonymization. According to our data protection supervisory authority, this is sufficient to comply with the GDPR vis-a-vis Google Analytics. Does data that is anonymized need to be collect in the event of a GDPR Subject Access Request? No. But as the controller, you need to make sure that is is anonymized.
You quoted the definition of personal data from Art 4(1) GDPR. This definition of identifiability is further explained in Recital 26: […] To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. […] If the user ID is unique, then the hashed user ID will be unique as well. Thus, the hashed ID will enable “singling out”, and would still count as identifying in the sense of the GDPR. You also claim that there's no way to reverse the hash. This is not quite correct. Assuming that the hash function itself is secure, then the only way to crack the hash is to brute-force the input. The difficulty of brute-forcing depends only on the entropy of the input data, not on the size of the output hash. It is thus comparatively easy to crack hashes of short low-entropy strings like sequential integer user IDs, IPv4 addresses, or weak passwords. In contrast, it would be difficult to crack long random user IDs, such as UUID version 4 identifiers created from a cryptographically secure RNG (CSPRNG). Even if the hashes can't be cracked, they are not anonymous – you can link them to the original user ID, after all. The GDPR only considers data anonymized if there are no “reasonably likely” means to re-identify the data subject. If this de-identification is reversible, it's called pseudonymization instead. If storage allows, a better technique to generate pseudonymous IDs is to create a table that maps the true ID to a CSPRNG-random ID. Unlike a hash, the random ID cannot leak extra information about the original ID. This pseudonymization technique could perhaps also be turned into irreversible anonymization by deleting the ID mapping, assuming that no “singling out” can happen. Pseudonymization is a very good security measure. It is explicitly mandated whenever appropriate in Art 32 GDPR. So you should probably use it. It's just that GDPR continues to fully apply to processing of the pseudonymized data. Since the pseudonymized data is the data subject's personal data, you may be required to delete it when receiving an Art 17 request for erasure. You may also be required to forward the request to others with whom you shared the data. However, the right to erasure has many conditions and exceptions. If you actually need to keep the data for a particular purpose, chances are good that you can keep it.
I think that one cannot answer a question such as "Will the personal use exception in the GDPR apply to personal blogs?", because it is unclear if you refer to: personal information published on the blog pages personal information collected from the Website, by way of forms, cookies, server logs, strictly collected and processed for the purpose of operating the Website for your own personal purposes as a blogger (by yourself of through a subcontractor in the sense of GDPR) and not personal information collected from the Website's operation, transferred or provided to third parties for their own purposes (this would include cookies used to identify and track users across multiple domains) Regarding 1., a personal blog wanting to benefit from the exemption should not publish third party's personal information without their consent or another legal basis, and C-101/01 certainly applies here. About 2., if the information is strictly collected and used for the own personal purpose of the operation of the blog, I would tend to agree that it should benefit from the exemption. I feel that C-212/13 would not necessarily be an indication that because the blog is publicly accessible it is then "directed outwards from the private setting" in the sense of this ruling, and should not be considered as "purely ‘personal or household’ activity". C-212/13 case was relating to a camera installed by an individual on his family home for its own security purposes which was also monitoring a public space. The persons filmed on this public space had absolutely no direct connexion with the person collecting their images. In case of a blog, the visitors of the blog interact with the blog for fulfilling the own personal purpose of the operation of the blog of the publisher of the blog. Another argument is given by the Recital 18 which you quote: a personal blog can be viewed as a type of social networking or related online activity. Finally, about 3., there is no doubt for me that, in this case, the publisher of the blog is engaged in an activity which is not personal, since it willingly provides personal information to third parties which they use for their own purposes (and not as subcontractors in the sense of GDPR). There may be other approaches apart from these 3, but that's a start for your considerations.
By itself, a chess position is not personal data. Personal data is “any information relating to an … identifiable natural person”. Since the file in question includes the name of the opponent, it is clearly personal data about the opponent. If the files are used for “purely personal or household purposes”, the GDPR won't apply per Art 2(2)(c). If the files are shared more widely – especially if the files are published – then GDPR becomes relevant. The person/entity who is data controller has to consider GDPR compliance. Data controller is whoever determines the purposes and means of processing of personal data (the “why” and “how”). The first question would be under which legal basis this personal data about another person can be shared. The GDPR offers multiple legal basis, notably “legitimate interests” and “consent”. Consent is always an option, but must be freely given (entirely voluntary). Legitimate interests can serve as a legal basis after a balancing test between your interests and the data subject's rights and interests. This balancing test also depends on the reasonable expectations of the data subject, which in turn depends on the more general context. For example, in a chess community where such sharing is completely normal there would likely be a legitimate interest for you to share games as well, if the games occurred in the context of this community. But if you play a game with a friend who is not part of this community, the friend cannot reasonably expect that their name and associated personal data would be shared. The second question would be how you would satisfy further GDPR compliance obligation, in particular the Art 13/Art 14 right to information. When collecting personal data, it is necessary to provide certain information such as your identity, what processing is being carried out, and how the data subject can invoke their GDPR rights (a privacy notice or privacy policy). This might be difficult or awkward to do. Practical solutions to these problems: If you want to share a game but aren't sure that the opponent is OK with this, remove identifying aspects such as names. For example, you could crop a screenshot, or describe the game in textual notation without listing the opponent's name. Play the game via a chess website that publishes the game. This way, the website is the data controller, and you and the opponent are the data subjects. This avoids having to act as the data controller yourself. This might work for private interactions, but not e.g. if you run a chess club and require members to play via that website – you might still be in a data controller role then and have full compliance obligations.
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.