Is the creation of a cookie with a anonymous id a violation of GDPR even if it&#39;s not used until consent? We run a website with a global user base and need to respect GDPR compliance for those visitors that the law applies too. Since we are on Shopify we are currently making a front-end request to check the visitors GDPR profile and if they are in a non-applicable area, we then load tracking (GA, Optimizely, Heap, etc.). Unfortunately since Shopify only allows client-side manipulation, the call to check visitor GDPR requirements severely delays the JavaScript we need to run A/B testing without massive flicker. To avoid this with other clients we have loaded Optimizely upon landing, which creates the anon cookie, however, we configure this to hold all tracking/events until consent can be given. If it is not given the cookie is deleted and Optimizely is unloaded. Does this approach comply with GDPR? Note: Optimizely does not track any PII or full IP addresses.
The cookie consent requirement comes from the ePrivacy Directive, not from the GDPR. While the GDPR defines consent, cookie consent is required regardless of whether the cookie actually contains personal data. Instead, it says we can access information stored on an end users device under the following circumstances. Technical access to the information is used for the sole purpose of performing a transmission over a network, e.g. using a browser cache. Accessing the information is strictly necessary for providing a service explicitly requested by the user, e.g. session cookies or a consent-declined cookie. The user has given consent to the access, where consent is defined by the GDPR (freely given, informed, specific, …). The first scenario likely doesn't apply because your cookies aren't likely to be “technical storage or access” in the sense of ePrivacy, and because the tracking cookies wouldn't be used for the sole purpose of carrying out a transmission. The second scenario doesn't apply because tracking cookies are not strictly necessary to interact with the webshop, as evidenced by the possibility to opt out. The service explicitly requested by the user is the webshop or website, not the A/B testing. This only leaves consent as possible grounds for storing or accessing information on the user's device. It is already the storing or access that is covered by ePrivacy, not only later use as a persistent identifier. Your suggestion – to first set the cookie and then delete it if it shouldn't have been set – is more compliant than many set-ups I've seen, but is still technically non-compliant. It is also likely to fail in practice under non-ideal network conditions: if the request to see whether GDPR applies times out, or if the user closes the browser tab before the cookie will be deleted, the tracking cookie will remain without consent. I would instead suggest to consider the following points. It seems that by itself, Optimizely Web cannot be used in a compliant manner since it doesn't provide sufficient control over how cookies are managed. Thus, you should avoid loading such tracking scripts unless consent has been given, or unless this processing falls outside of EU/UK law. Currently, you defer loading of tracking scripts until you know if you have to ask for consent. This can be avoided if you always ask for consent :) This can also be avoided if you load the tracking scripts from a server that can independently determine whether the requests comes from the EU. For non-EU requests and for users with opt-in, the server can return the original tracking scripts. Otherwise, the server returns a dummy script. This server can be independent from your website's hosting. By combining the jurisdiction decision with the loading of the script, one roundtrip is saved and latency is reduced. Finally, no one is forcing you to use Shopify, and ePrivacy/GDPR is not required to accommodate their limitations. You do have different choices: use Shopify, at the cost of slow pages and limited A/B tests use a different A/B test provider that can be used without setting cookies use edge computing to do stuff in between of the browser and the original server use a different webshop platform ignore EU laws Well, one of them is clearly unethical. But you do have choices, and which choice you take is a business decision. Slow pageloads and consent banners are likely costing you conversions, but Shopify might be providing massive value that outweighs all that.
How to properly ask for consent is an evolving issue. Your general consent flow is very common, but I don't think it's entirely compliant. Legal background on consent Consent is one of the Art 6 GDPR legal bases for processing. The ePrivacy directive (ePD) also mandates consent for accessing information on a user's device, where such access is not strictly necessary for a service explicitly requested by the user. For example, this means that analytics cookies require consent. Consent is defined in Art 4(11) as: any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her Further conditions for consent are given in Art 7, such as that “It shall be as easy to withdraw as to give consent”. The EDPB guidelines 05/2020 on consent provide extensive interpretation of the GDPR that should be considered as effectively binding. First layer: accept / change preferences The first consent layer provides general information about the purposes that consent is being sought for. This seems to be mostly compliant, but I have some doubts. Consent must be freely given, and withdrawing consent must be as easy as giving it. I would therefore recommend having a “continue without consenting” option that is given roughly equal prominence to the alternatives. Consent must be informed. Even in the first layer, you must give basic information. In the EDPB guidelines, the following items are identified: controller's identity purposes of processing what type of data will be collected existence of the right to withdraw consent if relevant: that the data will be used for profiling/automated decision making if relevant: possible risks if international data transfers are made under Art 49(1)(a) I think this makes it difficult to collected an “agree to all” style consent that covers all purposes. It would be better to clearly distinguish between the analytics and advertising purposes even in your first layer. Consent must be specific to a purpose. You try to make this possible via a second layer where granular choices can be made. This isn't entirely bad, since you also need to make the consent flow simple enough as to avoid click fatigue. But since you only have two processing purposes, it would be better to show them separately on the first layer. You cannot generally make access to the app conditional on unrelated consent. The statement “This app uses tracking identifiers” suggests that there is no choice. It would be better to make it clear that the user can voluntarily consent to such processing. Together, this would mean that a design like the following could be more compliant. Text in [brackets] indicates buttons or links. Your privacy choices To support and improve this app, you can choose to give us access for the following purposes: Analytics: understanding how you use this app We would like to collect information on how you interact with the app, and store cookies on your device for this purpose. [more information] [decline / agree] More relevant advertising We will always show ads, but if you want we can build an interest profile to show you more relevant ads. [more information] [decline / agree] You can always change your choices in the app settings, but past use of your data remains legal after withdrawing consent. ExampleApp is provided by ExampleDeveloper Ltd. [full privacy notice] [continue] Second layer: detailed information about all services Your second layer sounds good, as it provides granular controls and more detailed information. As already mentioned, I would move some of this to the first layer. But one of your questions pertains to the defaults on this screen: It is OK if I set all of the options to enabled the first time that the user goes to the preference screen (enabled by default) ? No, this is not OK. Consent means opt-in, and requires an affirmative action by the user. You cannot have pre-checked checkboxes. The default is that no consent was given. If you have an “enable all” button, I would also expect a “disable all” button. Else, consent might not have been given freely. You also cannot rely on the consent until consent has been actually given. So you must not start collecting analytics in the background while the user is still on the consent choice screen. In addition to being non-compliant by itself, loading pre-ticked checkboxes increases the risk that your application accidentally considers the consent as already being given, which could easily lead to illegal processing if there's a bug in your app. You might have processing purposes that are based on a legitimate interest instead of consent. These can be enabled by default, but you generally have to make it possible for the user to object. Your relationship with third parties When using third party services, it is crucial to understand if they are a processor who is contractually bound to only use the data on your behalf, or a separate processor. You must disclose processors (or at least categories of processors) in your privacy notice, but not really during the consent flow. The GDPR does not distinguishing between doing processing activities yourself versus outsourcing them to a processor. In both cases, you are the controller, and only you are asking for consent. Thus, it's also superfluous to show third party privacy notices. It's your obligation as the controller to provide all necessary information. If you are collecting consent for other controllers with whom you have joint processing activities, you must make this much more prominently. You would have to disclose in the first layer that you are sharing the data with other controllers who can use the data for their own purposes. This sharing is part of the processing purpose. This is quite tricky to do correctly when it comes to ad networks, since ad networks generally won't be your data processor and can have many intransparent members. Demonstrating consent As the data controller, it is your obligation to be able to demonstrate that valid consent has been given. This implies process-level obligations such as being able to show that your consent flow is non-coercive and makes it possible to decline consent. This also implies individual-level obligations such as being able to show when a given user has given or withdrawn consent for which purpose. If you have a backend anyway, it could be sensible to store information there about consent/withdraw events. When the user returns to the consent management screen through the app settings, you could show a timestamp like “you consented to this purpose on 2021-08-22 17:14:23”. I have recently written a more detailed discussion about demonstrating consent.
The question says: But by hashing a IP address you process the personal information and that you can't do without the user's permission! But processing personal data (PI) is covered not by the e-Privacy Directive (ePD) but by the GDPR. Under the GDPR processing may be lawful if it is done under any of the six lawful bases specified by Article 6. Consent is one of these. But paragraph (f) permits processing when: processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject ... This is generally known as the &quot;legitimate interest&quot; basis for processing. It normally requires a balancing against the privacy interests of the data subject. Where, as here, the processing is specifically to remove any traceability of the subject, and hence to protect the privacy of the subject, there doesn't seem to be much conflict, so I suspect such processing would be lawful. I have not found, after a brief search, an actual case where this has been tested, so my conclusion might be mistaken. Personal Data under the GDPR and hashing GDPR Quotes Article 4 of the GDPR defines &quot;Personal data&quot; (in paragraph (1) as follows: personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person; The term &quot;pseudonymisation&quot; is defined in paragraph 5 of article 4 as follows: ‘pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person; GDPR recital 26 reads: The principles of data protection should apply to any information concerning an identified or identifiable natural person. Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person. To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. This Regulation does not therefore concern the processing of such anonymous information, including for statistical or research purposes. Hashing If a cryptographically secure hash function is used to convert an identifier, such as an IP address, into a replacement hash, there is no practical way from the hash value alone to recover the identifier. However, if a particular identifier value is compared with a stored hash value, it is easy to tell if there is a match. Finding a match does not prove that the identifier is the same -- depending on the length of the hash value being used and of the identifier, there may be many values that would give the same hash. But the chance of two random IDs having matching hashes is very small. Thus, if a controller were to store hashed versions of the IP addresses, no one could convert that back to a list of visiting IP addresses. But if soemoen had the IP address of a suspected visitor, and access to the hash function, it would be easy to check if that IP was on the list. If a keyed hash function were used, only someone with access to the key could perform this check. It is not feasible to hash all possible IP addresses as there are over 4 billion possible IPv4 addresses, and over 10^38 IPv6 addresses (over one thousand decillion). Thus creating a table to reverse the hashing in general is not feasible. Whether the possibility of checking for a match makes a hashed IP &quot;reasonably identifiable&quot; as representing a specific natural person under the GDPR and related laws has not, as far as I know, been authoritatively decided. Note that at most it would reveal that a person using a certain internet connection had (probably) visited a particular site.
For reference, the cookie law you refer to is officially known as Regulation 6 in the Privacy and Electronic Communications (EC Directive) Regulations 2003. Quotations in my answer are excerpts from public advice on this topic published by the UK data protection authority, The Information Commissioner's Office. If a user has explicitly stated that they do not accept non-essential cookies, then any existing non-essential cookies placed by the website should be immediately removed, and this preference remembered so the cookies are not simply recreated a short while later. While a user may not have explicitly accepted cookies when asked, it is possible that the website is operating on the basis of implicit consent - i.e. assuming you accept unless you take action to state otherwise. The idea of implicit consent being allowed is to help make the implementation of cookie questions/banners less disruptive to end users' website experiences. &quot;Consent does not necessarily have to be explicit ‘opt-in’ consent. Implied consent can also be valid. If you are relying on implied consent, you need to be confident that your users fully understand that their actions will result in cookies being set. However, in some circumstances (for example, collecting sensitive personal data such as health details) it is likely that explicit opt-in consent is more appropriate.&quot; Ref: Guide to PECR: Cookies and Similar Technologies - What counts as Consent? There are a few exemptions where consent for cookies is not required, and so a couple of examples for cookies that could be stored regardless of consent might include: (a) a first-party cookie to remember the user's preference approving or disapproving the use of cookies (otherwise every time a new page is opened they would be asked the cookie question again); (b) a first-party session cookie to remember who the user is after they have logged into the website; or upon interacting with an e-commerce website, to remember which products they have added to a cart. These would be considered essential for the website to function. Non-essentially cookies, such as third-party tracking cookies would not be exempt. &quot;There is an exemption if: (a) the cookie is for the sole purpose of carrying out the transmission of a communication over an electronic communications network; or (b) the cookie is strictly necessary to provide an ‘information society service’ (eg a service over the internet) requested by the subscriber or user. Note that it must be essential to fulfil their request – cookies that are helpful or convenient but not essential, or that are only essential for your own purposes, will still require consent. This means you are unlikely to need consent for: (a) cookies used to remember the goods a user wishes to buy when they add goods to their online basket or proceed to the checkout on an internet shopping website; (b) session cookies providing security that is essential to comply with data protection security requirements for an online service the user has requested – eg online banking services; or (c) load-balancing cookies that ensure the content of your page loads quickly and effectively by distributing the workload across several computers. However, it is still good practice to provide users with information about these cookies, even if you do not need consent.&quot; Ref: Guide to PECR: Cookies and Similar Technologies - Are there any exemptions? It is worth noting that guidance was not very specific/clear on how this legislation should be implemented, and so there are vast differences in websites approaches to this challenge. Also remember that some websites may actually be non-compliant with this legislation: (a) through poor implementation - even if they ask the question if the website source code behind the scenes doesn't appropriately observe the end-user's preferences, or by appearing to be compliant while storing cookies which are not explained/justified in the privacy policy; or (b) through conscious deliberate decision - deciding they did not want to comply with legislation they do not agree with on the basis that to implement a cookie question/banner might cost them customers by being unnecessarily disruptive to the user experience; (c) through ignorance - there's always the possibility of a website owner being unaware this legislation exists if their webdesign company didn't tell them and they don't follow related news, or perhaps they have forgotten about it, etc.
The GDPR does not outlaw such processing of personal data. It merely regulates how and for what purposes you can process personal data. In general, you can conduct any processing activity as long as it has a clear purpose and a legal basis. Here, the purpose would likely be something like “conducting business with my clients” and the legal basis would be a “legitimate interest”. A legitimate interest always requires a balancing test that weighs your interests against the interests and rights of the affected persons. For example, can the affected persons reasonably expect such processing activities? In a professional setting, it can probably expected that business partners keep notes about contact persons so your intended processing could be fine. The GDPR does impose some general constraints. There are general principles like data minimization and storage limitation – you should only collect data that is necessary for your purpose, and shouldn't store it for longer than necessary. You should think about appropriate technical and organizational measures (TOMs) to protect the processing activity, for example about how your CRM is hosted, how backups are made and how security updates are installed, who has access to the personal data, and how the people with access to the personal data can be trained. For example, such training might inform your employees that they can only use the data in the CRM for business purposes, but absolutely not for personal purposes like asking Gina from reception out for a date.
It may be legal or it may not For example, if any of the users are in the European Union, then the GDPR applies and the person storing the information is a data controller and has legal obligations. These include, having a legitimate reason for storing them, storing them only for as long as necessary for that reason, notifying the individuals that the data is being stored and why, deleting it upon a users request etc.
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.
The GDPR does not prescribe how exactly consent must be managed, as long as consent was obtained in line with the GDPR's principles. Similarly, the EDPB does not provide concrete recommendations in its guidelines on consent, mainly noting that Controllers are free to develop methods to comply with this provision in a way that is fitting in their daily operations. I would not be too concerned with edge cases like failing HTTP requests, at least not any more than for other HTTP endpoints. If the user indicated consent, and you act on that indication of consent in good faith, that's probably fine. However, remember that you must provide a equally easy way for the user to revoke consent later. If the user changes their mind, they can use the mechanism that you offer to inspect their consent status, and revoke it if they want. But again, how to do that is largely up to you.