Are push tokens considered PII under the GDPR or the CCPA? I'm building a server for an app and I'm trying to get my privacy protections right. The app allows users to opt in to push notifications. If the user opts in, then I save a push notification token to later send notifications to that user on my server. Are such push notification tokens considered to be personally identifiable information under the GDPR or the CCPA? It seems to be it could be yes because the token can be used to push messages to a user (like a phone number or email address), or no because it only identifies a device and not a human being.
Yes, but it doesn't matter. This answer discusses gdpr implications. Personal data is any information that relates to an identifiable person. The GDPR has an extremely broad concept of identifiability, also covering indirect identification using additional information and with the help of third parties. Even just being able to single out one data subject, i.e. being able to distinguish different users from another, counts as identification. If you already have a concept of user accounts, any information that is linked with the user accounts and somehow relates to those users would also be personal data. Since you have distinct push tokens per user, it seems like this criterion would be met. Additionally, those unique tokens might be directly identifying by themselves. The GDPR does not allow for semantic games like “it only identifies the device, not the user”. The key here is that the definition of identifiability does not hinge on your intentions, but on objective capabilities: if you or someone else who can come into possession of this data were to attempt to identify the user (such as singling out users from another), would they be reasonably likely able to do that? Since most devices are single-user, being able to identify a device would imply that you're reasonably likely to also identify users. Just because something is personal data doesn't mean you're forbidden from using that data. It means that you'd have to comply with GDPR rules, if you're otherwise within scope of that regulation (e.g. if you're EU/UK-based, or are targeting your services to people who are in UK/EU). For example, basic GDPR compliance steps include having a clear legal basis for your processing of personal data (such as necessity for performing a contract to which the data subject is party, or necessity for a legitimate interest, or consent), providing a privacy notice, and taking appropriate technical and organizational measures (TOMs) to ensure the compliance and security of processing. For example, TOMs regarding these push tokens could involve encryption, access controls, and a plan for installing security patches in order to prevent data breaches. Using push tokens is already a good measure in this context, since they are effectively pseudonymous and prevent linking additional information via that token (two sites/apps pushing notifications to the same person will have entirely different tokens). However, the push notification provider (e.g. Google, Apple, Mozilla) can resolve the pseudonymous tokens and link them to a person, indicating that these tokens are ultimately identifying (even if you can't perform that linking yourself). Note that if GDPR applies, then other EU/UK rules might apply as well. For example, sending electronic messages (such as emails) is subject to anti-spam rules (EU: ePrivacy, UK: PECR). These rules apply regardless of whether personal data is involved. Since the rules are not technology-specific, it is likely that regulators would consider user-visible push notifications to be equivalent to more well understood technologies like email and SMS.
Most likely yes if you are subject to UK or EU laws: The EU ePrivacy directive and implementing laws such as PECR in the UK require that you obtain consent before accessing information on a user's device, unless that access is strictly necessary to perform a service requested by the user. Cookies and similar technologies such as LocalStorage are stored on the user's device. Analytics are not strictly necessary to display a website. Thus, you need to obtain valid consent before setting any analytics cookies. GDPR and ePrivacy/PECR have some interactions: Even though the cookies might technically be set by GoSquared, you as the website operator are responsible for compliance. You are the data controller, the third party analytics are usually a data processor who only process data on your behalf. You must ensure that the data processor is compliant. Even if they were a joint controller you'd be responsible for what happens on the website (relevant precedent is the Fashion ID case). While ePrivacy originally had a fairly weak concept of consent (e.g. “by continuing to use this site, you consent …”). However, the GDPR updated the definition of consent, so that valid consent must be freely given, informed, actively given, and specific. If you set cookies for different purposes in addition to analytics, users should be able to give or withhold consent for analytics independently from other purposes. Since consent must be actively given, consent is never the default, e.g. pre-ticked checkboxes are not compliant (relevant precedent is the Planet49 case). Like Google, GoSquared stores data in the US. You are causing personal data to be transferred into the US, which is an international transfer. Before it was invalidated earlier in 2020, such transfers were easy to do under the Privacy Shield adequacy decision. Now, such transfers are only legal if you sign SCCs with your data processor, and your risk assessment indicates that your user's data is sufficiently safe there, despite your processors potentially being legally unable to comply with the SCCs. Fortunately for you the UK's ICO has taken a more industry-friendly stance on this matter than other countrie's data protection agencies. Why do so many websites use Google Analytics (GA) without requesting proper consent? A variety of potential reasons: They are actually non-compliant. After all, GA is not GDPR-compliant in default settings, and Google doesn't do a good job of providing essential information. Many data protection agencies have indicated that cookie consent enforcement is not their focus. GA can be used without using cookies/LocalStorage/…, and thus without requiring consent under ePrivacy or PECR. The websites might not be subject to EU or UK laws such as ePrivacy.
I don't think you would be responsible for whether your software is used in a GDPR-compliant manner. For GDPR compliance, it is important who the data controller is. The data controller is whoever determines the purposes and means of a personal data processing activity, i.e. the why and how. The data controller alone is responsible for their GDPR compliance. When a data controller wants to run some software, it's the data controller's responsibility to ensure that this software is used in a GDPR-compliant manner (or possibly not at all). Determining purposes and means of processing When someone other than the developer runs a software, the question is who might be a controller: you as the developer, they as the operator, or neither, or both? The operator is clearly a controller: they determine a purpose for data processing (e.g. to manage staff) and have determined means to perform that processing (e.g. to use the software). The developer may or may not be a controller. Clearly, the developer has made choices about how the processing of personal data will be performed, i.e. has determined some means of processing. E.g. the developer has developed a particular architecture, chosen a way to store personal data, and has implemented some security measures. But determining some means is not sufficient to be a data controller, see discussion below. Has the developer participated in determining the purposes of processing? I think this will depend on the specific functionality provided by the software in question. If the software just does what it says and processes the data for the operator's purposes, everything should be fine. If the software also processes data for the developer's purposes, that developer might be a controller. For example, if analytics or crash reports are collected by the developer, that would be a clear indication that the developer would be a (joint) controller. So depending on specific factors, the operator might be the sole controller, or the operator and developer might be joint controllers. Essential vs non-essential means What about the developer determining some means? When does this make the developer a joint controller? The EDPB has created a theory of essential vs non-essential means: 40. As regards the determination of means, a distinction can be made between essential and non-essential means. “Essential means” are traditionally and inherently reserved to the controller. While non-essential means can also be determined by the processor, essential means are to be determined by the controller. “Essential means” are means that are closely linked to the purpose and the scope of the processing, such as the type of personal data which are processed (“which data shall be processed?”), the duration of the processing (“for how long shall they be processed?”), the categories of recipients (“who shall have access to them?”) and the categories of data subjects (“whose personal data are being processed?”). Together with the purpose of processing, the essential means are also closely linked to the question of whether the processing is lawful, necessary and proportionate. “Non-essential means” concern more practical aspects of implementation, such as the choice for a particular type of hard- or software or the detailed security measures which may be left to the processor to decide on. – EDPB guidelines 07/2020 on the concepts of controller and processor in the GDPR, added formatting for legibility Looking through that list of essential means, some might be determined by a software's developer, but I wouldn't expect this to be the case for this kind of open source software. types of personal data: the software certainly sets a framework for processing specific kinds of personal data, e.g. by providing database fields for names, contact details, and schedules. But ultimately, the developer does not control which data is actually collected and filled into those fields – the developer does not cause specific kinds of personal data to be processed with the system. duration of processing: unless the software is programmed with a fixed retention schedule, it should be impossible to argue that the developer has determined the duration of processing. Even then, it would also be the operator who has determined this duration to be appropriate, rather than editing the open-source software to change the duration. But typically, no such retention schedule is enforced, and retention would depend solely on the operator (who can use an admin interface or a database console to erase old records). categories of recipients: typically, the developer does not determine to whom the data in the system will be given. But if the system sends data to third parties by itself, this might change. For example, if the system is pre-configured to store data in an existing cloud database instance, or to a specific analytics server, the developer might be acting as a controller. Here, good software engineering and legal risk minimization coincide. Best practices for web apps state that account credentials and connection strings shouldn't be hardcoded or committed to a repository, and should instead be provided externally (e.g. via environment variables). categories of data subjects: this depends solely on how the software is used. The developer has no way to determine whose data the operator will enter into the system. If the developer isn't a controller, might they be a data processor instead? In a GDPR context, a data processor is whoever processes personal data on behalf of a controller. The developer is clearly not a processor in this scenario because both the “processing” and “on behalf” criteria fail. The developer has no access to the data in the operator's instance, so cannot process the personal data. There is no direct relationship between the developer and the operator. The operator has not delegated authority to the developer so that the developer would be acting “on behalf” of the operator. There is a legal relationship between the two roles (the developer has licensed the software to the operator) but that is entirely irrelevant in a data protection context. The GDPR isn't directly about cookies While the GDPR does cover how personal data can be processed with cookies, the famous “cookie law” is actually separate: those cookie consent requirements stem from EU member state's implementations of the ePrivacy directive. Instead of talking about “controllers”, ePrivacy has concepts such as the “provider of an information society service”. While this role fits perfectly to an operator/provider who runs a web app in a publicly accessible manner, it does not fit a developer who merely makes some source code available. Is the developer even subject to the GDPR? The GDPR can only apply to data controllers and processor who process personal data. As discussed above, the developer is probably not processing personal data at all. Even if the developer were processing personal data, it is questionable if GDPR would apply assuming the developer has no “establishment” in the EU (e.g. an office). Then, the question would be whether those processing activities are either related to offering goods or services to data subjects in Europe, or whether the processing activities involve monitoring the behavior of people who are physically in Europe. Unless the developer is actively targeting European businesses with marketing for this software, the answer is very likely “no”. Could the operator sue the developer for providing software that isn't GDPR-compliant? The operator can sue anyone for any reason, but is probably not going to win. As discussed, the operator is a data controller. They are responsible for ensuring that their purposes and means are GDPR-compliant. That involves selecting suitable software. The data controller would be neglecting their own responsibilities if they just download some random software and start feeding personal data into it. Things might be different if the operator specifically advertises GDPR compliance features but you're not going to do that. It's also worth noting that common open source licenses like the Apache License 2.0 include a warranty and liability disclaimer. To which degree they protect the developer ultimately depends on national laws, but they make it difficult for the operator to make a legal argument that they're entitled to a GDPR-compliant product. See also the related question: Do warranty disclaimers in software licenses carry any legal weight? What can you do? First, don't worry too much. Given how much bad software there is on the internet, surprisingly few developer get into legal trouble for writing source code that's buggy or missing some features. Second, consider choosing a license for your project that includes a reasonable warranty/liability disclaimer. Third, make the state of your project clear in your README file. If someone knows that this is alpha-quality software and that no compliance features were implemented, it's their own fault if they actually use that software.
Think of a website that has gives no option for the users to delete what they have posted -but still the users can delete their account completely. That's easy - this is exactly how all StackExchange sites (including this one) work :-). See for example: How does deleting work? on meta.SE. Is it against the right to erasure mentioned here as a part of GDPR? No, it is not (otherwise StackExchange would be in rather big trouble). The "right to be forgotten" is subject to limitations. Most importantly, it only applies to personal data. Personal data is defined as (GDPR, art.4): any information relating to an identified or identifiable natural person (‘data subject’) If what you posted contains no personal information about you, it is not "relating to" you. The details are complicated (as usual, see e.g. The GDPR: What exactly is personal data?), but "personal data" is things about you (your name, your address, your sexual history, maybe even your IP address). On the other hand, if someone asks how to solve a programming problem, and you write an answer explaining what API to call, that answer is not personal data. In addition to that, even personal data may be retained if the data controller has a need to retain that information. This is also covered in article 4. For example, the controller may retain information "for the establishment, exercise or defence of legal claims" - otherwise you could buy something online without paying, and then ask the seller to forget about your purchases so they cannot collect the outstanding payment. So, in summary: A website will need to allow users to delete or hide personal data that they posted - such as their user profile information, or personal information in their posts. That does not mean they are allowed to delete entire posts - it is enough if personal information is redacted or anonymized. The website may be allowed to retain that information (hidden) if they can show legitimate interest - for example billing information, or posts that are the subject of a lawsuit. The StackExchange network, for example, covers this by allowing users to: disassociate posts from their account delete their account entirely (thus effectively disassociating all posts from personal information) asking a moderator for redaction of personal data
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.
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.
The ePrivacy Directive Cookies are governed in the EU by the ePrivacy Directive which was first passed in 2002, and revised in 2009. However, if a site places a cookie, and later reads the cookie and stores an indication of the cookie content, this may be personal information and thus also subject to GDPR rules. (Other privacy laws, such as the CCPA, may also impose requirements on cookie use, when they apply.) Note that the so-called &quot;EU cookie law&quot; is a directive and not a regulation. This means that it is up to the various EU countries to implement it in their national legislation, and different countries may implement it in different ways. It would be the actual laws in individual EU countries that would be binding on website operators, and I am not going to try to find and analyze all the various laws on the topic. Paragraph 25 of the directive (linked above) reads: However, such devices, for instance so-called &quot;cookies&quot;, can be a legitimate and useful tool, for example, in analysing the effectiveness of website design and advertising, and in verifying the identity of users engaged in on-line transactions. Where such devices, for instance cookies, are intended for a legitimate purpose, such as to facilitate the provision of information society services, their use should be allowed on condition that users are provided with clear and precise information in accordance with Directive 95/46/EC about the purposes of cookies or similar devices so as to ensure that users are made aware of information being placed on the terminal equipment they are using. Users should have the opportunity to refuse to have a cookie or similar device stored on their terminal equipment. This is particularly important where users other than the original user have access to the terminal equipment and thereby to any data containing privacy-sensitive information stored on such equipment. Information and the right to refuse may be offered once for the use of various devices to be installed on the user's terminal equipment during the same connection and also covering any further use that may be made of those devices during subsequent connections. The methods for giving information, offering a right to refuse or requesting consent should be made as user-friendly as possible. Access to specific website content may still be made conditional on the well-informed acceptance of a cookie or similar device, if it is used for a legitimate purpose. This should mean, if implemented straightforwardly, that cookies, beyond those absolutely essential to the operation of a site, can only be placed if a user is notified of the intention to place them, and freely consents. This can be done once per user, on an initial session. Users are supposed to be provided with provided with &quot;clear and precise information&quot;. I do not think a simple statement that the site uses cookies fulfills this. At the very least the purposes for which cookies will be used should be provided. The directive does not make clear what level of detail about individual cookies such a notice must provide. The notice described in the question neither describes the purpose of cookie placement, nor does it offer any meaningful choice to accept or reject them. As such, I do not think it would be compliant with the directive. If cookies are read back (which is after all pretty much the point of having them) and can be potentially identified with an individual, then under the GDPR (article 6) there must be a lawful basis for processing them, and the interaction above would not be enough to establish consent as a lawful basis. There might be some other basis that does not require consent, however. Interpretations from others This page from cookiebot explains some of the history of the directive, and how it contrasts with the GDPR (which is a regulation, and so is directly applicable without the action of national legislatures). This page from The Verge discusses recent changes in the directive and the guidelines for applying it, and criticizes how it has been complied with, and ignored, by many sites. Cookies and the GDPR This page, &quot;GDPR, and the ePrivacy Directive&quot;, from GDPR.EU says: ... cookies, insofar as they are used to identify users, qualify as personal data and are therefore subject to the GDPR. Companies do have a right to process their users’ data as long as they receive consent or if they have a legitimate interest. Passed in the 2002 and amended in 2009, the ePrivacy Directive (EPD) has become known as the “cookie law” since its most notable effect was the proliferation of cookie consent pop-ups after it was passed. It supplements (and in some cases, overrides) the GDPR, addressing crucial aspects about the confidentiality of electronic communications and the tracking of Internet users more broadly. To comply with the regulations governing cookies under the GDPR and the ePrivacy Directive you must: Receive users’ consent before you use any cookies except strictly necessary cookies. Provide accurate and specific information about the data each cookie tracks and its purpose in plain language before consent is received. Document and store consent received from users. Allow users to access your service even if they refuse to allow the use of certain cookies Make it as easy for users to withdraw their consent as it was for them to give their consent in the first place. That page also describes the proposed ePrivacy Regulation which, if passed, will replace the current directive, and links to drafts of it. Conclusion The site described in the question probably does not comply with legislation implementing the ePrivacy directive. Depending on where it is hosted and targeted, and what it does with cookies that it sets, it may fail to comply with the GDPR as well. There has been very little enforcement of the directive so far. This may change in the future, particularly if it is replaced by a regulation, as has been proposed.
Alice's business sells database management software. Organisations buy or licence the software, deploy it on hardware they control and use the software to help store and, process and analyse 'personal data' within the meaning of GDPR. Alice's business has no access whatsoever to the personal data being stored and processed by those organisations. In respect of that personal data, GDPR is not engaged by Alice's business. The business is neither a 'controller' nor 'processor' of that personal data. Who does the data protection law apply to? - European Commission Who does the UK GDPR apply to? - Information Commissioner's Office