GDPR: Is giving out customer name and implied existence of customership legal? I'm an employee (software developer) for a company that acts a data processor, and the company that is a client and data controller has requested a feature that I find questionable. The purpose is to provide a client terminal inside a point of business that would function as follows: The customer arrives to the shop, the customer presses 'Start' button on a touch screen, enters her phone number, after this she is to be shown a greeting that includes her given name, customer selects what services she wants in order to complete the service order, and customer is called out by her given name when she is to be serviced. My assumption is that should not be done, and if not illegal, then this would be at least seen rather bad manners. My assumption is based on the fact that the personal data (given name, existence of customership) may be handed to someone that has no legal right to see that data, and it might be impossible to name that person later on if needed. As far as I can see it, if someone enters her phone number incorrectly, or for some reason enters a phone number that belongs to someone else, then it is possible that the given name belonging to someone else is shown. Also due to the location (population 5,5 million), some foreign given names can be rare to such extent that they are unique within the country. Since the phone numbers are recycled, it might be possible that a new customer sees the given name of previous owner of the number if the previous owner has also been a customer. I doubt there is any other possible harm to customers expect possible loss of privacy that doesn't cause tangible damage, the services provided are not associated to sensitive matters. So, is giving out customer name and implied existence of customership legal? Edit 1 The phone number in question is probably expected to be a personal mobile phone number. It should be possible to verify that a phone number is a mobile phone number. I don't know if people sharing a mobile phone has been taken in to consideration.
Art.5(1)(f) contains: Personal data shall be: (f) processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’). Art. 25 and Art. 32 also contain similar requirements. What is appropriate has to be determined, as the GDPR does not contain an exact definition. However as processor you don't have to worry about that, as Art.5(2) Contains: The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 (‘accountability’). But you need to inform the controller if you think an instruction violates the GDPR. But it is up to the controller to decide what to do. Art. 28(3) requires a contract between controller and processor which requires the processor to: (...) that the processor: (c) takes all measures required pursuant to Article 32; (h) makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller. With regard to point (h) of the first subparagraph, the processor shall immediately inform the controller if, in its opinion, an instruction infringes this Regulation or other Union or Member State data protection provisions. But again, the controller is responsible for this contract.
There is nothing in the GDPR requiring you to collect individual personally identifiable information. If the website has no need, and the website owner no desire, to collect such information, there is no requirement to do so. The GDPR requires that if such information is collected, that there is a lawful basis, and that it be handled appropriately and stored securely, and deleted when there is no longer a need to retain it, or on a proper request. If no such information is collected in the first place, all the rules about how to handle it do not apply. It is possible that some law of an individual country in the EU might mandate collection of some particular information, but I have not heard of any such requirement.
In Germany it's not so clear: https://www.lfd.niedersachsen.de/themen/datenschutz_im_kfz/kfz-und-datenschutz-148981.html The situation is different with regard to personal data collected in connection with the vehicle. Data is personal if it relates to a "specific person" or at least to an "identifiable person". A person is "identifiable" if, for example, he or she can be identified via the vehicle identification number or other additional knowledge. The Federal Data Protection Act (BDSG) therefore applies in these cases. The BDSG in turn contains a clear statement: the data "belong" to the data subject. Related to the motor vehicle: The data "belong" to the driver or owner of the vehicle.
This might be based on a misunderstanding of the GDPR. The GDPR applies under three circumstances: Art 3(1): you (the data controller) are established/live in the EU. Art 3(2)(a): you offer goods or services to people in the EU. Art 3(2)(b): you monitor behaviour of people who are physically in the EU. What is not a factor: what citizenship your site visitors have (see Recital 14). whether your site can be accessed from the EU (see Recital 23). The crucial part is what “offering of goods or services” means. The EDPB has issued official guidelines on the interpretation of this targeting criterion (guidelines 03/2018 on the territorial scope of the GDPR). Some important notes: The offer of goods or services does not have to involve any compensation. Gratis access to a website can also be a service. GDPR applies when targeting people currently in the EU. US tourists in the EU are protected, EU tourists in the US are not. The moment of offering the service matters. E.g. a US person using an US service cannot claim GDPR protection against the US service while travelling to the EU. Instead of looking at the users of the service, we should look at the target market of the service: if the service doesn't cater to people in the EU, GDPR doesn't apply. The essential question is whether the provider of the service “envisages” offering services to people in the EU. Does the service provider intend for EU data subjects to use the service? The guidelines assemble a non-exhaustive list of indications from case law, in particular the Pammer and Alpenhof case. An excerpt of indications that GDPR might apply: the EU or member states are mentioned in the offer of services the website has marketing targetted at an EU audience the activity at issue is of international nature, e.g. tourism mentioning special contact details for the EU market using a top-level domain name associated with the EU or member states travel instructions when visiting from the EU mentions of an international clientele including people/companies from the EU use of a language or currency other than yours offering delivery of goods to the EU So whether GDPR applies would depend on the subject matter of your website, and on whether you intend to participate in the EU market (even if only online, even if your service is gratis). If GDPR were to apply, then blocking people from the EU would be questionable. It might also be illegal, but not on GDPR grounds. If GDPR does not apply, then blocking people from the EU is already unnecessary. However, geoblocking would be a very strong indication that you don't intend to offer your services to people in the EU. There is no good case law on whether geoblocking is necessary or sufficient. I assume that geoblocking is sufficient (even if it can be easily circumvented e.g. with a VPN), but that it's not necessary in the first place. You could also re-emphasize that you're not targeting the EU market when considering the above indications. E.g. a web shop might clarify that they only ship to North America, but not internationally. Again: your targeting of your website is the crucial factor, not the origin of your visitors. So even if there is an occasional EU visitor, that doesn't mean you have to comply with GDPR.
The term in your question, "use an existing name", is pretty broad. Do you propose to say, "Compatible with Microsoft Lync"? Or will you actually name your product "Lync"? The first option is likely safe. The second one looks like a Trademark infringement more than a copyright issue. And "Lync" is distinctive enough, you probably won't win. However, if you propose to name your product "Messenger", you're slightly better off because "messenger" is a generic term in the English Language, even if Facebook adopted it for their product. The major criteria would be if your chosen name is likely to cause confusion with Facebook's product.
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.
The consent presented in the question is a text-book example on how to not secure consent under the GDPR. The GDPR requires concent to be explicit, specific, freely given, and informed. This particular privacy policy does not measure up to any of these requirements. The GDPR goes to great lengths to regulate consent. For instance, in Article 7 (2) is says: Any part of such a declaration [of consent] which constitutes an infringement of this Regulation shall not be binding. So if the consent obtained is not explicit, specific, freely given, and informed, and the company relies on consent to ensure lawfulness of processing, it is breaking the law (and may be fined under the GDPR). The big problem with this privacy policy is this sentence: Your continued access to or use of any of the Services shall be deemed your acceptance of the Privacy Policy. As you've noted, the GDPR requires consent to be explicit. What "explicit" means is spelled out in Recital 32, which (among other things) says: Silence, pre-ticked boxes or inactivity should not therefore constitute consent. And Recital 32 goes on state that consent must be specific: When the processing has multiple purposes, consent should be given for all of them. The full privacy policy lists 16 different purposes for which personal data is collected, but do not seek specific consent for any of them. Consent under GDPR must also be freely given. Recital 42 says (among other things): Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment. Here the company states that continued use of the service "shall be deemed your acceptance". The only way the data subject can refuse consent is to not use the service, which is to the detriment of the data subject. This also makes the consent invalid. Finally, the GDPR also requires consent to be informed. What this means is spelled out in Recital 42, which (among other things say): For consent to be informed, the data subject should be aware at least [...] the purposes of the processing for which the personal data are intended. Here the data subject is supposed to consent to some unknown, future change which may be to allow different purposes of the processing. This also invalidates the consent.
Privacy against publication of criminal convictions has been considered in the High Court in NT1 &amp; NT2 v Google LLC [2018] EWHC 799 (QB), if I may run the risk of posting a legal citation myself. But note that the claimaints there are anonymized, as often happens in criminal trials as well. In some cases, the court may give an injunction against disclosing names or details, and can hand down both a public and a private judgement, with the latter being a restricted document that does have the identifying details. So this question could only apply to mentions of criminal process where the accused is actually identified. (And I think just saying &quot;R v Smith&quot; is not enough - the posted or linked text would have to give some identifying detail about which Smith it is, the nature of the crime, etc.) I have no qualms at all about talking about NT1 and NT2. The claimants brought a case against Google for making available information about their long-spent convictions, including on GDPR grounds although it took place just before the implementation of GDPR in UK law. Dealing with that argument under the prior legislation, the judge found that of the various exemptions claimed by Google, the condition The information contained in the personal data has been made public as a result of steps deliberately taken by the data subject. (found in the Data Protection Act 1998, Schedule 3, paragraph 5, implementing the Data Protection Directive that preceded GDPR) applied, because of a longstanding principle for criminal conduct. The idea is that (paragraph 111): A person who deliberately conducts himself in a criminal fashion runs the risk of apprehension, prosecution, trial, conviction, and sentence. Publicity for what happens at a trial is the ordinary consequence of the open justice principle [...] The same must be true of the details of the offending, and other information disclosed in open court, including information about himself which a criminal reveals at a trial or in the course of an application. The core principles are the same as the carve-out from defamation law for the fair and accurate reporting of criminal proceedings (paras 44-49). That &quot;made public&quot; condition can now be found in a slightly different context in the Data Protection Act 2018, Schedule 1, Part 3, paragraph 32, which mirrors Article 9(2)(e) of the GDPR for the purpose of Article 10: This condition is met if the processing relates to personal data which is manifestly made public by the data subject. Since this is virtually the same condition of European provenance, in the same context of surrounding rules, I think the precedent is a good guide. For courts themselves, law reports, and journalism or scholarship, there are other specific grounds to rely on. Individual Stack Exchange posters are surely covered under the general exemption for posting on social media in a private capacity, GDPR 2(2)(c) as interpreted through its Recital 18. For the site itself, as in the case of NT1 and NT2, there could well be a legal claim made about the inclusion of criminal conviction information in a posted answer. (In general, such a post, being free text, could contain all sorts of defamatory statements or other objectionable content.) The court would have to look at the competing interests and the level of harm. NT1 was not successful but NT2 was. The example scenario, where we are talking about a very brief mention of a criminal case, cited because it illustrates a legal point rather than because there's anything relevant about the person mentioned, is quite far from the grounds complained of by NT2. For NT2, there was a newspaper article in which he was &quot;quite inappropriately, portrayed as one of a rogues' gallery of serious criminals&quot; (para 188), eight years after the end of his sentence, and it was this that he wanted removed from search results. In particular, the academic exemption (para 13) seems strong, in the same way that it would be for a publisher of legal academic content. The test of &quot;substantial public interest&quot; does not apply, because this exemption comes through paragraph 36 in the case of criminal convictions; it's enough to show a reasonable belief that publication would be in the public interest. Google was not able to rely on the &quot;journalism&quot; version of this exemption (again, under the prior law) because they are a totally generic search engine for all kinds of data and purposes (para 100 of the 2018 judgement). The public interest test, and the accompanying &quot;legitimate interest&quot; for the data controller, do not seem too difficult in this example.