Is a cookie notice required for analytics? Note: I've been directed here from Meta.SE I'm using GoSquared for my website analytics. I've visited quite a few sites using Google Analytics but they don't have a cookie policy or a cookie banner/cookie notice, even though Google Analytics uses cookies to provide their services. Do I need to make my own cookie policy or cookie notice if I use GoSquared Analytics (which also uses cookies to function)? Note that these are non-essential cookies provided by a third party. And does the fact that I am in the UK change anything?
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.
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.
Yes, there would still be an obligation to comply with erasure requests – if the data subject can be identified, and if the GDPR applies. This is a case for Art 11 GDPR: processing which does not require identification. The pastebin site is not required to collect identifying info just in order to facilitate later deletion. If the site is unable to identify the data subjects, then the data subject rights (like access, rectification, erasure, restriction, or data portability) do not apply. Other rights like the right to be informed and the right to object do remain, though. But if the data subject provides sufficient additional information that makes it possible to identify their records, then the data subject rights apply again. In practice, this is likely going to mean that anyone with access to a paste will be able to request deletion, since the site would have no ability to verify the identity of the data subject beyond the information in the paste. None of this absolves the site from implementing appropriate technical and organizational measures to ensure the security of this data. Even though the pastes might not be directly identifying, they are personal data and are far from anonymous. Common practices like numbering pastes with a sequential ID or showing recent pastes on a homepage have to be viewed critically. My go-to recommendation is to assign a cryptographically random UUIDv4 ID to the post, so that it is practically impossible for anyone to find the paste unless they were given a link by the uploader. Your idea to delete pastes after a fairly short retention period is also good. This helps with security, and it is in line with the GDPR's data minimization and storage limitation principles: data may only be kept as long as necessary for its purpose. On the other hand, quick deletion might not be in line with the purpose of these pastes – it all depends on context. You mention that this is an US-based site. If so, there's a question whether GDPR would even apply. GDPR will apply per Art 3(2) if the data controller is offering its services to people who are in Europe. Here, “offering” does not mean mere availability of the website, but that the data controller intends the service to be used by such people, in particular if the service is somehow targeted or marketed to such people.
For land ownership records and other similar scenarios such as business directors, the requirement for these to be public will be in legislation rather than a contract - this provides the legal basis, see GDPR Article 6(1c). Additionally when government departments are doing it they also have 6(1e) as lawful basis: "1. Processing shall be lawful only if and to the extent that at least one of the following applies: ... (c) processing is necessary for compliance with a legal obligation to which the controller is subject; ... (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;" -- GDPR, Article 6(1c,e). I'm not familiar enough with the specific legislation that will apply here but pretty sure this will be the case, and having said this you may well find public registries also become less public going forward. The reason ICANN has come under fire, is partly because under GDPR privacy is a protected fundamental right and therefore to comply personal data should be kept private by default and privacy never something you would be required to pay extra for. Any contract ICANN have in place with their registrars will not override legislation, it is in fact the other way around. "2. The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons." -- GDPR, Article 25(2). This doesn't stop ICANN from maintaining a register of domain name owners (registrants), but it does mean they can't just publish all records upon request to anyone anymore - whether people will be granted access to personal data will now depend on if they have a lawful basis for this, and in these cases their processing of the personal data will be limited to those purposes. Being nosey doesn't count! "When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of the contract." -- GDPR, Article 7 (4) - Conditions for consent. What this means essentially, is that if the consent is conditional for the contract it will not be treated as freely given, and therefore not valid - it will no longer be acceptable to contractually bind the provision of a product or service with consent to publish personal data or any other form of processing such as marketing mailing lists. Looking now at the specific points you have raised: "GDPR article 6 allows for processing of personal data on a contractual basis (section 1b)" Whilst this is true, this is only part of it - it doesn't allow for unlimited processing for any purpose and sharing it with any people, if you look at Article 5(b) it states that the information is collected for specific explicit legitimate purposes. Each purpose requires its own legal basis and needs to be compatible with the principles of GDPR. Without consent, ICANN currently does not have a legal basis to make the WHOIS records public for EU citizens and should have adopted some technical controls to require them to opt-in if they wish to be included in the public register. They're coming under fire for non-compliance having been given 2 years to prepare and change their systems/processes. "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;" Again whilst this is true, not all processing is necessary for the performance of a contract. In the same way people must give consent to receive marketing communications, they must freely give consent for their information to be shared/published (separate to the contract for provision of service) in the absence of other lawful basis for this processing. "Also section 1c, processing is necessary for compliance with a legal obligation to which the controller is subject;" There is no legislation which requires them to publish the personal data of domain name registrants. In this paragraph 'legal obligations' refers to those required by legislation (i.e. statutory obligations), not contracts (or non-statutory obligations) which are covered under Article 6(1b). "And finally section 1e, processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;" ICANN has no official government-assigned authority, and publishing the personal data globally is not in the interests of the data subject's or others' welfare or well-being - this is what is meant by 'public interest'. As far as I can see what ICANN are actually doing to comply seems to be accepted by the European Data Protection Board, they are only 'under fire' as you say because they are late in doing so. The deadline was 25th May 2018 and they had 2 years to prepare like all other organisations.
You must get opt-in affirmative consent to process personal data, including tracking people's use of your site or providing targeted advertising. The banner on StackExchange is likely in violation of the GDPR. Do not copy it. It does not have an explicit opt-in, only an opt out which is onerous (leave the site, then manually go in and delete any cookies they set, which may be hard to identify if they are from 3rd parties). The sites you mention that have a gateway are a more correct implementation. Consent must be acquired before processing of data begins, and it must be explicit.
It is the data controller's responsibility to respond to data subject requests. If you provide a B2B service, you are most likely a data processor who only acts on the controller's behalf, on the controller's explicit instruction. This will depend on your contract with the controllers, your customers (see Art 28). Typically a processor would merely forward any data subject requests to the controller. Only if you are contractually obligated to serve data subject requests would it be possible for you to respond directly. If a processor were to fulfil a data subject request on their own initiative, that would arguably be a GDPR violation. However, the processor has to assist their controller with compliance per Art 28(3)(e), e.g. by implementing an admin interface through which the controller can service GDPR requests. The core issue here is that controllers and processors have slightly different obligations in order to be GDPR compliant. Controllers owe compliance to the data subjects, but processors only act on the controller's behalf and owe compliance to their controllers – they have no direct relationship with data subjects. Assuming you were a controller, then yes, I would assume you would have to decrypt any data that you are able to decrypt in order to fulfil a data subject request. Access requests can only be denied if: Art 12(5): they are “manifestly unfounded or excessive” (which the controller has to demonstrate), or Art 15(4): the access would “adversely affect the rights and freedoms of others”. Art 11(2): the controller can demonstrate that they are actually unable to identify the data subject so no data subject rights in Art 15–20 apply. A request is not automatically excessive just because it will require substantial CPU time, this exception is more often triggered when data subjects request the same data very frequently (e.g. every week). You are not required to provide or search data that you don't have access to (e.g. E2E encrypted data). Your use of per-field encryption is a very strong security measure (depending on how keys are managed). But GDPR is not about achieving maximum technical data protection, but merely requires appropriate safety measures (see GDPR Chapter 4, especially Art 32). Asymmetric encryption of small fields within a database is unlikely to be appropriate, taking into account the cost of processing and the data subject's ability to exercise their rights. A different security measure to ensure that every business only sees the correct data would be through testing and code review of your SQL queries, and full disk encryption of the server storing the database. In practice, asymmetric encryption is most often just used to encrypt a symmetric key, which is then used for the actual data. But which measures are appropriate also depends on the risk to data subjects – your approach could make sense for very sensitive data. Art 14 does not play a role here. It is about transparency of processing: that you need to (a) notify the data subject that you're processing their data, if feasible, and that you (b) provide information about this processing, usually in form of a privacy policy. Art 14 is the pendant to Art 13, which applies when data is obtained directly from the data subject. The Art 15 right to access and the Art 20 right to data portability are distinct from the right to be informed. In any case, it is the controller's responsibility to fulfil these rights.
Why do you think Oracle have not been protecting their trade mark? Using a trade mark to describe the product (“Written in JavaScript”, “Seeking JavaScript developer”) is not an infringement and the trade mark owner is under no obligation to, indeed, cannot stop this. Where they are required to defend their trade mark is when it is being used in such a way that there is the risk of confusion that the goods or services could be confused with the trade mark owner’s goods or services. Further, they are not required to defend all breaches, only enough to show that they are actively doing so. Also it is not important that the trade mark be associated with the trade mark’s owner. Do you know who owns the trade mark “Ben &amp; Jerry’s”?
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.