What happens if I don&#39;t accept cookies? Due to the so-called "cookie law", websites that are owned in the EU or are targeted towards EU citizens are now required to prompt users to store cookies. Most often this takes the form of either a pop-up or a ribbon informing the user what the cookies are used for and a button to accept them. As I've come to notice, however, this doesn't seem to cover all kinds of cookies. Many sites create cookies even when I browse them without accepting to store them. What should a site do when a user doesn't accept cookies and what kind of cookies can it store regardless of consent?
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.
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.
There are a number of misconceptions here. GDPR does not generally impose blanket bans, but things get dicey if you're using data in a way that is not strictly necessary. Consent (freely given opt-in) is a way to continue nevertheless. A website without ads, tracking, or potentially tracking embedded content can probably work without having to ask for consent. Under the GDPR, every processing of personal data needs a purpose. This purpose must be covered by a legal basis. Some processing might be legally mandated or required by a contract with the data subject. It's also possible to base processing on a legitimate interest, but this requires a balancing test that also considers the data subject's rights and interests. As a last resort, consent can be an appropriate legal basis, but this comes with additional restrictions. Once you have a clear purpose that is covered by a legal basis, you can process the minimum data necessary to achieve the purpose. Sometimes, laws prescribe a particular legal basis. This is the case for cookies. You can use cookies (and similar technologies that access information on the end user's device) as strictly necessary to provide a service explicitly requested by the user. If you go beyond that, the ePrivacy Directive says you must obtain consent first. So for example, session cookies, shopping carts, or cookies that remember a “dark mode” preference are all perfectly fine because they are strictly necessary for something the user is trying to do. Also, you can use cookies to remember if the user gave or declined consent. On the other hand, analytics or tracking cookies are not necessary and require consent. If a website embeds third party content, this discloses personal data such as IP addresses to the third party. This disclosure requires a legal basis, most likely consent. There is case law about this regarding Facebook Like buttons on a page (→ Fashion ID case) but the same principle can be generalized to embedded Tweets or Youtube videos, images, or JavaScript files. A common way to handle this is to replace the embedded content with a placeholder, and to only load the embed once the user gives consent. But not all other domains or services are “third party” in the sense of the GDPR. When you engage a company to act as a data processor on your behalf, they are contractually bound to only use the data as instructed by you, and not for their own purposes. The GDPR allows you to outsource processing activities such as serving web content, as long as you have a suitable contract in place. Such “data processing agreements” are common for hosting providers or CDNs. When consent is to be used as a legal basis, it's important to consider the various conditions that the GDPR imposes (see Art 7 GDPR). The core principle is that consent must be freely given. You cannot make access to a site conditional on consent, so a naïve cookie wall or captive portal will be non-compliant. It's fine to force a choice, but “no” MUST be valid and possible. That consent is freely given also means that you must provide enough context for the user to make an informed decision, that the user must give consent through an unambiguous, affirmative action (consent is never the default), and that consent must be specific for a particular purpose (you can't bundle unrelated purposes). That is why modern consent management tools have multiple layers of information and allow the user to give consent for individual purposes (e.g. yes to analytics but no to ad personalization). In your particular context, you could proceed as follows: Figure out what kind of external content you're currently including. Can you enter into a data processing agreement with the external providers? If so, sign that. Can you host the content locally? This can be an easy solution except for video streams. Careful: copyright concerns might make this impossible. Can you replace the content with placeholders that only load if and when the user gives consent? That way, the rest of your site remains accessible without annoying consent walls. If the third party content is an unavoidable and essential part of your page, use an interstitial to inform the user of the risks before they proceed.
Whether consent is necessary depends on the specific processing purposes. For example, general usage statistics about search terms or about the usage of the site likely fall under a legitimate interest. Outside of the GDPR, there can be consent requirements for the use of specific technologies. Per the ePrivacy directive, consent is required for accessing or setting cookies on a user device, unless the cookie is strictly necessary for the service requested by the user (“functional cookie”). This consent requirement also extends to other storage and fingerprinting technologies. A functional cookie could e.g. be used to store a history of search terms on the user device itself. However, ad personalization is not strictly necessary for the search functionality, so setting cookies (or using similar technologies) for ad personalization requires consent, regardless of whether ad personalization itself would require consent. To determine whether a processing purpose falls under a legitimate interest, the data controller must weight the interest against the data subject's rights and freedoms. There are no objective guidelines on this, and ultimately a court would have to decide. However, I would assume that the tracking necessary for ad personalization is an inappropriate infringement on the data subject's rights and freedoms, so that ad personalization cannot fall under a legitimate interest. The data controller would have to choose a different legal basis, which effectively only leaves consent.
A web site that is serious on protecting some content behind a paywall will put the protected content, or a version of the page with both protected and unprotected content, on separate page or pages, so arranged that a user will not be able to follow the link until that user has signed in and been accepted as an authorized user. A site that merely uses CSS to hide "protected" content is not really protecting it. CSS is designed to be modified by the ultimate user -- that is part of its function. If the site chooses to send you content, you are entitled to read it. Even if some of the content has a CSS tag attached which suppresses or obscures the display of that content, they know perfectly well that any user can supersede this with local CSS, and so I don't see how they have any legal claim, nor any way of knowing if you have accessed the "hidden" content or not. If you attempt to bypass or hack a login screen, that might be circumvention under the US DMCA, or "Unauthorized computer access" under any of several laws.
Per Art 3(2), GDPR only applies to non-European companies when their processing activities relate to the offering of goods or services to people in Europe, or when the processing activities relate to monitoring people in Europe. However, the word “offer” of this targeting criterion requires some level of intent. It is not enough for GDPR to apply that they're marketing to someone who happens to be in Europe, but GDPR would apply if they are intentionally marketing to people who are in Europe. I don't know what they are marketing, so I don't know if that would be the case here. Even if GDPR were to apply, it would not be the most appropriate law. Yes, there's the GDPR right to erasure, which applies under some conditions (though there's a pretty absolute right to opt-out from marketing). The EU's ePrivacy Directive provides more specific rules though, in particular that every such marketing email must offer a way to unsubscribe. Other countries have comparable anti-spam laws, potentially also the home country for this online service.
Is it GDPR compliant that I can't access the account that I created and the personal data that I shared because "I haven't completed their internal pre-qualification process"? Article 15 defines a “Right of access to the data subject” but it's difficult to see how this could be construed as a right to log into a specific website. Common sense suggests this would be a very bad idea. If they are willing to provide the data through another means (say a report or data dump of some sort), the obligation would seem to be met. In fact, article 15(3) even states that data controllers should merely provide the information in a “commonly used electronic form” (i.e. not necessarily through access to their systems or whatever form they are using internally for the processing). Have you asked for that and would you be satisfied by that resolution? Is it GDPR compliant that their answer to my deletion request is "We will delete the data..." The text of article 17 (right to erasure) explicitly specifies that such a request must be honored without “undue delay”. Article 12, which defines some of the modalities for the rights to access, rectification or erasure by the data subject, also provides that controllers shall “provide information on action taken on a request […] without undue delay and in any event within one month of receipt of the request”. You haven't provided any time frame and I don't think there is anything wrong with acknowledging the request by promising they “will” do it but in light of article 12, it seems you would indeed be entitled to know once they have actually taken further action. However, you implied you might want to access the data first and it's not clear to me whether you explicitly invoked the GDPR in earlier communications. So I would clarify and reiterate my request (access or erasure) and ask them for explicit confirmation once it has been satisfied.
First of all, although the GDPR is stated to apply to any site which processes the data of any person who is in the EU, it is not clear how a site not located in the EU, does not business in the EU, and does not primarily target EU residents as its audience can be required to comply with the GDPR. To the best of my knowledge, no such case has yet been brought, much less decided. There has also been some debate on whether an IP address constitutes Personal Data under the GDPR, and if it always does so, or only under particular conditions. The European Court of Justice (ECJ) held that (under the predecessor Directive 95/46/EC) that a dynamic IP address was personal data. But in that case the web site was run by the German Federal Government, which surely has wider scope for getting info from a German ISP than a small private US web activist does. There is not yet any case law that I know of on the applicability of the GDPR to IP addresses in any case at all similar to the one in the question. Joe would in my view be wise to at least learn that logs are being kept, and post a disclosure of this on the site. Whether Joe needs to do more than that is less than clear at this time.