Using AI to identify similar browsing pattern I understand that storing any hash or IP that can identify &quot;user uniquely&quot; is against GDPR. I am planning to use user browsing patterns to see if a similar or the same user had previously visited the website. (Scroll pattern/click frequency and so on.) There will not be any hardware related information saved or any cookie saved on the client side, just the pages visited and &quot;way&quot; a user navigated the website. Is such a method GDPR compliant?
I understand that storing any hash or IP that can identify &quot;user uniquely&quot; is against GDPR. That is not correct. However any data which is identifiably associated with a an individual human, including any data which could be used to identify that human, is generally &quot;Personal data&quot;, and may not be processed (which includes storing it) without a lawful basis, if the GDPR applies. Any of the six lawful bases allowed by the GDPR may be used, including consent, and the legitimate interest of the data controller. The GDPR does not generally specify that particular technological solutions are permitted or forbidden. If this usage pattern could reasonably be used to identify a particular person, or to single out a person from among a group of people, it is probably personal data, and a lawful basis would be required. Otherwise, not. As for whether such a person is &quot;identifiable&quot; if use of this technique permits the Data Controller to identify two visits at separate times as having been made by the same person, when the later visit is still in progress or is recent, the IP for that visit will still be available, and thus could be associated with the first visit as well. And even if that is not done, such a technique could permit building a profile of such a person, including the actions taken on different visits. I think that would be enough to make this &quot;personal data&quot;.
Whether GDPR applies does not depend on the country of residence. Instead, GDPR applies to a non-EU site or service if the data controller offers products or services to people in the EU (see Art 3(2) GDPR). This depends solely on the behaviour and intent of the data controller / the provider of the website – compare also the discussion of the “targeting criterion” in EDPB guidelines 3/2018 on the territorial scope of the GDPR. While your proposed measures might not be entirely ineffective (in that they document an intent to not serve people in the EU), they are both unnecessarily restrictive and overly lax. For example, they would unnecessarily prevent EU tourists in the US from registering but would nevertheless allow US tourists in the EU. For the targeting criterion, it matters whether the data subject is in the EU at the time of the offer, not at all what their residency is. Even if a person who is currently in the EU registers with your service, that doesn't necessarily mean that you are targeting people in the EU. Instead of implementing signup restrictions, a better strategy might be to clarify in the copy on your website that you are only targeting the domestic US market, not the European market with your services. I have discussed this in more detail in an answer to “How can you block GDPR users from US based sites?” If you have a site where GDPR doesn't apply, and you receive a GDPR data subject request, you shouldn't deny it on the basis that the user must have lied – instead you can deny it on the basis that GDPR just doesn't apply to you.
Obtaining consent for cookies is not required by the GDPR at all. Instead it is covered by the e-privacy directive, which as a directive rather than a regulation, must be implements by specific legislation in each individual country. The exact requirements vary with the law of each country. An e-privacy regulation has been proposed, which would have scope similar to the GDPR, would replace the Directive, and would not require national implementing legislation. However it has not yet been adopted. Proposed versions have significantly different requirements than the current Directive. Nor does the GDPR require consent for advertising that does not involve the processing of personal information, unlike some other privacy laws such as the California CCPA. However, if the Google package sets cookies without consent that are not strictly necessary for operation of the web site, it might well fail compliance with some of those national laws implementing e-privacy. Also, even necessary cookies must be disclosed to the user, as I understand it, possibly only in general terms. Several national Data Protection agencies have said that cookie compliance is not a major priority, at least not until an e-privacy regulation is in place. But that does not mean that lack of compliance is legal. Unfortunately I see no way for a developer using the Google package to correct this issue within the package. One would either have to implement a different solution, or trust that Google will fix this before enforcement becomes a serious issue. However, the app developer could add a separate general cookie consent banner, and turn off all adds if consent is not given, I believe.
Yes such a username would be personal data. It is information that relates to an identifiable person. In this context,a person isn't identifiable only if you can infer their real-world identity, but already if you can single out one person's records. Thus, your random IDs and any linked information would be personal data as well. Just because something is personal data doesn't mean that processing it is illegal. It just means you need a legal basis. That could be necessity for performing a contract with the data subject (like saving game progress), a legitimate interest, or consent. Taking into account GDPR principles like &quot;data protection by design and by default&quot;, it could be sensible to hide a players stats from the leaderboard until they give consent. On the other hand, you may have a legitimate interest to provide leaderboard data for ranking/comparison, especially if the leaderboard entries are pseudonymized. In any case, it should be clear to the users which information is visible to others.
The university has a legal obligation to collect certain data from attendees, including employees an visitors. It has decided to keep these records in digital form, and offers a smartphone app as a convenience. The university has outsourced the data processing activity to a third party. This is perfectly legal under the GDPR, if that third party is contractually bound to only process the data as instructed, and not for their own purposes. Whereas the university acts as a data controller (Verantwortlicher), the third party would be a data processor (Auftragsverarbeiter). I have some doubts though whether an app or a website is indeed the solution that offers the best data protection, especially taking into account the GDPR's data minimization principle. Requiring updates when entering or leaving any room is potentially excessive. Given the sensitivity of the data, the university should have performed a data protection impact assessment to weigh the consequences of this measure. At least for employees, the measure would likely have to be approved by the union (Personalrat) as well.
If you are concerned with a digital thing being verifiable as exactly the same at some later time you ought to use a hash. A hash function takes some input bits like say a digital video and produces output bits often represented as hexadecimals. For any particular input it will always have the same output, but it is not reasonable for more than one input to have the same output. All modern computers have standard software to do this and I'm sure many websites offer it as a free service.
From Article 4 of the GDPR: ‘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; The fact that you can use the ID in your database, along with the value returned by the cookie you set to identify the user makes it personal data. The favorite colour is information relating to an individual. The fact that it is connected to the cookie ID means that it is personal data.
Term 1 isn't going to hold up, but that is not a GDPR matter. It's just a matter of basic consumer protection law in the EU. You can't offload responsibility for your mistakes. Looking at 2, Dale M. already pointer out that it's now how the GDPR works. You are the Data Controller. X,Y and Z are Data Processors. Article 28(1) of the GDPR is in direct conflict with your disclaimer. You accept zero responsibility, the GDPR says you are fully responsible. That's the exact opposite.