Which article of the GDPR implies that one should use the BCC field in order not to dissiminate personal mail addresses? Which article of the GDPR implies that one should use the BCC field in order not to dissiminate personal mail addresses when sending mails?
Article 5(1)(f) processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’).
I'm not aware of any cases on point, but as a rule legal fig-leaves don't play well in court. If the webmaster simply puts up a banner saying that EU residents are not permitted but takes no other action to exclude them, then that is going to be considered irrelevant. The webmaster is still very likely required to comply with the GDPR. On the other hand if the webmaster takes other steps to exclude EU residents, such as using a geolocation service to block connections known to be in the EU, validating email addresses and blocking those from EU domains, and ejecting anyone who mentions that their residence is in the EU, then that is more likely to be seen as a good-faith attempt to avoid being subject to the GDPR. It will also have the practical effect of greatly reducing the number of actual EU residents. All these controls can be evaded, but it would be much harder for any data subjects to claim that they acted in good faith or that the webmaster acted in bad faith. Note that validating an email address or logging an IP is itself processing of personal data, so anyone implementing such a system still can't ignore the GDPR completely, but it would greatly limit the scope and make it easy to delete any such data after a short time. (Note: the term &quot;EU resident&quot; above is an approximation of the territorial scope).
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.
GDPR seems quite clear that if you are recording calls, video and/or audio, you must get consent. Wrong. The GDPR requires that your have a legal basis for processing personal data. Consent is a legal basis but there are others. With respect to note taking, the GDPR only applies to “personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system.” So, if they notes are not about an individual (and many B2B phone calls will not be) or are neither automated nor filed, the GDPR does not apply. If they are captured by the GDPR, you need to have a legal basis for the notes. Again, consent is one but it is not the only one.
It follows from case law from the ECJ, e.g. C‑70/10 (28 January 2010) and C-582/14 (19 October 2016), that IP-addresses are personal data. Since my interpretation of the case law differs from the interpretation offered by @Greendrake, I'll go into the relevant case law in a bit more detail than I did in my initial answer. TL;DR: Yes, IP-addresses in server logs are personal data and you need to declare IP-address logging in your privacy policy. As I said, we need to examine the case law I mentioned in the introduction to find out whether IP-addresses are personal data. The first of those are ECJ C-70/10. In this, the court concludes that all IP-addresses are "protected personal data": It is common ground, first, that the injunction requiring installation of the contested filtering system would involve a systematic analysis of all content and the collection and identification of users’ IP addresses from which unlawful content on the network is sent. Those addresses are protected personal data because they allow those users to be precisely identified. (my emphasis) Then, in 2016, the ECJ ruled in a more narrow case ECJ C‑582/14 specifically ruling on dynamic IP-addresses: The court goes through a number of deliberations, then concludes: Having regard to all the foregoing considerations, the answer to the first question is that Article 2(a) of Directive 95/46 must be interpreted as meaning that a dynamic IP address registered by an online media services provider when a person accesses a website that the provider makes accessible to the public constitutes personal data within the meaning of that provision, in relation to that provider, where the latter has the legal means which enable it to identify the data subject with additional data which the internet service provider has about that person. It is very clear from this text that the court does not challenge or invalidate ECJ C-70/10 on static IP-addresses. The court is very careful, in its ruling to point out its ruling is specifically about dynamic IP-addresses. So the ruling of ECJ C-70/10 still stands for static IP-addresses, these are always protected personal data. I believe this case law is summarized in Recital 30 of the GDPR. This recital lists the identifiers that may make natural persons identifiable: Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. (my emphasis). Since it follows from case law that static IP-addresses always makes the data subject identifiable, and dynamic IP-addresses may make the data subject identifiable, I will conclude, based on jurisprudence alone, that: Unless you are able to filter your logs to exclude static IP-addresses. I think you must consider IP-addresses protected personal data under the GDPR. However, in ECJ C‑582/14, the ruling about dynamic IP-addresses hinges on the controller having legal means to identify the data subject by connecting the IP address to some other data. The court seems to think that getting access to ISP logs is the only means of doing that. This is wrong. In 2015, the Norwegian computer scientist Einar Otto Stangvik identified 78 Norwegians who seem to have downloaded abuse material starting only with their IP-addresses. Stangvik did this while working as a consultant for Norway's larges newspaper VG. I know Stangvik and I am familiar with the methods he used. I've tried them myself, and they work. Stangvik did not have access to ISP logs, he did not do anything illagal, and the 78 natural persons identified only by means of their IP-address, combined with other data the Stangvik had legal access to. I will not go into details, I will just say this: If you know how to do this, getting to the natural person when you know the IP-address is not difficult or labour-consuming. To return to the question: It also follows from the GDPR that logging of IP-addresses falls under its definition of "processing". Your privacy policy should list all personal data personal data that is collected by yourself and third parties ("processors" in the terminology of the GDPR) that you rely on. Your hosting company is such a third party, and you need to declare the logging of IP-addresses in your privacy policy.
If GDPR applies, then no one can opt out. If it doesn't apply, then an IP block is superfluous. Whether GDPR applies is determined by Art 3 GDPR. For this, we must distinguish where the data controller is operating from. It is irrelevant where the site is hosted, but primarily relevant where the data controller (your colleague) has an “establishment”, e.g. where he resides or typically works from. Per Art 3(1), GDPR applies to all processing activities in the context of an European establishment, regardless of where the users are. So if your colleague were running this site from Europe, they wouldn't be able to circumvent GDPR by blocking European users. However, if your colleague is running this site from outside of Europe, then Art 3(1) doesn't trigger. Per Art 3(2), GDPR can apply to processing activities where there is no European establishment. There is the Art 3(2)(a) “targeting criterion”: if your colleague “offers” goods or services to people who are in Europe, regardless whether paid or gratis, then GDPR applies to all processing activities related to this offer. I'll discuss this more below. There is also the Art 3(2)(b) criterion: if your colleague monitors the behaviour of people that occurs in Europe, then GDPR applies. For example, an app collecting geolocation information or a website creating interest profiles for ad targeting might trigger this criterion. An IP block can help to establish that no offering/monitoring related to people who are in Europe is happening, but it might not be necessary. It may be worth talking a bit more about the targeting criterion. The GDPR explicitly says that mere availability of a website in Europe doesn't imply that GDPR would apply. Instead, it is necessary to establish the data controller's intention – are they soliciting users from Europe, or otherwise expecting that people from Europe might use those services? Recital 23 gives a couple of non-exhaustive factors that can be considered here, for example: the site uses a language or currency used in the EU but not used in the controller's own country the site mentions users or customers from Europe, e.g. in testimonials This means that a lot of US websites, written in English or Spanish, only mentioning payment in USD (if any), not mentioning any European countries, will not be subject to GDPR. Then, occasional European visitors are irrelevant. It wouldn't be necessary to IP-block potential European users. However, such an IP-based block would help establish that the data controller really doesn't intend for those services to be offered to people who are in Europe. My personal opinion is that it's wasted effort to block users from foreign countries in case their foreign laws claim to apply, but if such a block brings peace of mind that might be worth it. While geoblocking might not be necessary, is it sufficient? There is no clear guidance on this subject, but it seems to be generally accepted that IP-based geoblocking is fine, even though it is trivially circumvented using VPN services. Of course, if a website were to block European IP addresses but were to also advertise that people in Europe can use their services via VPNs, that would probably still be an “offer” and might defeat the point of doing any geoblocking. The Art 3(1)(a) targeting criterion is most easily applied to things like ecommerce where physical goods are shipped to the customer in return for payment – so essentially whenever the data controller participates in the EU Single Market. This is roughly similar to the concept of a Nexus in US tax law. But in principle the targeting criterion can also apply to other kinds of websites or apps such as blogs, even if they are gratis. GDPR does not just apply to for-profit commercial activity, and doesn't distinguish between controllers that are entities/LLCs and controllers who are natural persons. Things are slightly more complicated due to the Art 3(2)(b) monitoring criterion and the pervasive use of online trackers on websites, but this aspect of the GDPR is difficult to enforce and frequently ignored. In this answer, “Europe” means the European Union (EU), the European Economic Area (EEA), and the United Kingdom (UK). Note that countries like Norway are covered by GDPR, whereas Switzerland is not. Of course, the GDPR is not the only privacy law relevant internationally.
Why would the EU expect that any of its laws would apply to my business? It doesn't. Unless you choose to do business in the EU (which is possible, thanks to the wonders of the World Wide Web). Then, and only then, do you have to comply with EU law, including the GDPR. From a comment by @BenCollins: I'm talking about non-EU online retail that does allow Europeans (particularly those not actually in the EU at the time of the transaction) to place orders. Basically, GDPR Article 3 says that the GDPR applies to the processing of personal data of data subjects who are in the Union The phrase &quot;in the union&quot; is clearly open to interpretation, but according to the website Security Now, Dr. Michèle Finck says this: Most people seem to agree that the relevant criterion is whether you're based in the EU at the moment data is collected - citizen or not (my emphasis). While Michèle Finck is a well-respected legal scholar, she is not an authoritative legal source, so we need to wait for to case-law to nail this. For what it is worth, (not much I am afraid) I think it would be against common sense to define the territorial scope so broad that brick and mortar stores in the USA risks to be prosecuted in Europe if they sold goods or services to European tourists. However, what most US based businesses that chooses to be open to business for orders that are placed by natural persons who are in the [European] Union need to know that there is this: According to European law, the GDRP does apply to them when they conduct such business. From a comment by @BenCollins: I question the notions that (a) there is a basis by which the law would apply The legal basis is European law, in particular GDPR Article 3. and (b) that it has any enforcement mechanisms outside the EU. As for enforcement, I think a good answer has already been provided by Dale M. but for completeness: The USA has treaties with EU that mean that after a legal case has been decided in a court of law in the EU, it can request that the USA enforce the judgement (typically by collecting the fine the USA-based business incurred when conducting business in Europe). To make this answer more general, here are a breakdown of the the regulation of territorial scope of the GDPR for businesses that are not located in the EU: The scope is clearly spelled out in Article 3, and if you're not &quot;a controller or a processor in the Union&quot;, you are only subject to the GDPR if your processing activities are related to: a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or b) the monitoring of their behaviour as far as their behaviour takes place within the Union. US based companies that engage in business practices that are illegal in Europe know about this, and has already taking steps to protect themselves from the being prosecuted in Europe under the GDPR by using firewalls to block access to their services from the EU. The bottom line is that if you: have no presence in Europe, and don't offer goods or services to people who are in the Union, and you don't collect personal data about European natural persons, then the GDPR does not apply to you. If at least one of the above applies then you need to follow the GDPR if you do not want to be prosecuted in the EU.
[I'm not so well-versed on US and Russian law, thus I will limit my answer to EU law.] Your specific use of a user identifier, as I understood from your question, can be classified as personal data, so in your case, the GDPR seems to apply. This means that you need to have a) legitimate purposes to process that personal data (e.g. crash reporting) and b) a legal justification for each purpose of processing: it could be based on consent or another legitimate purpose (inc. your own legitimate interests). Consent might not be the best option for you, but it's up to you to decide. In any case, you need to assess the risks to the data subjects (your users) before you decide. How likely is it that you will get breached, and what potential harm will that cause to your users? These are some guidelines; my recommendation is that you read the law and the guidelines by the Article 29 Working Group and European Data Protection Board, or hire some good experts on this. There is no easy answer, or one size fits all solution. The GDPR isn't so hard to understand or implement, but it does require some change in mindset. With the new law, processing personal data carries a higher risk of penalties, so you should do it only when it's absolutely necessary, and with respect to the rights of your users.