Are Blizzard breaking GDPR by charging people for changing their usernames? I have had an account with Blizzard for several years now. I changed my username (referred to as a battletag) only once, over a year ago. I now want to change it again because searching it on Google shows personal info about me that I don't want others to know. Blizzard charge for changing the username. I contacted them mentioning GDPR, and was told it looks too generic to be personal data, so I would have to pay for a change. Their GDPR contact agreed with this. Surely it is personal data, because they can search it within their own database and link it to my real name which makes it personal data under GDPR. Am I not understanding GDPR correctly, or are they violating my rights?
It’s personal data ... but why do you think you can change it for free? It’s clearly personal data because it can be demonstrably linked to you, both within and outside Blizzard’s database. Presumably, you consented Blizzard having it or they have some other legitimate basis for having it. So far, this is all GDPR compliant. You have a right to be forgotten, so you can ask Blizzard to delete your account. You have a right to confirm the information is correct. And that’s it. They can charge you a fee to change your user name just like your government can charge you a fee to change your real name.
The first thing to notice is that the £100 offer appears to be a legit offer. That is to say, accepting it will create a binding agreement between you and the company. There is no reason yet for the company to believe that you have suffered more damages, and you do have reasonable options to prevent them (ask bank for a new card - that's not going to cost you £100). The second observation is that the GDPR does not really affect the first observation. The GDPR itself does not give rise to additional civil claims or special damages. Yes, the GDPR states that the company is in the wrong, but parties can make agreements how a wrongful deed is made right again. And their offer appears to do so. Note that accepting the offer does not take away your continuing GDPR rights. It just affects their past error. You can still ask them whether they have your card data on file today.
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
Yes, there would still be an obligation to comply with erasure requests – if the data subject can be identified, and if the GDPR applies. This is a case for Art 11 GDPR: processing which does not require identification. The pastebin site is not required to collect identifying info just in order to facilitate later deletion. If the site is unable to identify the data subjects, then the data subject rights (like access, rectification, erasure, restriction, or data portability) do not apply. Other rights like the right to be informed and the right to object do remain, though. But if the data subject provides sufficient additional information that makes it possible to identify their records, then the data subject rights apply again. In practice, this is likely going to mean that anyone with access to a paste will be able to request deletion, since the site would have no ability to verify the identity of the data subject beyond the information in the paste. None of this absolves the site from implementing appropriate technical and organizational measures to ensure the security of this data. Even though the pastes might not be directly identifying, they are personal data and are far from anonymous. Common practices like numbering pastes with a sequential ID or showing recent pastes on a homepage have to be viewed critically. My go-to recommendation is to assign a cryptographically random UUIDv4 ID to the post, so that it is practically impossible for anyone to find the paste unless they were given a link by the uploader. Your idea to delete pastes after a fairly short retention period is also good. This helps with security, and it is in line with the GDPR's data minimization and storage limitation principles: data may only be kept as long as necessary for its purpose. On the other hand, quick deletion might not be in line with the purpose of these pastes – it all depends on context. You mention that this is an US-based site. If so, there's a question whether GDPR would even apply. GDPR will apply per Art 3(2) if the data controller is offering its services to people who are in Europe. Here, “offering” does not mean mere availability of the website, but that the data controller intends the service to be used by such people, in particular if the service is somehow targeted or marketed to such people.
If you are purely a designer (and not contracted for the daily operation of the site), the answer is "no". GDPR Article 4 defines the "roles" responsible for complying with GDPR, and there are two: Controller and Processor. The Controller is the one who calls the shots. In particular: Decides what personal data to process. This is usually the owner of the web site. The Processor is the one that actually does the processing. This is usually some company providing some sort of data processing service (e.g. SaaS, PaaS, etc.). The relationship between the Processor and the Controller must be contractual. The contract is called a DPA (Data Protection Agreement or Data Processing Addendum). As a designer, you don't fit into any of these roles. If your contract with the client is silent on liability for GDPR compliance, then you have no liability. This goes for projects completed both before and after the May 25 deadline. Of course, if there are GDPR clauses in your contract, then you must fulfil them just as have to fulfil any other contractual obligation. But unlike the controller and the processor, there are no automatic legal liability for a designer or programmer.
Your VPN scenario is why you have to show the banner to everyone. If you somehow knew beyond any doubt that someone was not in the EU, then you would not have to show a banner, but because you can't verify that, you should always show the banner. Doing so also protects against accidentally violating a similar law in another country; the GDPR is the best-known privacy law, but it is far from the only one. It's good practice to ask for people's permission before collecting their information anyway.
You are processing the users IP address in order to carry out the translation to a physical location (see my comment for the technical issues with that) and an IP address is most certainly considered personal information, so yes under the GDPR you are going to need a published policy because you are both data controller and data processor. You need to inform the user of what you are doing, and you need to tell them of the legal basis for the processing (there are several under the GDPR, of which consent is only one - but in your case its going to be the easiest to justify). If you use a third party service for the location translation, you also need to inform the user of that and make available the third party services data processing policy.
The Art 15 GDPR right to access is pretty absolute. There are only three grounds under which access to a copy of your data can be denied: Art 12(5): the request is “manifestly unfounded”, e.g. clearly just submitted for trolling Art 12(5): the request is “excessive”, e.g. if you repeat the same request very frequently Art 15(4): access to a copy would “adversely affect the rights and freedoms of others” Thus, I am confident that Twitch would respond to an access request with a copy of all your chat messages. Of course, the chat messages might be useless without context, but providing that context might infringe on the privacy rights of others (see Art 15(4)). There are two caveats to this right. The data need not be machine-readable, unless the more limited Art 20 right to data portability also applies. Twitch is under no explicit obligation to provide access in a self-service manner, e.g. through an app or web interface. It would probably in the best interest of Twitch to provide self-service means, but right now the Twitch privacy policy (permalink) asks you to exercise your rights by emailing privacy@twitch.tv. Alternatively, their privacy choices page contains an entry to “Obtain access to or a copy of certain personal data we hold about you”, which contains a barely-visible link to a web form where you can request chat data.