GDPR - reCAPTCHA with user&#39;s consent? This question is specifically about Google's reCAPTCHA, but may possibly apply to many other CAPTCHA solutions that are collecting "personal" data. I was reading briefly about ePrivacy regulations and I have found very good resource about PECR and cookies at ICO. I have tried to contact ICO via their Live chat, but unfortunately they don't provide any legal advice. However, they said - "If you're collecting personal data, then you must comply with GDPR." From what I could find online and from what I can see in browser, Google's reCAPTCHA is collecting client's hardware and software information in order to analyse if the client is human or robot. Some of the cookies are sent to google.com. Some unofficial sources say that Google even use their GA tracking cookie to identify human vs. bot. In my understanding this approach can be seen as tracking or fingerprinting. So I'm wondering how is it actually from legal point of view? Do we really need to obtain user's consent before we can use Google's reCAPTCHA on website served to EU citizens? ICO says, there are exemptions for session cookies providing security that is essential to comply with data protection security... Can be reCAPTCHA considered as tool for providing data protection security? My point is that no bot will ever give consent to reCAPTCHA, so what is way out of this riddle? UPDATE (2018-05-07) I noticed Google updated their EU user consent policy, that is linked from reCAPTCHA admin, located here: Their terms of service: ...it is your responsibility to provide any necessary notices or consents for the collection and sharing of this data with Google. For users in the European Union, you and your API Client(s) must comply with the EU User Consent Policy currently located at http://www.google.com/about/company/user-consent-policy.html. So assuming the consent is required, I would like to rephrase my original question: If I offer ways to give consent and/or deny reCAPTCHA; Is it legally acceptable to include and execute reCAPTCHA on website by default without prior consent?
“From your perspective you should not worry about asking permission to use reCaptcha as it is not you who is processing the data it is google and any GDPR compliance falls on them.“ This is plain wrong. If a user visits your website you are the controller of data collected on your website. Regardless of what entity collects that data. However in my non-legal opinion reCAPTCHA falls under Article 6 section 1d and 1f. Also Recital 49. 1d: “processing is necessary in order to protect the vital interests of the data subject or of another natural person;” While you could argue in some cases (most probably) reCAPTCHA is used to reduce spam to a business entity thus not a “natural person”. 1f: “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 which require protection of personal data, in particular where the data subject is a child.” Here is where the real ruling applies “Legitimate interests”. You as a business have a legitimate interest in reducing spam into your business. Not only does spam take up your time but it also takes up your resources. As to the extent in which spam takes up is dependent on the usage in question. But nearly everyone can safely assume reducing spam (one of the cornerstones of the GDPR) is a legitimate interest. Recital 49 (excerpt): The processing of personal data to the extent strictly necessary and proportionate for the purposes of ensuring network and information security, i.e. the ability of a network or an information system to resist, at a given level of confidence, accidental events or unlawful or malicious actions that compromise the availability, authenticity, integrity and confidentiality of stored or transmitted personal data, and the security of the related services offered by, or accessible via, those networks and systems, […] by providers of electronic communications networks and services and by providers of security technologies and services, constitutes a legitimate interest of the data controller concerned. This could, for example, include preventing unauthorised access to electronic communications networks and malicious code distribution and stopping ‘denial of service’ attacks and damage to computer and electronic communication systems.
There are two issues with typical analytics solutions: they rely on visitor consent they involve processing in the US Some people believe that they can sidestep GDPR problems by only collecting anonymous data, but this doesn't matter for the consent requirement, and is also impractical in my experience. These aspects are discussed in more detail below. Before I go further, I have to mention that no common analytics solution relies on third-party cookies. While analytics services are often provided by a third party, that is neither technically nor legally relevant. Technically, these analytics scripts usually set some analytics ID on a first-party cookie – a cookie scoped to the domain where the website is running, not scoped to the analytics provider's domains. Legally, analytics services often serve as a “data processor” on behalf of a website, and don't use the collected data for their own purposes. GDPR allows outsourcing processing activities (such as analytics collection) to others. In particular, this means that there is no technical or legal argument for preferring self-hosting over using some analytics services, assuming other relevant conditions are complied with (data processing agreement, international transfers). In the past, ad blockers have also blocked a large percentage of self-hosted analytics servers. Self-hosting some analytics solution is primarily valuable because it gives you more control over where the data is processed. But it doesn't give you better analytics, and doesn't let you sidestep any consent requirements. Server-side tracking is quite limited in what kind of info it can collect, but it is the only collection method that cannot be blocked. Since you're only re-interpreting data that the server has anyway, no extra network requests are caused between the client and the server. Collection session- or user-level data can be challenging though, unless the visitor is logged in. Server-side data collection is very easy on traditional websites, but more challenging e.g. with single-page applications that communicate with the backend via GraphQL. Server-side data collection is most valuable when business-level events can be tracked – an event such as “placed order” is probably closer to the user's intent than “navigated to /checkout”. You will probably find that this is not an either–or situation. You will likely want some server-side analytics as a baseline (limited data, but less problematic legally, and limited impact of blocking software), but still want to use traditional analytics for those visitors that consent to it. When consent is needed By itself, there might be a legitimate interest for collecting analytics. But for collecting session-level data, it is necessary to assign some kind of identity to visitors. This is usually done by setting a cookie with a random ID. Per the ePrivacy Directive in the version from 2009, any access or storage to information on the end user's device needs consent, unless that access/storage is strictly necessary for a service explicitly requested by the user. This is known as the “cookie law”, but is not technology-specific and will also apply to equivalent client-side approaches such as LocalStorage, tracking IDs in URLs, or fingerprinting. The consent requirement is also independent from the question whether the stored information qualifies as personal data. The GDPR didn't change anything with these rules. It only changed the definition of consent, invalidating “implied consent” approaches like “by continuing to use this site, you consent to …”. Consent means opt-in. Consent must be easy to decline and to withdraw, and users must understand what specifically they are consenting to. This has led to a decrease in percentage of people who consent to storage of analytics IDs. What you can do about it Consent is only explicitly required for client-side storage or equivalent technologies. That means you may be able to collect some analytics on an opt-out basis. You can collect some client-side data without asking for consent. And you can probably use server-side data for analytics purposes. That means you are able to get comparable page-level data, but not session-level data. For determining the country of the user, you just need the user's IP, and this is available server-side. Google's deprecation of UA and move to GA4 helps analytics customers to be more compliant, by making it easier to collect data without setting a ClientID. Why US-based services are a problem The GDPR expects that the entire data processing pipeline maintains a high level of data protection. This means that transferring personal data into non-European countries is only allowed if they offer an adequate level of data protection. Alternatively, contracts (SCCs) between the data exporter and data importer may be able to translate enough of the GDPR into an enforceable contract with the foreign importer, to ensure compliance of processing there. The US did have an adequacy decision called “Privacy Shield”, but this was invalidated due to concerns over the rule of law in relation to US mass surveillance laws. For the same reasons, contracts with US-based data importers are probably invalid. There are also increasing concerns of using EU-based services from US-controlled companies. In particular with relation to Google Analytics, there have been repeated warnings by data protection agencies that use of this service violates GDPR. GA does not guarantee that the personal data collected via the analytics platform is only processed in Europe. What you can do about it The international transfer problems can be avoided by using an analytics service hosted in Europe, or in any other country with an adequacy decision (such as Canada). Self-hosting on an European server is another popular option. Analytics data is rarely anonymous In your question, you write: I don't want to use PII data, but eager instead to find a privacy-friendly way to distinguish one user from another. It is important to mention here that the US concept of PII is substantially more narrow than the GDPR concept of personal data (PD). PD is not just directly identifying info, but any data relating to an identifiable person. A person is identifiable not only when you know their real-world identity or email address, but already when you can single them out in a data set, or otherwise distinguish them from others. Thus, per-session or per-visitor analytics data should be treated as personal data, and GDPR continues to apply (which may or may not mandate consent). Anonymization is possible but challenging. Anonymization tries to ensure that there are no reasonable means that could likely identify the data subject. The only widely used anonymization method is aggregate statistics, e.g. moving from per-user events to average values. In particular, aggregate metrics such as “pageviews per month” are anonymous. Other anonymization techniques I have seen: Tokenization: mapping the user's ID to an entirely random ID. After some time (e.g. 24 hours), the mapping is erased so that the random ID cannot be traced back to a user. Plausible uses a weaker variant of this that uses a hash function to derive a pseudo-random ID from the user's identifying info (e.g. IP address). While Plausible's approach avoids having to store a large lookup table, a malicious server operator could log the daily key and use it to recover the original data from the hashed IDs. The weakness of this approach is that it still relies on some identifying data. While it is a good compliance and security measure, it doesn't really change anything fundamental from the GDPR perspective. Differential privacy: individual records are distorted with an appropriate amount of noise, but the noise cancels out when calculating aggregate statistics. Such techniques are the state of the art, and the only class of general-purpose anonymization techniques that are likely to achieve anonymization in the sense of the GDPR. However, they are mathematically involved. I don't know of any analytics product that incorporates differential privacy techniques. From my own research into GDPR-anonymized analytics, I found it challenging to design solutions that both provide proper anonymization and are able to provide sufficiently accurate session-level statistics as expected from a typical web analytics solution.
Well actually... I think you'll just need to wait a little more. I monitor the situation quite closely and I can tell you that it's just a matter of time. Microsoft was one of the first (if not the first) to communicate openly about the GDPR and the changes that follow. From the blog post: If your organization collects, hosts or analyzes personal data of EU residents, GDPR provisions require you to use third-party data processors who guarantee their ability to implement the technical and organizational requirements of the GDPR. To further earn your trust, we are making contractual commitments available to you that provide key GDPR-related assurances about our services. Our contractual commitments guarantee that you can: Respond to requests to correct, amend or delete personal data. Detect and report personal data breaches. Demonstrate your compliance with the GDPR. Microsoft is the first global cloud services provider to publicly offer you these contractual commitments. We believe privacy is a fundamental right. The GDPR is an important step forward to further clarify and enable individual privacy rights and look forward to sharing additional updates how we can help you comply with this new regulation and, in the process, advance personal privacy protections. Microsoft has set up an informational site on GDPR here. If your eyes are on any other provider, I think the only way to learn more is getting in touch and inquiring about their progress and process. Hope this helps.
It's hard to prove a negative, and I'm not sure which specific part of the quoted Terms you object, to, but it specifically states that content access may be done to: Comply with the law Protect its customers; and Protect the security of its business; and Protect its business interests. It's unlikely that access of information to comply with the law is illegal. At least one EU directive, Directive 95/46/EC, sets limits on the collection and use of personal information. We're concerned with the first condition for lawful data processing, and the second principle of data quality. Data processing is only lawful if the data subject has unambiguously given his consent; or processing is necessary for the performance of a contract to which the data subject is party; or processing is necessary for compliance with a legal obligation to which the controller is subject; or processing is necessary to protect the vital interests of the data subject; or 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 or in a third party; or processing is necessary for the purposes of the legitimate interest pursued by the controller or by the third party, except where such interests are overridden by the interests for fundamental rights and freedoms of the data subject which require protection. The principles of data quality, which must be implemented for all lawful data processing activities, are the following: personal data must be processed fairly and lawfully, and collected for specified, explicit and legitimate purposes. They must also be adequate, relevant and not excessive, accurate and, where necessary, kept up to date, must not be stored for longer than necessary and solely for the purposes for which they were collected; special categories of processing: it is forbidden to process personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, and the processing of data concerning health or sex life. This provision comes with certain qualifications concerning, for example, cases where processing is necessary to protect the vital interests of the data subject or for the purposes of preventive medicine and medical diagnosis. So, let's say that someone has given their consent. It'd be at least a little questionable whether the inspection of private information could mean that they access personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, and the processing of data concerning health or sex life. I'm a bit less clear on US laws, but you'd probably look for laws around Personal Identifying Information, as that's where a lot of focus has been.
There is a lot going on in this question, so I'll pick out some individual aspects. Last but not least, I'll discuss if GDPR even applies. Does the GDPR require consent for X? Almost always, no. Consent is only one of many legal bases of processing. A common alternative to consent is a “legitimate interest” where a balancing test is performed between this legitimate interest and your interests, rights, and freedoms. Consent is typically only appropriate if this balancing test fails, for example if you would not reasonably expect this processing activity to occur. It's worth noting that it's a reasonably common occurrence that businesses are sold or merged. This is not unexpected. In general, you would not be required to consent to such a transfer. What can a company do with personal data acquired through a merger/acquisition? The GDPR does not provide explicit provisions for this case. But it might be useful to think about the two cases where (a) the new company is a continuation or successor of the original one, and (b) where the data is transferred (“sold”) to an otherwise unrelated company. In case (a) where the business is continued as normal, there is no change. In case (b) where data is transferred to a separate company, things are more complicated. The original company would need a legal basis for transferring the data. But as mentioned above, there might be a legitimate interest. Arguably, such a transfer could also be based on Art 6(1)(b) if the transfer is necessary to continue to provide the service, for example if the original company would otherwise have to terminate service. Of course, activities like data brokering where access to data is granted to unrelated third parties would generally fail to be covered by contractual necessity or a legitimate interest, and would probably need consent – but that doesn't seem to be the case here. When a data controller (such as the new company) acquires your personal data from sources other than directly from you, then they are subject to the notice requirements in Art 14. They have to actively notify you about their processing activities. But because you received emails that mentioned the transfer, this condition might have been met. Of course the new company continues to be bound by the purpose limitation principle as detailed in Art 6(4) – they can only use the data for purposes that are compatible with the purposes for which the data was initially collected. Thus, the new company cannot arbitrarily widen processing purposes, though some change in scope is certainly permissible. How does the GDPR right to object and to restrict processing apply here? The Art 21 GDPR right to object means that if the legal basis for a processing activity is a “legitimate interest”, then you can ask for an opt-out. But in some cases, this objection does not have to be granted. An objection essentially requires the controller to repeat the legitimate interest balancing test, taking into account the “grounds relating to [your] particular situation” that you provided in the objection. The Art 18 GDPR right to restrict processing is an alternative to the right to erasure. It applies only in narrow circumstances, for example while an objection is being checked. It is likely that you were informed about the transfer to a new company about 1 month in advance, so that you would have been able to prevent this transfer by closing your account prior to the deadline. If the new company conducts processing activities based on a legitimate interest, then their presumably GDPR-compliant privacy notice about which you were notified will certainly explain that you have a right to object. Is the new company GDPR-compliant? That is impossible to tell, but nothing you've shown so far indicates that they're non-compliant. My largest issue with this story is that the new company is from Australia, a country with extraordinarily bad privacy protections (as of 2022). However, due to the way how the GDPR treats international transfers of data, this doesn't prevent Australian data controllers from being GDPR-compliant, although it does make it difficult for other companies to use services based in Australia. Does GDPR even apply? Whether GDPR applies to a non-European company depends only on whether they either offer goods or services to people who are in Europe (“targeting criterion”), and whether the monitor people's behavior that takes place in Europe. Factors such as your citizenship would be irrelevant. I'll ignore the monitoring criterion, and focus on the targeting criterion. I'll assume that you are in Europe (EU/EEA or UK). Whether a company is targeting people in Europe depends primarily on the company's intentions. It does not matter whether the service is accessible from Europe. Thus, it is quite possible that the original company was not subject to the GDPR. Then, any questions about GDPR, consent, and data transfers are moot. In contrast, the new company clearly mentions GDPR-compliance, which would only matter if they intend for people in Europe to use their services. So GDPR probably applies to them, giving you the full suite of GDPR data subject rights as (hopefully) outlined in their privacy notice. And as long as they notified you that they acquired your personal data in accordance of Art 14, I don't seen anything that they might have done wrong in respect to this acquisition/merger.
Yes, GDPR applies: you are a data controller established/living in the UK or are offering services to people in the UK you fall under the material scope of the GDPR. The Art 2(2)(c) exemption for “purely personal or household activity” does not apply since you're offering the service to the public. You must consider GDPR compliance here. This is especially important as you are showing personal data to the public. Don't do that unless you have a very good reason, appropriate safeguards, and are clear to users how their information will be shown. On a high level, GDPR compliance involves working on the following questions: For what purpose are you processing personal data? Context: purpose limitation principle per GDPR Art 5(1)(b) What is the legal basis for processing? GDPR Art 6(1) lists the available legal bases. Here, consent, necessity for performance of a contract, or a legitimate interest could be a legal basis. They may have further obligations attached. A legitimate interest requires a balancing test that considers the data subject's rights and freedoms. Consent must fulfil the conditions per Art 7 in order to be valid. What is the minimal data necessary to achieve the purpose? Per the Art 5(1)(c) data minimisation principle, it is illegal to process personal data beyond what is necessary and adequate. You must provide data protection by design and by default per Art 25. Special categories of data per Art 9 such as health data are illegal to process outside of narrow exemptions. You must delete data once it is no longer necessary. What appropriate safeguards and security measures should you apply? Per Art 24 and 25, you are responsible for determining and implementing appropriate measures. This depends a lot on your specific context, so there's no checklist you can apply. Per Art 25(1) you must pseudonymize the processed information if that is compatible with the processing purpose. What further compliance measures do you have to consider? There are additional GDPR and non-GDPR compliance measures. From the GDPR side: Use the answers to these questions to write a privacy policy, including the information that you must provide to data subjects per Art 13. Consider whether you have to maintain a Records of Processing document per Art 30, or if you have to make a Data Protection Impact Assessment per Art 35. If you use third party services, figure out whether they are a joint controller or data processor and apply appropriate safeguards. If you have data processors, ensure that you have a contract in place that covers the items from Art 28(3). If you share data with other controllers (not processors) you need a legal basis for doing so. If you transfer data into a non-EU/EEA country (after 2020: non-UK country) you need a legal basis per Art 44 and have to cover additional items in your privacy policy. Ideally, the target country is covered by an EC adequacy decision per Art 45. For US-based companies, this is the case only when they have self-certified under the Privacy Shield framework. Non-GDPR compliance steps could include cookie consent banners, or showing a VAT ID. How can you prepare for data subject requests? Data subjects have various rights per Arts 15–23, subject to the modalities in Art 12. For example, a data subject could request that their information is erased from your website. The exact rights also depend on the legal basis you selected. You should figure out in advance how to deal with such requests.
GDPR is not a blanket ban on the handling of personal data. It is a set of guidelines when and how data may be processed and stored. Documenting the compliance with a deletion request is one of many purposes for which some data may be retained after a deletion request. Others would be past contractual obligations, legal documentation requirements, and even a balance of 'legitimate interests' of the processors and the data subjects. The processor might be able to argue that fraud/abuse prevention is such a legitimate interest. What if I want to create a service that does let users enter their friends' email addresses, and send those friends an email invitation to the service? Get a specialist lawyer on staff who can check your exact business processes. A web site like this cannot possibly give you a full explanation of the pitfalls.
The same page at the ICO website also lists what an organisation should do if they refuse to comply with a request: What should we do if we refuse to comply with a request? You must inform the individual without undue delay and within one month of receipt of the request. You should inform the individual about: the reasons you are not taking action; their right to make a complaint to the ICO or another supervisory authority; and their ability to seek to enforce this right through a judicial remedy. You should also provide this information if you request a reasonable fee or need additional information to identify the individual. Even if they did not inform you about this, the last two bullet points basically list your options. You can make a complaint (Art. 77 GDPR), or go to court (Art. 79 GDPR) requesting the online retailer to comply with your request. (Or do both). You can request a compensation for damages, but it is often difficult to prove if you have suffered (non-material) damages.