How does GDPR deal with combined personal data? There is a person named aa 1 where aa is their first name and 1 is their surname. Now some other person makes an email named aa.1@somemailingcompany.com. Whose personal data is this? aa 1's or that other person's? How is a request from the real aa 1 answered then to access the email?
I think this shows a misunderstanding of the meaning of the GDPR. A data subject has the right to demand information, correction, deletion etc. about some of their data held by some institutions, depending on the legal basis for the data processing. One John Smith does not have the right to see the data of any other data subject named John Smith, and he cannot even demand to know if there are other John Smiths in the database. The data controller has to make reasonable steps to ensure that an individual who seeks account information is in fact the individual who is the data subject. In the case of an email, that's usually easy -- if John Smith can access the mail account jsmith@sample.org, one can assume that he is the John Smith who opened the account. If not, then not. If the data controller has the birthplace and birthdate in their records, they can possibly match that against some government-issue identity document, too, but why would they have that data?
It is the data controller's responsibility to respond to data subject requests. If you provide a B2B service, you are most likely a data processor who only acts on the controller's behalf, on the controller's explicit instruction. This will depend on your contract with the controllers, your customers (see Art 28). Typically a processor would merely forward any data subject requests to the controller. Only if you are contractually obligated to serve data subject requests would it be possible for you to respond directly. If a processor were to fulfil a data subject request on their own initiative, that would arguably be a GDPR violation. However, the processor has to assist their controller with compliance per Art 28(3)(e), e.g. by implementing an admin interface through which the controller can service GDPR requests. The core issue here is that controllers and processors have slightly different obligations in order to be GDPR compliant. Controllers owe compliance to the data subjects, but processors only act on the controller's behalf and owe compliance to their controllers – they have no direct relationship with data subjects. Assuming you were a controller, then yes, I would assume you would have to decrypt any data that you are able to decrypt in order to fulfil a data subject request. Access requests can only be denied if: Art 12(5): they are “manifestly unfounded or excessive” (which the controller has to demonstrate), or Art 15(4): the access would “adversely affect the rights and freedoms of others”. Art 11(2): the controller can demonstrate that they are actually unable to identify the data subject so no data subject rights in Art 15–20 apply. A request is not automatically excessive just because it will require substantial CPU time, this exception is more often triggered when data subjects request the same data very frequently (e.g. every week). You are not required to provide or search data that you don't have access to (e.g. E2E encrypted data). Your use of per-field encryption is a very strong security measure (depending on how keys are managed). But GDPR is not about achieving maximum technical data protection, but merely requires appropriate safety measures (see GDPR Chapter 4, especially Art 32). Asymmetric encryption of small fields within a database is unlikely to be appropriate, taking into account the cost of processing and the data subject's ability to exercise their rights. A different security measure to ensure that every business only sees the correct data would be through testing and code review of your SQL queries, and full disk encryption of the server storing the database. In practice, asymmetric encryption is most often just used to encrypt a symmetric key, which is then used for the actual data. But which measures are appropriate also depends on the risk to data subjects – your approach could make sense for very sensitive data. Art 14 does not play a role here. It is about transparency of processing: that you need to (a) notify the data subject that you're processing their data, if feasible, and that you (b) provide information about this processing, usually in form of a privacy policy. Art 14 is the pendant to Art 13, which applies when data is obtained directly from the data subject. The Art 15 right to access and the Art 20 right to data portability are distinct from the right to be informed. In any case, it is the controller's responsibility to fulfil these rights.
Yes, this violates the GDPR if the user is in Europe. Data which is tied to a personal device can be tied to the person who owns it. From "What Is Personal Data" by the UK Information Commissioner's Office (ICO) (emphasis added): Personal data is information that relates to an identified or identifiable individual. What identifies an individual could be as simple as a name or a number or could include other identifiers such as an IP address or a cookie identifier, or other factors. If it is possible to identify an individual directly from the information you are processing, then that information may be personal data. If you cannot directly identify an individual from that information, then you need to consider whether the individual is still identifiable. You should take into account the information you are processing together with all the means reasonably likely to be used by either you or any other person to identify that individual. The bit about "all means reasonably likely" in the last bullet includes the kind of de-anonymisation tactics described in the NYT article. There are 6 lawful bases for data processing in the GDPR, and all processing must fall under at least one of them. (a) Consent: the individual has given clear consent for you to process their personal data for a specific purpose. (b) Contract: the processing is necessary for a contract you have with the individual, or because they have asked you to take specific steps before entering into a contract. (c) Legal obligation: the processing is necessary for you to comply with the law (not including contractual obligations). (d) Vital interests: the processing is necessary to protect someone’s life. (e) Public task: the processing is necessary for you to perform a task in the public interest or for your official functions, and the task or function has a clear basis in law. (f) Legitimate interests: the processing is necessary for your legitimate interests or the legitimate interests of a third party, unless there is a good reason to protect the individual’s personal data which overrides those legitimate interests. (This cannot apply if you are a public authority processing data to perform your official tasks.) Selling data isn't covered by any of the others, so consent must be obtained. Permission must be clear and positive, and you cannot predicate delivery of a service on the processing of data that isn't necessary for that service. So for instance you cannot say "You can use this service as long as we are allowed to collect and sell your data" because selling the data isn't necessary to the provision of the service. From "Consent" by the ICO: Consent requires a positive opt-in. Don’t use pre-ticked boxes or any other method of default consent. Explicit consent requires a very clear and specific statement of consent. Keep your consent requests separate from other terms and conditions. Be specific and ‘granular’ so that you get separate consent for separate things. Vague or blanket consent is not enough. [...] Avoid making consent to processing a precondition of a service. This applies to any processing of data about individuals within the EU, so just being an American company doesn't get you a free pass to ignore the GDPR if your app gets used by Europeans. The "Legitimate interests" basis is more problematic, in that the company collecting the data has to conduct a vague "balancing test" to determine if this basis applies. For direct marketing the ICO has written this, which says that direct marketing may be a legitimate interest, especially if you can show that the user has expressed interest in such adverts. For instance a location service which promises to tell you about nearby special offers would fall into this category. Against this, the impact on the user's privacy has to be considered, and location data is "special category data" because it can reveal medical information (e.g. hospital attendance) or religious affiliation (e.g. which church you go to). So unless the relationship between the recorded location data and the service is very direct its not going to pass the balancing test. The company would also need to distinguish between knowing the current location and keeping a record of historical locations; the two need separate justification. And of course nothing about this covers the sale of the data; this is considering a company which sells advertising space in it's app, not one that sells the data itself.
Earlier this year, the Internet lawyer Arnoud Engelfriet wrote a blog post about exactly this topic. As it is written in Dutch, I will summarize it here: As you also said, deleting posts breaks the flow of the archived conversation and it makes your archive incomplete. This is a problem for the freedom of expression and information. But Art. 17(3) GDPR includes an exception to the right of erasure for this situation. So posts do not need to be deleted. However, profiles are not included in this exception. So they must be removed, but they can be pseudonymized. For example replace the username with user89432, and remove all details from the profile. If other posts contain the nick of the author of an anonymized post, that is considered an journalistic, academic artistic or literary expression, so Art. 85 GDPR would apply, so the right of erasure does not apply to that. Bottom line: you only have to pseudonymize the account, if that person wants to be removed from the forum.
GDPR gives you a lot of flexibility here to choose either DPA. From Art 77: Without prejudice to any other administrative or judicial remedy, every data subject shall have the right to lodge a complaint with a supervisory authority, in particular in the Member State of his or her habitual residence, place of work or place of the alleged infringement if the data subject considers that the processing of personal data relating to him or her infringes this Regulation. However, the DPA from the company's country would be designated the lead supervisory authority for this investigation. If multiple DPAs are involved, they would coordinate with each other. There is no EU body that you could contact directly. But if the different DPAs have a dispute regarding this investigation, the EDPB would provide a consistency mechanism. This mechanism has been used in the past e.g. to force the Irish DPA to correctly apply the GDPR against companies from the Meta group, like WhatsApp and Instagram. Though it might slow things down, it could be advantageous to have multiple DPAs involved, precisely so that the investigation is double-checked. If the lead supervisory authority declines the case, this would also enable the other DPA to do its own investigation. So, it would be a good idea to lodge a complaint with the DPA of your home country, and let it forward the issue to other DPAs as needed. However, contacting the DPA in the company's country would also be fine, especially if you are fluent in the relevant official language, and/or if you live in Ireland.
Are my assumptions correct? Yes, this is precisely the sort of thing that would fall under the purview of "the purposes of the legitimate interests pursued by the controller or by a third party", as it fundamentally enables you to deliver the service to the data subject, and its also difficult to argue that "such interests are overridden by the interests or fundamental rights and freedoms of the data subject" given its a fundamental part of delivering the service before any consent can be given. Its not the intention of the GDPR to solely require a direct relationship between the data controller and data subject, its intention is to allow the data subject to control more of the relationship than they did previously - in some cases, that control remains with the data controller, which is why not all of the lawful basis for processing rest on consent. So long as you ensure that the CDN provider has a relevant privacy policy and is identified as a data processor in your privacy and data policy then you are good to go. In my mind, this is similar to the issue of how the data subjects packets get to you from their computer - we aren't including all of the network providers who carry the packets between the data subject and the processor (despite the fact that those providers will have access to much of the same information as the CDN, such as IP address, source, destination etc), even though in many cases we don't know that information (for example which route it will take over the internet). The only difference here is that as the data controller, you know about the CDN and can include it in your policies, so you should.
An app(lication program) is software run on the end-users machine. That does not fall under the GDPR. Any processing (including storage) you do on user data has to be compliant with the GDPR. Allows a user to authenticate via e.g. Facebook and stores some basic data (optional) Authentication via Facebook leaves GDPR compliance to Facebook (AFAIK). It would be a good idea to provide alternative authentication methods, such as Google and an "own account" user name and password so that the user doesn't have to share information with a multinational company in order to use your service. The "basic data" will need to be processed according to the GDPR. As long as the "optional" part is "opt in" (i.e. the user needs to at least click on something) then this means you have permission to process that data. Providing this "basic data" as a JSON or CSV file should meet data portability requirements. Allows a user to upload a GPX file (a route or some other activity) Stores the above file to Google's database Allows the user to analyze that file. Since the user is actively choosing to upload each file you have permission to do this. You should make it clear in your privacy policy that the data will be held by Google. Doing so should not be a problem as Google has set up the legal framework to do this under the GDPR. You don't have to store the information encrypted, but you should use encryption (e.g. HTTPS) for any data transmission. Allowing the user to analyse the file is not an issue; either the user is doing it on their own machine (GDPR irrelevant) or you are doing it under user instruction (meaning you have consent). Since the user has uploaded GPX files they already have data portability on those files. You should tell your users that while you will employ best endeavours you don't promise to keep their files accessible and they should maintain their own private copies. That way if your entire database gets corrupted they can't blame you for loss of data. Finally, make sure there is a "Close my account and delete all my data" option.
Under the GDPR, consent is not the only legal basis that allows processing of your personal data. Other legal bases such as legitimate interest exist as well. So the question is: does the company have a legitimate interest to send you these emails? The answer is that this case is more about direct marketing, less about personal data. The circumstances under which direct marketing emails can be sent are covered by the ePrivacy directive, which is implemented in the UK via PECR (Privacy and Electronic Communications (EC Directive) Regulations 2003). PECR and ePrivacy introduce a concept known as soft opt-in: where a natural or legal person obtains from its customers their electronic contact details for electronic mail, in the context of the sale of a product or a service, in accordance with Directive 95/46/EC, the same natural or legal person may use these electronic contact details for direct marketing of its own similar products or services provided that customers clearly and distinctly are given the opportunity to object, free of charge and in an easy manner, to such use of electronic contact details when they are collected and on the occasion of each message in case the customer has not initially refused such use. (ePrivacy Directive, Art 13(2)) In plain language, they are allowed to send unsolicited marketing emails to existing customers, under the following restrictions: this only applies to customer relationships the marketing must be for similar products or services you must be able to object to further messages, i.e. unsubscribe upon collection of contact details you were given the opportunity to opt out