Under GDPR EU law, can I sue big tech companies (Facebook, Google, Apple) for acquiring and storing my personal data without my consent? Many of my friends have social media accounts (Instagram, Facebook, etc.) where they regularly post photos of them and where occasionally I appear in them. Many of my friends have their personal assistance in their phones that is constantly hearing what happens in the vicinity of the phone. Sometimes, since they are my friends, these apps record my voice and process it. I never consented to these companies to process and store my data, only my friends allowed it. However there is little doubt that these companies also have all these information about me, my facial expression, my voice signature, and many other personal information. I have two questions: Is this permissible under EU private data law? Can I sue these companies for illegally storing so much information about me? How can I prevent that such companies have so much information about me?
Per GDPR Art 79, you can sue data controllers if you consider your rights to have been violated. Where you have suffered damages due to GDPR infringements, you also have a right to compensation per Art 82. However, your rights may not have been violate as far as the GDPR is concerned. Under the GDPR any kind of personal data processing needs a clear purpose, and that purpose needs a legal basis. One possible legal basis is consent, but there also are others (such as legitimate interest). Just because you didn't consent doesn't mean that your rights have been violated. Where processing is based on legitimate interest, you can object to that processing of your personal data – but your rights must be balanced against that legitimate interest (Art 21). If your friends post a photo and you only appear in the background, your friends' legitimate interest to post that photo likely outweighs your rights. In practice, suing Facebook because of GDPR infringement is not a sensible way to achieve the outcomes that you likely want. First, this is expensive. Second, it is arguable whether Facebook or your friends should be the defendant. Third, removal of existing data won't prevent the processing of new data in the future. It would be more sensible to treat this as an interpersonal rather than a legal problem, and to talk with your friends so that they don't include you in their photos that they would like to share online. I've focussed on photos because their situation is fairly clear. Voice snippets might not count as personal data when you are not identifiable in them. Personal assistant apps should not be listening continuously, but only start recording when a wake-word is recognized.
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.
There are two relevant bodies of EU law to consider here. The GDPR covers processing of personal data. Personal data is any data where the data subject can be identified directly or indirectly. The ePrivacy directive is also relevant, and covers how you may access and store information on the user's device. Directives are not directly applicable law. Instead every member state translates the directive into national law. In the UK, ePrivacy is implemented by PECR. Is the data you collect personal data in the sense of the GDPR? Yes: that hashed unique device ID or a system-provided advertising ID likely is personal data, and any linked data would then be personal data as well. This is going to be the case in particular if you store user accounts on your server and can connect these bug reports to a user. Consider also whether the game save could include personal data, and whether the video clip could be analyzed to identify the data subject. Does this mean collecting this information in bug reports is forbidden? No, the GDPR doesn't forbid or allow anything outright. Instead, you should go through the compliance process. In a nutshell: determine the purpose of this processing, e.g. “fixing bugs” find an Art 6 legal basis for this purpose, e.g. “Art 6(1)(f) legitimate interest” or “Art 6(1)(a) consent” if the legal basis is legitimate interest, you must balance that interest against the data subject's interests determine whether your compliance requirements include creating/updating your Records of Processing, or whether you have to write a Data Protection Impact Assessment implement the processing in a manner that respects GDPR principles such as Transparency and Data Minimization if the legal basis is legitimate interest you must implement an opt-out solution if the legal basis is consent, you must request consent first in a manner that satisfies the Art 7 conditions for consent – and allow consent to be revoked easily prepare to satisfy data subject rights: information requirements per Art 13, usually done in the privacy policy right to access, rectification, erasure, and data portability right to object (opt-out) and to restrict processing be aware of your general requirements a data controller to process this data securely, e.g. use HTTPS connections to transmit bug reports, take steps to protect your own accounts (e.g. 2FA), and ensure you have a suitable contract with any data processors that act on your behalf, e.g. cloud providers or contractors I would question whether your bug reports really need to include a device ID. That isn't forbidden, it just complicates compliance a bit. And what about ePrivacy? The ePrivacy directive is known for its cookie consent requirements. But these consent requirements apply when accessing any information on the user's device, or when applying equivalent fingerprinting techniques. Your game save is not an issue because it is necessary for the game. But that device ID and other system information is more difficult. So what to do? Compliance isn't trivial, but certainly possible. You will likely process the bug reports under your legitimate interest, but might still have to collect consent for accessing a system ID due to ePrivacy. Such a screen might look like this: Oh no, the game crashed! Do you want to send a bug report to the developers? Your bug report will be protected as per our privacy policy (link). Your bug report will contain the following information: … Yes, collect system information and send bug report No, do not send bug report You could make an argument that a bug report can be sent in any case, and that you just need ePrivacy consent to collect useful system information. For example: Oh no, the game crashed! When sending a bug report to developers, do you want to include extra system information (link to details) that helps fixing the problem? In any case, your bug report will be protected as per our privacy policy (link). Your bug report will contain the following information: … Yes, send bug report with extra system information No, send anonymous report
Defamation requires communication to a third-party I can say (or write) anything I want about a person directly to that person and, unless it is a threat, they have no recourse at all. I can call them a liar, a thief, a Nazi, or a goat fornicator. Of course, I have to be careful – calling them a “bastard” might be a slur on their mother communicated to a third-party (them) which would give her a right to sue although that would require a literal and largely archaic use of the term. That said, you do need to check with your lawyer if you can redact names in the face of a subpoena - complying with a legal obligations is a legitimate use of personal data under GDPR.
First of all, although the GDPR is stated to apply to any site which processes the data of any person who is in the EU, it is not clear how a site not located in the EU, does not business in the EU, and does not primarily target EU residents as its audience can be required to comply with the GDPR. To the best of my knowledge, no such case has yet been brought, much less decided. There has also been some debate on whether an IP address constitutes Personal Data under the GDPR, and if it always does so, or only under particular conditions. The European Court of Justice (ECJ) held that (under the predecessor Directive 95/46/EC) that a dynamic IP address was personal data. But in that case the web site was run by the German Federal Government, which surely has wider scope for getting info from a German ISP than a small private US web activist does. There is not yet any case law that I know of on the applicability of the GDPR to IP addresses in any case at all similar to the one in the question. Joe would in my view be wise to at least learn that logs are being kept, and post a disclosure of this on the site. Whether Joe needs to do more than that is less than clear at this time.
GDPR definitely applies. Your scenario seems to raise two questions: What is the legal basis for processing? Are the security measures appropriate? Legal basis Every processing activity of personal data requires a legal basis. Most well-known is consent, but there are six categories in Art 6(1) GDPR including legitimate interests and necessity for performing a contract with the data subject. Conditions on consent are laid out in Art 7 GDPR. You say that data subjects “explicitly agree to the website's privacy policy and GDPR”. The GDPR does not generally expect “agreement” to a privacy policy, as information per Art 13 is an unilateral notice. Such general agreement also cannot constitute valid consent. In the context of certifications, the legal basis would likely be necessity for performing a contract with the data subject: You were contracted to provide this validation service to the data subjects. You should however make it clear which information will be displayed on the validation page (other than a valid/not valid) response. For example, I am concerned that showing the email address would not be strictly necessary for providing the validation service. You should also consider whether this validation service is a core component of your certification service, or whether there should be an opt-in or opt-out here. Security Measures The GDPR requires that you implement appropriate security measures, “taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms” of the data subjects (see Art 32 GDPR). This gives you a lot of leeway to determine what measures are appropriate, but also criteria that you must consider in your determination. A number of security measures are explicitly suggested and must also be considered: pseudonymization and encryption ensuring confidentiality, integrity, availability, and resilience of your systems ability to restore the service (e.g. backups) processes for regularly testing and evaluating your measures Aside from generic IT security measures like backups and providing the service over a HTTPS connection, I would be concerned about “insecure direct object reference” style attacks on the database. If I know that certification no 1234 exists, I could try to get the information for other numbers like no 1233 and so on. This would leak personal data. Basic defenses could include requiring additional information such as the data subject's name to be provided, or using anti-bot measures such as captchas and rate limits. However, the real solution is to avoid sequential IDs, and to generate sufficiently large tokens with a cryptographically secure random number generator. Instead of a “certification number”, it would be better to view this as a “validation code”.
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.
In my opinion, this should be enough. The GDPR regulation is general - it does not attempt to address these issues directly, precisely for the reasons we see here: You can never predict how the technology will develop. When interpreting the GDPR, we must keep the intended goal in mind. What is the purpose of the "right to erasure"? To prevent anyone from further processing the personal data. If you "crypto-shred" it, it can't be processed anymore, not even theoretically. The encryptec file cannot be used to identify the subject, therefore it is not even personal data anymore. In case it can be decrypted in the future... Well, that is just a speculation. The courts can go to great lengths in interpreting what personal data is (dynamic IP address is considered personal data, since it can be linked to a person by the police with a court order), but i am pretty sure that "it can be theoretically possible in some distant future" is beyond the limit. As for the second question, I am not aware of any applicable case-law, but I guess that current security and technological standards will be used to assess the delay. You have a right to protect your data, the subject has a right to erase them. Those rights must be balanced, neither fully overrules the other. The delay should be short enough so the right to erasure is effective, and it should not extremely long compared to other (economically viable) backup solutions available, in line with current industrial standards.