GDPR and CDN (content delivery networks) I have a website hosted in a European server. The website is static (serverless) so I can take advantage of a CDN to serve its whole content. A CDN is, basically, a distributed network of servers. That means that a copy of my website would be hosted on several servers around the world. User requests are (ideally) directed to the server which is closest to the user. By doing so, a CDN improves the performance of the site. How is this relevant concerning the GDPR? By using a CDN I'm adding to the system a new third-party that will collect the IP and other metadata from my users. Obviously I can't get consent from the user beforehand: when they hit the server it is already too late. Probably, users will get routed to a server close to them, but this is not guaranteed. I don't know to which server they are going to connect. I don't even know the country. It could be that a German user end up sending his IP, browser footprint, etc. to a server in Japan (unlikely but possible). Because I don't know it, I can't inform the user about it. My assumptions are: Without CDN, the hosting provider would collect that same data so I don't think there is a relevant difference. I just need to inform my users in the privacy policy which CDN provider I use and that it collects personal data on the basis of legitimate interests (Art.6(1)(f)), as I do with the hosting provider. Because there is a potential transfer of personal data out of the EU, I must ensure that the DPA that I sign with the CDN provider includes the SCC. Also, I must inform the users about this possible data transfer in my privacy policy. Are my assumptions correct? Is there, in the frame of the GDPR, any other aspect to take in consideration when using a CDN?
Are my assumptions correct? Yes, this is precisely the sort of thing that would fall under the purview of "the purposes of the legitimate interests pursued by the controller or by a third party", as it fundamentally enables you to deliver the service to the data subject, and its also difficult to argue that "such interests are overridden by the interests or fundamental rights and freedoms of the data subject" given its a fundamental part of delivering the service before any consent can be given. Its not the intention of the GDPR to solely require a direct relationship between the data controller and data subject, its intention is to allow the data subject to control more of the relationship than they did previously - in some cases, that control remains with the data controller, which is why not all of the lawful basis for processing rest on consent. So long as you ensure that the CDN provider has a relevant privacy policy and is identified as a data processor in your privacy and data policy then you are good to go. In my mind, this is similar to the issue of how the data subjects packets get to you from their computer - we aren't including all of the network providers who carry the packets between the data subject and the processor (despite the fact that those providers will have access to much of the same information as the CDN, such as IP address, source, destination etc), even though in many cases we don't know that information (for example which route it will take over the internet). The only difference here is that as the data controller, you know about the CDN and can include it in your policies, so you should.
The territorial scope of the GDPR is defined in Article 3. It covers "personal data of data subjects who are in the Union", whether they are EU citizens or not. So to answer your questions: 1) are EU users, but moved to USA a few years ago, and signed-up on my website? They are not in the EU, so are not covered. You don't need to know if someone is an EU citizen, just if they are currently in the EU. 2) went for holidays in USA, signed-up on my website, and then came back to EU? (note - potentially skipped any Consent questions at sign-up, because IP was from USA) If someone moves into the EU while using your service then they fall under the GDPR for the time they are in the EU. If their home address is in the EU then that is covered, and monitoring of their behaviour while in the EU is also covered. Your other two questions are about VPNs. If a VPN is used to evade IP address geolocation and you have no other clue about where someone is then you can't be blamed for not knowing where they are (although I'm not aware of any actual case law on this topic). But if someone with a USA IP address gives a home address in the EU then you should probably treat them as being in the EU to be on the safe side. Basically, if you don’t know if they are in the EU or not, you should treat them as if they were.
It seems clear that this is personal information under the GDPR. If you are subject to the GDPR, you need to have a "lawful basis" to store or process such information. (You are subject to the GDPR if you are locates in the EU, or if your users are. My understanding is that it is location at the time the app is accessed that matters, not a user's citizenship. I am not totally sure about that, however. Unless your app is limited to non-EU access, it it probably safest to comply with the GDPR) The degree of precision of your location data will not matter -- a specific city is quite enough to make it personal data if it can be tied to a specific person. There are various lawful bases that may be relied on for processing and storage, but explicit consent is probably the one with the widest applicability. To use consent as the lawful basis, you must present an OPT-IN decision to the user, and record the results. If the user does nothing, the result must record lack of consent. You may not use a pre-checked consent box or another mechanism that has the effect of an opt-out choice. You should be clear about what information will be stored, and how it will or might be used. You will also need to consider how your app will function for those who do not consent, and how to handle requests to withdraw consent. So if an app obtains user consent to store location data in a manner that complies with the GDPR, it may store user location data. The consent should make the possible uses of the data clear. If the data is to be shared, the consent should make the possible extent of sharing clear. Some previous questions and answers here on law.se dealing with GDPR consent that seem possibly relevant: User consent required under GDPR What provisions should I make regarding GDPR consent when users do not sign themselves up? GDPR - Withdrawn user consent Opt Out Consent under GDPR
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.
The question says: But by hashing a IP address you process the personal information and that you can't do without the user's permission! But processing personal data (PI) is covered not by the e-Privacy Directive (ePD) but by the GDPR. Under the GDPR processing may be lawful if it is done under any of the six lawful bases specified by Article 6. Consent is one of these. But paragraph (f) permits processing when: 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 ... This is generally known as the &quot;legitimate interest&quot; basis for processing. It normally requires a balancing against the privacy interests of the data subject. Where, as here, the processing is specifically to remove any traceability of the subject, and hence to protect the privacy of the subject, there doesn't seem to be much conflict, so I suspect such processing would be lawful. I have not found, after a brief search, an actual case where this has been tested, so my conclusion might be mistaken. Personal Data under the GDPR and hashing GDPR Quotes Article 4 of the GDPR defines &quot;Personal data&quot; (in paragraph (1) as follows: 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 term &quot;pseudonymisation&quot; is defined in paragraph 5 of article 4 as follows: ‘pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person; GDPR recital 26 reads: The principles of data protection should apply to any information concerning an identified or identifiable natural person. Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person. 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. The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. This Regulation does not therefore concern the processing of such anonymous information, including for statistical or research purposes. Hashing If a cryptographically secure hash function is used to convert an identifier, such as an IP address, into a replacement hash, there is no practical way from the hash value alone to recover the identifier. However, if a particular identifier value is compared with a stored hash value, it is easy to tell if there is a match. Finding a match does not prove that the identifier is the same -- depending on the length of the hash value being used and of the identifier, there may be many values that would give the same hash. But the chance of two random IDs having matching hashes is very small. Thus, if a controller were to store hashed versions of the IP addresses, no one could convert that back to a list of visiting IP addresses. But if soemoen had the IP address of a suspected visitor, and access to the hash function, it would be easy to check if that IP was on the list. If a keyed hash function were used, only someone with access to the key could perform this check. It is not feasible to hash all possible IP addresses as there are over 4 billion possible IPv4 addresses, and over 10^38 IPv6 addresses (over one thousand decillion). Thus creating a table to reverse the hashing in general is not feasible. Whether the possibility of checking for a match makes a hashed IP &quot;reasonably identifiable&quot; as representing a specific natural person under the GDPR and related laws has not, as far as I know, been authoritatively decided. Note that at most it would reveal that a person using a certain internet connection had (probably) visited a particular site.
A data controller is whoever determines the means and purposes of processing. It is possible that multiple controllers jointly determine the means and purposes. However, someone can only be controller over processing activities where they actually have the ability to influence these decisions (see e.g. the Fashion ID case). The provider of an app does not have any control over what Google does on its servers with the collected data, unless Google were a data processor for that particular processing activity. Thus, the app provider is not a data controller for Google's subsequent processing, and is not responsible for Google's GDPR compliance. HOWEVER, the app provider is a data controller regarding what happens within the app (including any SDKs, libraries, or frameworks). The app provider is data controller for processing activities such as “collecting data” and “sending data to Google”. These processing activities must comply with the GDPR (if GDPR applies), for example they need a legal basis. Under some circumstances there might be a legitimate interest for sending data to another data controller. But in the context of behavioural advertising, such a legitimate interest would be very weak and would not pass the required balancing test. Instead, the app provider would likely have to collect consent. This is very similar to the question of whether a website can embed content from Google services such as YouTube videos, which would necessarily share data with Google. I have written related answers here and there. You are correct that many apps do not collect valid consent before showing ads. GDPR/ePrivacy enforcement in this space is rather lacking, especially since many offenders are outside of the EU. However, this doesn't mean such illegal data processing by apps would be OK.
Can you anonymise people It is valid to anonymise the data of people, instead of deleting all of the records. The principles of data protection should apply to any information concerning an identified or identifiable natural person. Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person. 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. The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. This Regulation does not therefore concern the processing of such anonymous information, including for statistical or research purposes. Source As long as the person is not identifiable, then you do not need to treat the data as personal under the GDPR. You do have to inform a person once they are no longer identifiable, and be able to identify them if they provide the missing information: If the purposes for which a controller processes personal data do not or do no longer require the identification of a data subject by the controller, the controller shall not be obliged to maintain, acquire or process additional information in order to identify the data subject for the sole purpose of complying with this Regulation. Where, in cases referred to in paragraph 1 of this Article, the controller is able to demonstrate that it is not in a position to identify the data subject, the controller shall inform the data subject accordingly, if possible. In such cases, Articles 15 to 20 shall not apply except where the data subject, for the purpose of exercising his or her rights under those articles, provides additional information enabling his or her identification. Source The articles covered by this are: 15 - Right of Access 16 - Right to rectification 17 - Right to erasure 18 - Right to restrict processing 19 - Right to be informed 20 - Right to data portability
The GDPR does not prescribe how exactly consent must be managed, as long as consent was obtained in line with the GDPR's principles. Similarly, the EDPB does not provide concrete recommendations in its guidelines on consent, mainly noting that Controllers are free to develop methods to comply with this provision in a way that is fitting in their daily operations. I would not be too concerned with edge cases like failing HTTP requests, at least not any more than for other HTTP endpoints. If the user indicated consent, and you act on that indication of consent in good faith, that's probably fine. However, remember that you must provide a equally easy way for the user to revoke consent later. If the user changes their mind, they can use the mechanism that you offer to inspect their consent status, and revoke it if they want. But again, how to do that is largely up to you.