Can you preemptively check local storage before user agrees under Cookie Law? I am pretty new to the idea of asking for consent for storage for a website because I'm American. I understand that if I want to store anything, I need to ask users for consent. However, I'm confused by exactly how to abide by the Cookie Law. How do I know if the user has agreed to storage if I can't check the storage? Is it more that I am allowed to check local storage to to see if the user has agreed previously? ie I don't store anything until the user agrees, but I may check local storage to see if the user has agreed to anything. I might be digressing, but the way I interpret the law was that if I track anything that can give insight into who the user is, that's bad. But if it's used for a purely frontend application for the website (eg a personal blog that may have a search backend, but the storage items aren't used for that), I don't have to worry so much? Esp if it's storage for things like color modes or positioning of navbar (left, right, up, down)? I guess what I'm getting at is what's a reasonable flow to be compliant at the same time as leveraging cookies so the site doesn't reset to vanilla and consent banner doesn't pop up every time the user visits?
Yes, a site may check for a cookie indicating past consent before prompting for consent to read and store cookies When people speak of the &quot;Cookie law&quot; they usually mean the ePrivacy Directive, (ePD) more formally the Privacy and Electronic Communications Directive 2002/58/EC. The full text of the directive is here First of all, being a directive and not a regulation, the ePD is not itself legally binding. Instead it instructs the legislatures of member states to implement it, which they generally have done. So the actual binding law is the law of a particular country, which could vary from the wording of the directive. However, in this case, my understanding is that the implementations do not vary significantly. An updated and revised ePrivacy Regulation (ePR) has been proposed, which would replace the ePD and complement the GDPR. But there has been dispute over the proposed terms of the ePR, and it has not yet been passed. Article 5 section (3) of the ePD reads: Member States shall ensure that the use of electronic communications networks to store information or to gain access to information stored in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned is provided with clear and comprehensive information in accordance with Directive 95/46/EC, inter alia about the purposes of the processing, and is offered the right to refuse such processing by the data controller. This shall not prevent any technical storage or access for the sole purpose of carrying out or facilitating the transmission of a communication over an electronic communications network, or as strictly necessary in order to provide an information society service explicitly requested by the subscriber or user. Notice that this covers both writing (storing) and reading (gaining access to) cookies and other information stored on a user's device. Cookies ar one form of such locally stored information (LSI). Note that the GDPR, which replaces Directive 95/46/EC, is used to define &quot;consent&quot; in the ePD. In general, one must have consent to read or store, and consent must be sought only when the user has been given &quot;clear and comprehensive information ... about the purpose&quot; of the stored information. The relevant exception for this question is that information (including cookies) which is &quot;strictly necessary&quot; to provide a service specifically requested by the user. Here the user has requested access to the web site, and may have previously agreed to accept cookies. The site must prompt for consent if the user has not previously consented (and the site will store cookies not strictly needed), and should not if the user has. Therefore, it is strictly necessary to check for and read if present a cookie indicating that such consent has previously been granted. If such a cookie is not found, no consent has been granted. Strictly required LSI should not have a dual purpose where one purpose is not strictly needed. For example, an &quot;I accept cookies&quot; cookie should not also be used for tracking. That should be done (if at all) with a separate cookie, and only after consent is received. Note that there should be an easily found and easily used method or link on the site (preferably on each page of the site) to review the purposes of stored or accessed LSI, and to withdraw previous consent. If consent is withdrawn, the cookie indicating that consent has been granted should be erased, as should any cookies or other LSI not strictly needed to provide the services requested by the user. Keep in mind that the legal distinction is not between cookies that contain &quot;technical&quot; information and those that do not. That is not relevant. Nor is the distinction between cookies that might be used to identify a person and those that do not. The legal distinction is between cookies (or other LSI) that are strictly needed to provide the services requested by the user, and all other LSI. Strictly needed LSI does not require consent, all other LSI does. For example, a random string, used to determine the number of unique visitors, but not linked to any identifying info about the user, does not help to identify an individual user. But it is not strictly needed, so it can only be stored with consent. Data that are associated with an identifiable natural person (human being, not a firm or organization), are governed by the GDPR (where it applies). There must be a lawful basis for processing such data, which includes reading them from LSI, and storing them. Consent is one of the six possible bases for such processing, but consent need not be obtained if another lawful basis applies. When consent is the basis, it must be easily withdrawn by the user. Note that this applies to all data (PI) that is associated with a person, not just data that can readily be used to identify the person (PII). Note that other workflows are also lawful. For one example, if a site is a strictly membership site, it could prompt for a login before reading or storing any LSI, and then read previous preferences stored on the server by that user to determine whether consent for cookies has been granted. Conclusion A cookie indicating that consent to access and store cookies hs previously been given by a particular user can lawfully be read before a user is prompted for consent, under the ePD and its implementing laws.
Yes If you are in the EU, or your players are in the EU and your service is targeted at some part of (or all of) the EU, then this pretty clearly falls within the scope of the GDPR. Such a service would be collecting data associated with natural persons. At least some of it would be made public along with an online identifier, and other parts would be processed and stored, even if disclosed only in anonymized form. (By the way it is a non-trivial task to anonymize data well enough that it is no longer persona data under the GDPR. But let's suppose yoru methods are good enough.) Under GDPR Article 6 the DC must have a lawful basis for such processing. If the basis is &quot;consent&quot; then the consent must be freely given, whch means giving consent may not be a condition of using the service. Under GDPR Article 13 a notice must be sent to the Data Subject (DS) when the data is collected from the subject, including some 11 items or categories of information about the collection process, the Data Controller (DC), the purposes of processing, the legal basis of processing (which the DC must define), who will receive the data, the data retention period, and various rights of the DS. Such a service must be prepared to respond to data access and data erasure requests, under articles 15-17, and data restriction requests under article 18. It must provide a method for a DS to easily make such requests. Other GDPR provisions may well apply in addition to these, but that is enough to show that such service is very likely to be within the scope of the GDPR, unless none of the DSs are present in the EU or the related market area.
Doing this is OK according to the GDPR and other European laws. The relevant bit is GDPRs rules for Lawfulness of processing, and in particular Article 6 (1)b, which says that it is legal to do this if processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; In your particular case, signing up for using your app is "entering into a contract" and it is the data subject who has requested to use your app that is subject to this processing.
People running web servers are generally liable for contributory culpability, when some user breaks the law by putting the material on the server. There are legal mechanisms for relieving the server guy from this burden. The best-known mechanism is "DMCA takedown", where you publish contact information so that an offended person can serve up a proper legal claim that you are distributing material that they own copyright to. If you follow the rules, you may enjoy "safe harbor" protection against contributory liability: one of the requirements is that you have to take infringing material down. The specific requirements can depend on the nature of the liability and jurisdiction, but generally involves a "hands off" involvement where the person has no knowledge of what's going on on his server. So just disclaiming responsibility does not work. There are other more serious violations, such as distribution of child porn or transmission of top secret information. Jurisdiction is not totally central to internet questions, and I could sue you (the server guy) in US courts, or (depending on the offense: copyright infringement of a particular item) in UK courts. Nailing this down specifically to Sweden is harder, but recall that The Pirate Bay had a whopping judgment against them.
I believe in this case, your company (OrgX) is a data processor and your customer's organization (OrgY) is the data controller. OrgY is responsible for establishing a lawful basis for sending you (OrgX) the personal data for their employees. Note that consent is just one of six lawful bases outlined in article 6(1). I'm no expert, but I believe OrgY's admin can claim they have a legitimate interest in sending their employee's personal data for training sake. In either case, the data processor is not responsible for establishing the lawful basis for processing. Of course, data processors aren't completely off the hook. GDPR outlines specific requirements for data processors (see chapter 4, particularly article 28).
The territorial scope of the GDPR is defined in Article 3. It covers "personal data of data subjects who are in the Union", whether they are EU citizens or not. So to answer your questions: 1) are EU users, but moved to USA a few years ago, and signed-up on my website? They are not in the EU, so are not covered. You don't need to know if someone is an EU citizen, just if they are currently in the EU. 2) went for holidays in USA, signed-up on my website, and then came back to EU? (note - potentially skipped any Consent questions at sign-up, because IP was from USA) If someone moves into the EU while using your service then they fall under the GDPR for the time they are in the EU. If their home address is in the EU then that is covered, and monitoring of their behaviour while in the EU is also covered. Your other two questions are about VPNs. If a VPN is used to evade IP address geolocation and you have no other clue about where someone is then you can't be blamed for not knowing where they are (although I'm not aware of any actual case law on this topic). But if someone with a USA IP address gives a home address in the EU then you should probably treat them as being in the EU to be on the safe side. Basically, if you don’t know if they are in the EU or not, you should treat them as if they were.
You are responsible for what data is being processed by your website. When you embed third party components on your website (e.g. iframes, scripts), you are at least jointly responsible with the third party providing these components. You are only responsible for what happens on the website (i.e. what processing is under your control), not for what the third party provider does with collected data on their services. However, note that information will be transferred to Google's servers regardless of whether the visitor has a Google account! The Fashion ID case is relevant case law establishing and explaining these points. Since you are (jointly) responsible, you need a legal basis for collecting personal data through the tracking snippet and sharing it with the third party (here Google). For example, the legal basis could be a legitimate interest, or could be consent. A legitimate interest requires that you balance this interests against the interests, rights, and freedoms of the data subject (the site visitor). If the data subject wouldn't reasonably expect this tracking, you cannot rely on a legitimate interest. Consent can always work, except that it is a freely given, informed opt-in – likely unsuitable for conversion tracking. Which legal basis to use is primarily your responsibility. You argue that the tracking snippet does not collect personal data. However, this argument is not well supported. Under the GDPR, personal data does not only include directly identifying information such as an email address, but also any information “relating” to an identifiable person. Identification includes the ability to single out someone, e.g. by a browser fingerprint. For purposes of conversion tracking, Google will clearly try to collect data that allows the visitor to be singled out, thus collecting personal data. Furthermore, specific kinds of information are regulated by the ePrivacy directive. This includes “traffic data” and “information stored on a terminal device”, regardless of whether this information is personal data under the GDPR. Under ePrivacy, such information can only be used as strictly necessary to provide the service requested by the user (and conversion tracking is not strictly necessary), or when the user gives their consent. Depending on what information is collected by the tracking snippet and on whether you are subject to ePrivacy, you would have to collect consent anyway. There is also the issue that Google Ads is an US-based service, and transferring data to the US is largely illegal since the 2020 Schrems II ruling. The US do not provide an adequate level of data protection, so that transfers would require additional safeguards. Standard Contractual Clauses (SCCs) for Controller to Controller transfers are not sufficient by itself. Of course those extra safeguards are effectively impossible to implement and no one is doing this correctly, but it's worth considering that there is additional legal risk. Explicit consent can provide a legal basis for transfers even to a country with inadequate protections, but that mechanism is intended for occasional transfers. In conclusion: you have wrongly concluded that no personal data would be involved you are jointly responsible with Google for whatever data is processed by the conversion tracking snippet you need a legal basis for sharing this data with Google legitimate interest may be sufficient, depending on what data is involved (consider ePrivacy) and depending on the result of your legitimate interest balancing test alternatively, you may require every visitors consent to track their conversions – unlikely to result in good data additionally, such use of Google Ads may run into issues around international transfers due to the Schrems II ruling this kind of stuff is difficult, and no one is really doing this correctly :/
Among other things, GDPR regulates what you may do with the data within your systems. You can use it for the contracted purpose, or in accordance to law, or with informed and revokable consent, or for some other enumerated purposes. Even with consent, you have to take security measures to avoid the misuse of the data. Remember the software shrink-wrap licenses? &quot;By opening the package, you agree to the terms inside.&quot; GDPR makes the equivalent in the cloud world impossible. You have to document exactly what you do with the data, and for any use that is not necessary to perform the service the customer can opt out. In the scenario you describe, it is possible that you are not the data controller under GDPR but the data processor, and that you have a duty to keep the data from separate controllers apart. And delete any batch at the end of contract. If you want to do this professionally, you need to consult a lawyer for your specific plans.