Right to be forgotten in US legal system. Practical approach for erasure? As it commonly known, the right to be forgotten is a fundamental right in the modern informational society. It is the right of an individual to obtain erasure of his personal data from the online and offline directories immediately upon request without undue delay. The perfect example of implementation of this fundamental rule is European GDPR rules which clearly state principles and obligations in Article 17 and recitals 65 and 66. Everybody working in EU and EEA areas is obliged to abide this law and individuals have tools and mechanism to prosecute legal entities that break these regulations. What about US? Is there any similar law within US legal system which I can use effectively to push for observance of my right to forget? I.e. to push websites, web-services and other online/offline entities to delete my personal data. Is there any way to punish them by law if they deny to do that?
In the broad sense encoded in EU law, there is no right to be forgotten in the US. Certain rights recognized in the Constitution, in particular in the Bill of Rights, which prohibit various government actions. The Constitution also gives Congress the specific power to regulate interstate commerce, which has been used to limit individual freedoms (such as the right to grow wheat). In deciding if a law limiting freedom is constitutional, the courts will apply the standard known as strict scrutiny in deciding, when a law restricts a fundamental right (such as the right to free speech). The requirement for passing such scrutiny are that the law is needed for a compelling state interest, it is narrowly tailored, and uses the least restrictive means to do this. There is no such law encoding a supposed "right to be forgotten", although in certain circumstances one might sue for damages over an invasion of privacy, usually broken down into intrusion of solitude, appropriation of name or likeness, public disclosure of private fact and false light. A requirement to delete a person's posts or posts about a person, or records of transactions would not fall under these categories. The simplest answer to the question is, there is no such law, and it is hard to see what law could be constructed that is consistent with US Constitutional protections of individual freedoms.
If a data controller fails to fulfil your data subject rights, lodge a complaint with your data protection authority. In Hamburg, the appropriate form is here. However, they are not required to investigate your complaint. Independently from a complaint, you could consider suing Wordpress for compliance – Automattic has a subsidiary in Ireland so this might actually be feasible. I'm not quite sure though that Automattic is indeed the data controller for wordpress.org, as opposed to the .com domain – the privacy policy isn't quite GDPR compliant. While your GDPR Art 17 Right to Erasure might not apply in this case, there's a definite GDPR violation because the data controller failed to respond to your request within a month as per Art 12(4). That your posts on the bugtracker were deleted doesn't look like an issue in this context, what does matter is that they didn't respond to emails to the addresses mentioned in their privacy policy. Whether you have a right to erasure depends on the legal basis for storing your data. In general, you have a right to erasure if: the data is no longer necessary; processing is based on consent (because you can always withdraw consent); or processing is based on a legitimate interest and they have no overriding legitimate grounds to continue processing despite your objection (Art 21). The data is still necessary to identify you for your actions on the bugtracker, but depending on your particular situation you may be able to object successfully and force them to anonymize your posts.
If person A deletes their account would that mean that person B no longer can view the email sent by person A? No. Person B's inbox implies overriding legitimate grounds that limit person A's &quot;right to be forgotten&quot;. See article 17.1.(c) of the GDPR. Furthermore, item 2 of article 17 is not applicable because the email service did not make A's personal data public. The email service merely sent to B the record with which A unequivocally addressed B. This means that the email service does not even need to notify B regarding A's request for erasure. All the email service needs to do is remove A's account pursuant to A's request.
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
The way you describe this UUID, it is pseudonymous data (see GDPR Art 4(5) and Recitals 28–29). That is, it is not directly identifying, but you have a mapping between pseudonyms and identifiers that can be used to re-identify this data. Effective pseudonymisation requires not only that the data is logically separate, but that there are effective organisational and technical measures preventing re-combination by unauthorized persons. Alongside with encryption, pseudonymisation is one of the safety measures that the GDPR explicitly requires whenever appropriate (see Art 25, Art 32). Pseudonymous data is still personal data, because you can easily re-identify the data. The PII concept is US-specific and is misleading in a GDPR context, where it is not the inherently identifying characteristics of the information that matters, but the realistic ability of the data controller to single out data subjects to whom this data relates (compare Art 4(1) and Recital 26). However, were you to irrevocably erase the UUID–email mapping, things are more tricky. There is no longer any connection with directly identifying data, so this data might be anonymous. On the other hand, such a persistent UUID still allows you to recognize/distinguish persons, so it might still be personal data. This might be the case especially when the UUID is used in long-lived cookies of website visitors, thus matching the GDPR's concept of an “online identifier”. This conclusion could be avoided by limiting reuse of UUIDs, e.g. creating a new UUID after some context-dependent appropriate duration. The GDPR does not require all data to be stored in the EU, but requires international transfers of personal data to have sufficient protections. If you're processing these data in countries without adequate legal protections (like the United States), additional safeguards have to be used. Pseudonymisation could be part of such safeguards, and has been suggested by some data protection authorities in the wake of the Schrems II ruling. However, pseudonymisation alone does not make the international transfer legal, it is more of a strategy to reduce remaining risks. I think that your systems has a good chance of being OK, but not neccessarily so. If in doubt, perform a DPIA and possibly consult your data protection authority under GDPR Art 36. If feasible, storing/processing data only in the EEA or in countries with an adequacy decision will simplify compliance. Safeguards such as pseudonymisation could be strengthened by rotating UUIDs, and by restricting access to the table with identifiers.
That GDPR Disclaimer is no protection in some jurisdictions: the applicable laws to that situation in germany for example don't care about the GDPR: Cold calling, mailing, or e-mailing private people to advertise services all is handled by the same law: Without the consent it is expressly illegal under §7 of the law against unfair competition (Gesetz gegen unlauteren Wettbewerb UWG) and such cases are rather Slam-Dunk if the origin can be made out. The punishment can be a 300.000 € fine. The fact that to email someone you need their e-mail address and that e-mail addresses and private addresses are by default considered personally identifiable information is making it worse for the advertizer: Without either an exception (there is none available to cold-emailing) or special allowance of the person the data belongs to, you violate §4 of the federal data protection law (Bundesdatenschutzgesetzes BDSG) just by handling their e-mail address. That's a separate crime from the UWG one, adding up to another 300.000 € fine under §43 BDSG - or even up to 2 years in prison under §44 BDSG! Oh, and if the email does not contain a proper sender's address, that's another chance for a huge fine under the UWG... So, GDPR is your least trouble, if you violate the marketing laws of a country, or their own data privacy laws. A disclaimer means nothing as the act of sending the mail, even to an unintended addressee, is what is illegal and the law as written does not give a damn about 'I didn't want to advertise to that person' when in fact you sent them unwanted advertisements. Oh, and the very repository you suggest? It would violate the very same §4 BDSG and be illegal for processing private data if it was not actively asked to do that by the end user. As a result, that database is useless: It does kick back all people not in its database. Its database is incomplete because only few people give their address to that database as people not aware of the database never add their data on their own. So it regularly violates §4 BDSG with every German citizen's e-mail address it gets and kicks back, and claiming those addresses would be OK, it throws the company trying to check the database under the bus because they rely on data that is impossible to be reliable. tl;dr Don't do cold-(e)-mail marketing. You throw yourself into boiling oil with a lit torch in hand. further reading Other laws banning such behavior I had listed here, and I quote myself: The US has the CAN-SPAM-Act, which illegalizes sending unsocialised advertisements. You may NOT send a mail if any of the following is true: it has no opt-out the email was gained by 'harvesting' contains a header not matching the text contains less than one sentence the adressee does not have any relation to you In fact, you are liable for a 5-digit fine per infringing e-mail in the US. The FTC itself suggests to never buy e-mail lists - as E-mail harvesting or generating any possible e-mail adress itself is illegal.
You wrote: As far as I believe, it is permitted under GDPR to record and store non-anonymized web server access logs, as these can be useful for security reasons. True, Recital 49 GDPR: The processing of personal data to the extent strictly necessary and proportionate for the purposes of ensuring network and information security, i.e. the ability of a network or an information system to resist, at a given level of confidence, accidental events or unlawful or malicious actions that compromise the availability, authenticity, integrity and confidentiality of stored or transmitted personal data, and the security of the related services offered by, or accessible via, those networks and systems, by public authorities, by computer emergency response teams (CERTs), computer security incident response teams (CSIRTs), by providers of electronic communications networks and services and by providers of security technologies and services, constitutes a legitimate interest of the data controller concerned. This could, for example, include preventing unauthorised access to electronic communications networks and malicious code distribution and stopping ‘denial of service’ attacks and damage to computer and electronic communication systems. You asked: My question is whether this anonymization process counts as processing personally identifiable data under GDPR? IP addresses are personal data in some cases, so yes, you're processing personal data. Then, these anonymized logs will be fed into an analytics tool to provide stats on unique visitors, page hits, etc. These are purposes considered compatible with initial purposes according to Article 5.1.(b): Personal data shall be (...) collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for (...) statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’); As a matter of fact, you might be required to anonymize the data for those purposes, see Article 89.1: Processing for (...) statistical purposes, shall be subject to appropriate safeguards, in accordance with this Regulation, for the rights and freedoms of the data subject. Those safeguards shall ensure that technical and organisational measures are in place in particular in order to ensure respect for the principle of data minimisation. Those measures may include pseudonymisation provided that those purposes can be fulfilled in that manner. Where those purposes can be fulfilled by further processing which does not permit or no longer permits the identification of data subjects, those purposes shall be fulfilled in that manner. If I were to anonymize the logs and continue to use them exclusively for security reasons, would that change anything? No, you would be processing data in a manner compatible with initial purposes (ensuring network and information security). Or does it not matter what I do with them once they are anonymized? Yes, it does. If you're not using them for &quot;archiving purposes in the public interest, scientific or historical research purposes or statistical purposes&quot; then you're using them for purposes incompatible with initial purposes. You would need to find new legal basis for processing. does this extra anonymization process on top then take it over the line meaning that consent and a privacy notice would be required? It depends on what you want to do with anonymized data. In your case, for security purposes or security and statistical purposes, you don't need the consent and there is no requirement for the privacy notice (but sure, it would be nice to publish one). For other purposes it might be different.
Since the Steam ID contains or may contain enough information for it to be possible to link your account to you as a physical person, it would definitely be considered "personal data" according to Article 4 of the GDPR. However, by agreeing to the DOTA2 terms of service, you have given consent for them to show your information to other players (or at least that is included in most terms of service I have read for other games. I have not read the one for DOTA2 specifically). Replays are an interesting corner case. If download of replays are only possible for other players or if the wording of the ToS says that you consent to displaying your user ID to anybody, that would mean that they would have covered their bases. As long as they comply with other parts of GDPR, like "the right to erasure" (Article 17) that is. If the API is accessible to anyone and not covered by the ToS you might have a case. If you only want to remove the traceability between you and the replays, you can always evoke Article 17 and delete your account.