Android Application: Is purchaseToken defined under GDPR as PII? In our Android application user is allowed to buy subscription. From code we are retrieving his purchaseToken (using this API ) and saving purchaseToken on our server to validate his license. According to documentation on above page "purchaseToken" is defined as "A token that uniquely identifies a purchase for a given item and user pair". From my side as developer: we cannot get exact user who purchased this item based on purchaseToken. Google does not provide such possibility (no API for this). But in theory – if somebody has token + access to Google database – he can identify user exactly. So the question is: For me as Android Developer, is "purchaseToken" identified as PII (Personally Identifiable Information) or not? The question is important, because depending on if it is true or false I have to inform user or do not inform about that.
IANAL, But the information commissioners office (UK) describe personal data as: (bolding mine) The GDPR applies to ‘personal data’ meaning any information relating to an identifiable person who can be directly or indirectly identified in particular by reference to an identifier. This definition provides for a wide range of personal identifiers to constitute personal data, including name, identification number, location data or online identifier, reflecting changes in technology and the way organisations collect information about people. https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/key-definitions/ So I would say that in your case it is personal information. In principle, regardless of if you can identify an individual, personal data is that which can be used to potentially identify an individual. For an extreme example of why this is important: Lets say your app sells AIDs medication. Can a hacker who got in and stole your database, be able to use that with information they stole elsewhere to identify people with AIDs and blackmail them, in a way that they wouldn't if you had not stored this identifier? Plus, if you want to err on the side of caution, there's no legal penalty for telling the user about non-personal information you store.
Art 13 GDPR is about information to be provided when data is collected directly from the data subject. This information can be provided directly during/before collection. It is not generally necessary or useful to send the data subject an email with this information. Usually, a SaaS website will provide the information under Art 13 as part of their privacy policy, and link it in easy to find places. Also consider the EDPB guidelines on transparency, which suggests a layered approach: in addition to a detailed privacy policy, summarize key information directly when the data is collected, e.g. next to an input form.
There are two &quot;cancellations&quot; here. There is a contract between the customer and the company. This contract was ended. Also, as part of GDPR obligations, the data of the former customer was removed. Now the &quot;credit&quot; part suggests a pre-paid phone, which are often described as &quot;no contract&quot;. Legally this is incorrect. There is a contractual obligation for the phone company to deliver phone services (typically expressed in minutes of call time, # of text messages and/or MB of data). Now the pre-paid contract with high likelihood had a clause which dealt with inactive accounts. For instance, the minutes of call time may expire after 5 years. A &quot;credit&quot; that has not been converted to minutes, messages, or megabytes may also expire. When this happened, the company might need to keep the customer data on their records for two more years (for legal reasons), so the 7 year period does not sound weird at all. As soon as the legal reason to retain the data has ended, the GDPR indeed states that the data should be removed. That act is not connected to the credit expiring years before.
I'm pretty sure that under GDPR, you can indeed request them to send all data they have on you. If it's a complex request, they may charge you something like £10. If they have a lot of data on you, they may list the categories of data they have and ask you to pick one, rather than them having to collect and send everything. They should respond within one month, but iirc in the UK implementation, they can inform you (within that month) that they will respond within three months instead. For the rest, I only know current Dutch law. GDPR is not that different from what we already had (in general terms) and in many cases it even extends it. Under our law (WBP), you can also request a correction of the data in case it is incorrect, or deletion if they no longer need it for the purpose for which it was collected and stored. I don't really know how that works out in practice though, as Facebook can of course claim that "being able to connect you to your friends when you sign up for WhatsApp or Facebook with that number" is a legitimate purpose (in their eyes). They might also not have your full name and therefore not be able to connect your data to your request. Or, perhaps, they have only your full name (and there are probably more people with your name), so they'll have a hard time verifying that it's really your data which they would be handing over or deleting. The company is required to verify your identity before acting on your request. How they implement that is up to them. Under Dutch law, if I remember correctly, any data that can be connected to your person by any party is personally identifiable information (PII). While Facebook might not be able to find who's behind a phone number, your carrier most certainly can. Therefore, the data falls under PII protection laws and they will have to implement a way to verify you and get you your data. Finally, whether your local laws apply to Facebook, I don't know exactly. There's lots of information on this though, so you should be able to find it. Generally, countries say that if something happened within their territory (e.g. you signed up for WhatsApp while in the UK), their law applies. Companies, I've read, will instead try to claim that their main office is in SomeCountry and therefore SomeCountry's laws apply. But I'm pretty sure you'll be able to find a Facebook office somewhere where GDPR applies, so that's probably fine. While not an exact answer and while I am not sure about everything, I hope this gave you some pointers to go on!
These kinds of cookie banners are typically noncompliant and useless since they are not clear and provide too little information to users. Careful: blocking a user who declines consent is usually a GDPR violation! Instead, only those aspects of the site that rely on this consent should be disabled. When cookie consent is needed Per the EU ePrivacy directive (PECR in the UK), information society services (websites, apps, …) are only allowed to store or access information on the end user's device if one of the following holds: the access or storage is strictly necessary for performing a service that was explicitly requested by the user; or the user has given consent Note: there is no “legitimate interest” exception for cookies. When is access/storage strictly necessary? For example, it is strictly necessary for a photography app to store photos on a device. It is strictly necessary for a website to store session cookies so that you can log in to the site. It is strictly necessary for an ecommerce site to store the contents of your shopping cart. It is strictly necessary to remember cookie consent status. And so on. It is not strictly necessary from the perspective of the user to have analytics cookies, ad personalization cookies, or cookies for features that the user doesn't actually use. Many websites that just provide the service the user expects will therefore not have to ask for cookie consent, even if they use cookies. It is worth noting that the ePrivacy definition is entirely technology-neutral. It doesn't relate specifically to cookies, but to any kinds of storage, including LocalStorage. Regulatory guidance considers any access or storage of information on the device to be in scope, even JavaScript APIs in a browser (for example to read the screen dimensions), and considers techniques like fingerprinting to be functionally equivalent and therefore subject to the same rules. It is also worth noting that these rules apply regardless of whether the information being accessed/stored qualifies as “personal data”. What consent is Consent is defined in Art 4(11) and Art 7 GDPR, and further explained in EDPB guidelines 05/2020. A defining feature of consent is that it must be freely given. The user must not suffer “detriment” for revoking or declining consent. And per Art 7(4): When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract. This disallows making access to a service conditional on unrelated consent. For example, it would not be permissible for a website to exclude users who decline consent for advertising cookies. But: The EDPB guidelines discuss that there can be “permissible incentive” for consent. For example, courts and some DPAs seem to be of the opinion that a subscription website can offer free access to users that consented to personalized ads: consent-or-pay-walls can be compliant, whereas consent-walls alone would not. Sometimes consent is really needed for a processing activity, in which case it is OK to block that service until consent is given. For example, websites should not load third party content like YouTube videos or embedded maps until consent is given to share personal data with the third party. The rest of the website should still work, though. If consent was not freely given, if the user didn't have an actual choice, then the consent is invalid. What should the data controller in your scenario do? The data controller should reassess the role of the cookies for which they are trying to ask for consent. If these cookies are strictly necessary from the user's perspective, then it is proper to inform the user about them – but this should not be confused with consent. It is my personal opinion that purely informational cookie banners are confusing/misleading and should be avoided, but this could also be argued differently. If these cookies are not strictly necessary, then the phrasing “We need to use cookies to provide you with our service” is quite misleading. It should be made clearer to the user that they can opt-in to additional services/improvements if they want to. The user should be able to configure this on a per-purpose basis. Thus, more compliant cookie consent flows will typically give the user three options: continue with only strictly necessary cookies/purposes (must be default behaviour if none is selected) consent to all purposes configure purposes For example, I'm fairly happy with the current Reddit cookie notice: Why this is a good notice: it explains the data controllers (Reddit and partners) it summarizes the purposes for which consent is sought it links to more detailed information the presented options “accept all” an “reject non-essential” are less ambiguous that “accept/decline” Comparing this with the list of minimum required information for informed consent in section 3.3.1 of the EDPB guidelines linked above, the following information is missing though: the identity of the “partners” what (type of) data will be collected and used the existence of the right to withdraw consent
No, it's not legal. The General Data Protection Regulations (GDPR) apply given that you are in the UK (regardless of where the Data Processor is based). The UK GDPR is slightly modified due to Brexit, but the same principles apply. The only plausible legal basis for this actions would be that you consent to it, and you're entitled to withdraw that consent at any time. Some may claim that Article 6.1(b) applies, i.e. that it's necessary to send marketing email in order to fulfil the contract, but GDPR is clear that bundling such consent into a contract for service simply to permit the data processor additional actions isn't allowed, as I'll demonstrate. UK GDPR requires that consent to use your personal information (in this case, your email address) for the stated purpose be freely given. Consent to use your information for direct marketing is not freely given if it's inseparable from the consent to use it for some other service, as per para 43: Consent is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, or if the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance. And Article 7.4 backs this up with When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract. The intent of Article 6.1(b) is that only the processing required for the service you have bought is allowed (e.g. if you supply your address for delivery of stuff you've bought, the data processor can use that address to send you the stuff, but is not allowed to add a contract term that allows them to send you unwanted stuff). Examples of emails that Article 6.1(b) would allow (in my assessment) include things such as notification of upcoming downtime, or a reminder that subscriptions are due, but not unsolicited advertisements for other products. There's a grey area that's open to interpretation, where adverts are piggybacked onto actual service messages.
It's really your client that should be asking these questions. Writing the app is perfectly legal. So you can enter a contract with that client to write the app and deliver it to them, ready to be put on the Google Play store or the App Store (entering a contract needs to be done carefully, obviously). I'd make 100 million percent sure that the contract states clearly that you have zero responsibility if the app is rejected or removed for non-technical reasons, and that the legality of actually selling and running the app is also not your responsibility. The reason is that I very much suspect that running the app might be illegal, and that the chances of getting it permanently on one of the stores are rather slim. And solving those problems is outside of what a software developer can competently do.
The "Contribution activity" is extracted from repositories hosted on Github. Looking at the privacy statement, Github considers itself as a hosting service for those repositories. See EU Directive 2000/31/EC Article 14 for the exact definition and conditions: Article 14 Hosting Where an information society service is provided that consists of the storage of information provided by a recipient of the service, Member States shall ensure that the service provider is not liable for the information stored at the request of a recipient of the service, on condition that: (a) the provider does not have actual knowledge of illegal activity or information and, as regards claims for damages, is not aware of facts or circumstances from which the illegal activity or information is apparent; or (b) the provider, upon obtaining such knowledge or awareness, acts expeditiously to remove or to disable access to the information. Paragraph 1 shall not apply when the recipient of the service is acting under the authority or the control of the provider. This Article shall not affect the possibility for a court or administrative authority, in accordance with Member States' legal systems, of requiring the service provider to terminate or prevent an infringement, nor does it affect the possibility for Member States of establishing procedures governing the removal or disabling of access to information. Article 2(4) GDPR defines that the GDPR does not apply (to Github) in this case This Regulation shall be without prejudice to the application of Directive 2000/31/EC, in particular of the liability rules of intermediary service providers in Articles 12 to 15 of that Directive. Extracting data from the repositories to create a nicely formatted contribution activity list, would still be considered hosting as defined at Directive 2000/31/EC, because Github does not (manually) redact or modify commits. So if you want to hide your contribution activity, you must delete the contributions. And you should not ask Github to do that, but ask the owners of the repositories. And they might have good reasons to deny your request. If an owner of a repository denies your request without a good reason, you can ask Github to do so. But Github would then probably deny that request, because they explain in their privacy statement that modifying the history is not possible: The email address you have supplied via your Git commit settings will always be associated with your commits in the Git system. If you chose to make your email address private, you should also update your Git commit settings. We are unable to change or delete data in the Git commit history — the Git software is designed to maintain a record — but we do enable you to control what information you put in that record. edit To further clarify why Article 14 of Directive 2000/31/EC applies, see case C-236/08 (Google v. Louis Vuitton) where the European Court of Justice clarifies the meaning of that article (ECLI:EU:C:2010:159): In that regard, it follows from recital 42 in the preamble to Directive 2000/31 that the exemptions from liability established in that directive cover only cases in which the activity of the information society service provider is ‘of a mere technical, automatic and passive nature’, which implies that that service provider ‘has neither knowledge of nor control over the information which is transmitted or stored’. Accordingly, in order to establish whether the liability of a referencing service provider may be limited under Article 14 of Directive 2000/31, it is necessary to examine whether the role played by that service provider is neutral, in the sense that its conduct is merely technical, automatic and passive, pointing to a lack of knowledge or control of the data which it stores. The way Github creates/shows the contribution activity is in my opinion technical, automatic and passive. That means it is not liable, and that implies that the GDPR does not directly apply, unless data is unlawful, and someone notifies Github of that: The restriction on liability set out in Article 14(1) of Directive 2000/31 applies to cases ‘[w]here an information society service is provided that consists of the storage of information provided by a recipient of the service’ and means that the provider of such a service cannot be held liable for the data which it has stored at the request of a recipient of that service unless that service provider, after having become aware, because of information supplied by an injured party or otherwise, of the unlawful nature of those data or of activities of that recipient, fails to act expeditiously to remove or to disable access to those data. Surely the GDPR might be the reason data is unlawful. But you need a reason, in particular based on Article 17 ("right to be forgotten"). For example if personal data of a 12 year old child is processed without permission of it's parent. Without such a reason the legitimate interest of the repository owner will probably prevail (who wants to keep the git history complete).