Do I have to provide proof of citizenship - GDPR Recently, I've been going through some old accounts of mine (on online websites) and I started deleting them. Thanks to GDPR, this is now much easier. Most companies' customer services have no problems with this; but I have encountered one where they were rather less cooperative. First they said that I can only deactivate my account, but I want to delete it (and Article 17 of the GDPR gives me this right). Therefore, I further emphasised that my wish is for them to completely delete my account. To this they responded that I have to send them my passport and ID to prove that I am an EU citizen. I understand that they may have this right - but do they actually? I cannot find anywhere online that I have to do so - and actually, sending in photos of my documents seems a bit iffy to me, at the very least.
You do not have to prove that you are an EU citizen, because EU citizenship is entirely irrelevant to the GDPR. Have a look at Article 3, which basically says that GDPR applies if you are in the EU or if the company is in the EU. If the company is in the EU, therefore, you do not need to send them anything or prove anything about yourself to invoke GDPR. If the company is outside the EU, you can send proof of address or other evidence that you are in the EU, which might be something that they already have, like your IP address.
It doesn’t make you exempt from the GDPR if that’s what you’re asking The hash you produce is linked to one (or a small number) of computers and it therefore serves as an ID number. Because that ID number is linked to the owner of the computer it is personal information and if you are collecting it, you must comply with the requirements of the GDPR - valid legal reason, deletion when no longer required, deletion on request, data security etc.
This is less of a compliance question, and more of an infosec question. On one hand, you want to be able to restore access to an account to users who have lost their access. On the other hand, you must prevent unauthorized access e.g. from hackers. These factors must be balanced. Whether you'll fulfil a data subject access request will generally follow the same criteria as deciding whether you'll reset someone's access credentials, so I'll mostly discuss identity verification in general. Trying to validate names is generally pointless from a security perspective, since the name on the account might not be real, or because validation documents like scans from a passport can be easily forged. When a service has identity validation measures like requesting a copy of photo ID, or requesting a photo of you holding up a validation code written on paper, that doesn't actually help validating that the person requesting access is the account owner, but that the person requesting access appears to be a natural person, and now documents about their identity are on file. A lot of information like names, birthdates, or addresses is also not at all secret and could be easily guessed by a malicious actor. Most websites work by equating access with control over an email account. If you can receive a password reset code over email, you have access. In effect, this delegates the responsibility of account recovery to the email or OAuth provider. So the issue is what happens when someone loses their email account, which is not entirely uncommon for accounts that are multiple years old. One reasonable (and likely GDPR-compliant solution) is to deny access when someone loses their account. Quite a lot of services operate this way. A milder form of this is to email the old address that someone is trying to take over the account, and turn over the account only if you have other evidence of ownership and there has been no reply over multiple weeks. Since this is part of an identity verification measure, I don't think the GDPR's normal 1 month deadline would apply. However, this approach is very risky: an attack can succeed through the mere inaction of the true account holder, and it would arguably be a data breach if you give access to the wrong person – safer for erasure requests only. Also, emails like “click here or we'll delete your account” look a lot like spam (I get a lot of those about alleged problems with my Paypal account). A potentially more reasonable approach is to use questions about the account to verify ownership. When did they create the account? When did they last use it? Can they answer questions about non-public content of the account? (But don't let an attacker choose the questions!) You see some older sites that ask the user to select a “security question” for recovery purposes. But this isn't a best practice – they are frequently the weakest link in an authentication system. If the user answers truthfully, the answer may be easy to guess or discover for an attacker. E.g. the infamous “what is your mother's maiden name” question is horrendously insecure in the age of Facebook. If the user provides a more secure answer, that is essentially just another password that's even easier to lose than an email account. High-value accounts typically offer a secondary authentication method as a fallback. E.g. my bank can send me new access codes via physical mail. GitHub can optionally link a Facebook account for recovery purposes. But these measures would be overkill for most cases. Especially collecting a physical address for the sole purpose of offering account recovery would likely violate the GDPR's data minimization principle, though it may be fine when the user opts in with freely given consent. To summarize: what you're trying to do is extremely difficult, because you've need to balance different security aspects: keeping malicious actors out, and letting legitimate account owners in. Whereas I'd resolve that by denying any account recovery or subject access requests, other approaches exists with other risk profiles. The GDPR requires you to perform reasonable identity verification measures, but what is reasonable depends on the business context and is ultimately an infosec question.
[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.
It depends on the issuing country. The primary purpose of a passport is to enable the holder to travel internationally, not to prove citizenship. Most countries only issue passports to their citizens, which has made such passports widely recognised as proof of citizenship — both inside and outside of the issuing country. But at the end of the day it is up to the country to decide whether to follow this established pattern or not. For example, Estonia does not. And, of course, it is up to the country to decide which documents prove citizenship of their own citizens inside. Say in Russia a Russian passport for international travel is not a valid document for identification/proving citizenship. So-called "internal passport", similar to that of German citizenship card, serves for this role.
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.
This issue touches upon two distinct GDPR rights: Art 15 right to access: you have a right to receive a copy of all personal data concerning you that are undergoing processing (including storage). Access may only be denied where this would “adversely affect the rights and freedoms of others.” Art 20 right to data portability: if processing is being carried out by automated means, and processing is based on certain legal bases (consent or contract, but not legitimate interest), then you have a right to receive a copy of your personal data in a machine-readable format, for personal data that you have provided to the data controller. Whereas the right to access is fairly straightforward, the right to data portability applies under much more narrow conditions. Basically, it's a right that you can download any data that you've uploaded so that you can move to a different service. Google Takeout is primarily concerned with your right to data portability, and provides your data in a machine-readable format. Any photos that you've uploaded to Google Photos, you'll be able to download. Thus, it could be technically compliant to exclude information that they've inferred about your personal data, such as image-recognition results. Such results would still be personal data under the GDPR definition of the consent, and would be covered by your right to access. Google might argue that you already have access to this data through the web interface. In my opinion the GDPR clearly requires the data controller to provide a “copy”, i.e. the data in some durable form – not merely access through a web interface. Whereas your question is specifically about Google, the same issue applies to other services as well. E.g. Ruben Verborgh has an interesting blog series on trying to get access to all their data from Facebook, though unsuccessful so far. Similar to your scenario, Facebook offers a download for personal data but does not include all personal data in this download. In one of the documents provided by Facebook in the course of the exchange, they note that they allow access to photo tags through the web interface, but do not include this in downloaded data – without providing further justification.
the statute only applies to EU residents Wrong. GDPR applies to everyone in the EU (Art. 3). This means tourists are also covered. Residence status is completely irrelevant (Recital 14(1)): The protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence There is no provision for data processors/controllers to demand proof from data subjects of them being located in the EU. You can challenge them, but if they refuse to provide proof you will still be liable to fulfill their GDPR request should they indeed be present in the EU.