Comment by nness | Hacker News Reader

Comment by nness | Hacker News Reader

The article title is "Is Google reCAPTCHA GDPR Compliant?"

And its a good point — broad data collection has always attracted the mire of European regulators, and in the decision they state that they find that reCaptcha serves as both a security and analytics tool (due to its broad data capture.) I can't argue with that definition.

The solution, for Google, is to only conduct telemetry after the user has authorised that telemetry, allowing reCaptcha to function without the data collection consent. They already have such functionality in Google Analytics, but arguably, might be less valuable for Google without that data.

For the businesses using reCaptcha, its a problem. The article makes a fair point that you can't use the service if the user declines consent. But it is a reminder that any business operating in the EU at this scale must incorporate a data privacy specialist into their requirements gathering and review processes. It's just the price of the ticket to play in the EU.

You can argue the data collection is legit and does not need the user consent, because it is needed in order to perform the core function to separate bots from humans. Thus, no special consent is needed.

The different question is that if Google uses this data for purposes it is not intended. In this case the service might be still GDPR compliant from the website implementor point of view, but Google would be doing fraud by breaking their Terms of Service how the data is handled.

If a service doesn't work without respecting user rights, the service can't be used.

What's next? Capture a picture of your webcam to check if a real person is sitting in front of the PC?

This is already happening, with some remote working platforms requiring the camera on during working hours

Twitter also requires the employee to be in a dedicated room with a door that closes. At least they used to.

Some KYC processes in the EU (and likely elsewhere) do involve a webcam interview with a 3rd party who checks the customer‘s face and passport.

The question is also, why separate humans from bots? It makes creating useful scripts harder, doesn't it fall into "fair use" case which in EU is enforced even in software where you can modify it to be able to run it on your platform.

To prevent or at least cut down on spam? Pretty much the entire reason captcha systems were created in the first place and an entirely legitimate reason?

In addition to spam, preventing bots from buying up all the GPUs and PS5s in the recent past would have been nice.

Though in the end you're the one clicking busses and bikes and bridges and busses again and when you're through that charade, everything is gone anyway because the bots were faster/better at that..

It is up to the website owner to decide how they want to distribute the content, not the reader. What you see as fair is often not fair from the website owner point of view.

If you disagree with this you are always free to create a competing business without such captcha limitations for bots, and put your money where your mouth is.

Think about why the bots exist - it's almost always data theft or other schemes to abuse your API to profit. Taking money from your pocket.

>>because it is needed in order to perform the core function to separate bots from humans

The core function for most sites using recaptcha is not to separate bots from humans, so a consent is needed before sending data to a 3rd party not related to the core functions of the site or app

This does seem like a good legitimate use case.

However, if Google transfers the data collected to its American servers or daughter companies, that would still make for a massive GDPR violation, both for Google for breaking the law and, if the situation does not get resolved, possibly for the companies using Google's services while it knowingly violates the law.

> You can argue the data collection is legit and does not need the user consent, because it is needed in order to perform the core function to separate bots from humans.

You would have a hard time arguing that. The core function to separate bots from humans is done by requiring the user to identify certain images. The only data that needs to be "collected" (and even that doesn't need to be kept) is whether they clicked the correct squares.

That is not most of how it identifies bot traffic. The order you click them, how quickly you click, and where within each square you click for all ways humans and computers can be different.

But the real work is not about your interaction at all: this is how the invisible version can perform almost as well as the one where you click things. This involves comparing information about your computer's JavaScript environment with what they have seen elsewhere, and if you are running a bot farm it's pretty hard to keep your statistical distribution for all of these different attributes from looking odd.

> how the invisible version can perform almost as well as the one where you click things

I don't think it does for me. I run most websites in temporary containers, I do a lot of tracker blocking on DNS, uBo, etc., I clean cookies frequently.

Either those CAPTCHAs are really bad and are considering me human when they shouldn't, or all those things you mentioned are not necessary for their core functionality.

Several of the non-interactive signals would still pass through in those sorts of situations. I don't know exactly what reCAPTCHA collects, but if you look at something like https://amiunique.org/fingerprint you can get a similar idea of what's possible.

Yeah I get what you're saying. What I'm saying is that it's not required for its core functionality. Without all that, it still works by getting the user to click on images. Sure, maybe it's not just about validating the correct squares were clicked on. Maybe it analyses timing, how much the mouse moves around and whatever else. Nothing there requires collection and storage of user data. All it needs is to process it there and then. It can throw it all away as soon as the user clicks the button.

> Without all that, it still works by getting the user to click on images.

I don't see where you've shown that?

ReCAPTCHA v3 doesn't include any clicking on images, as far as I can tell because that doesn't actually add that much in terms of identifying bots?

> All it needs is to process it there and then. It can throw it all away as soon as the user clicks the button.

Even if they limited themselves to tracking how users clicked the button they'd still need to store it, so they could compare this user to other users and build models of what human/bot traffic looked like.

> ReCAPTCHA v3 doesn't include any clicking on images, as far as I can tell because that doesn't actually add that much in terms of identifying bots?

Perhaps I'm being considered human and just being generally unaware. It's possible. Do you have an example website where I can try it? I have uBo block recaptcha by default, so whenever a website uses it, it takes me a few clicks and page reloads until I get the prompt. I can't remember of a single instance where I didn't have to go through the challenge but maybe my own biases are in the way of me seeing it.

> Even if they limited themselves to tracking how users clicked the button they'd still need to store it, so they could compare this user to other users and build models of what human/bot traffic looked like.

This gives me the creeps. In any case, does this need to be accompanied by PII? And how can I validate that it's not?

It's almost certainly possible to defend the use of a reCAPTCHA-like tool without user consent under article 6 para 1(f) (legitimate interests). My concern with using reCAPTCHA would be the track record of Google - they have a long history of testing the boundaries of data protection law and accepting fines as a cost of doing business.

Google don't appear to even mention GDPR in the marketing materials or docs for reCAPTCHA; they do claim that reCAPTCHA Enterprise (a separate, paid-for product) can be GDPR compliant, but I'd take that with a big pinch of salt. Competing CAPCHA services make much stronger claims regarding GDPR compliance and are much more transparent about how the service uses personal information.

> But it is a reminder that any business operating in the EU at this scale must incorporate a data privacy specialist into their requirements gathering and review processes. It's just the price of the ticket to play in the EU.

This sounds very American. You don't need a data privacy specialist to operate in the EU. You need to develop with privacy first by design. Treat all PII as radioactive. Literally. Yes, if you need to bolt this onto existing US software to make it "compliant", you're screwed and you'll need to call in a containment team like when you find radioactive cargo in your business that is not normally expected to handle it.

A lot of times topics like GDPR and privacy are brought up on HN I'm seeing comments that act like it's black magic. It really isn't. It's trivial to be "good enough" as far as legislation is concerned. The problem is just that over the past decades and especially in the US we've seen myriads of online services sprout up that now often seem integral but were built with a complete disregard for privacy and now need to either be retrofitted or somehow contained to become compliant. It's like finding out paint is radioactive after it has been marketed for decades with no regulation or oversight.

Internet companies have been playing it fast and loose with privacy well past the point that people started pointing out it's a (ethical if not legal yet) problem. That is now coming back to bite them. I'm okay with that. It's just a shame so many businesses are caught in the crossfire because those companies have also tried their best to make themselves integral and unavoidable. Good luck trying to migrate away from AWS/Azure/GCP for example.

> It's trivial to be "good enough" as far as legislation is concerned.

I'd be very interested to read any tutorials/howtos/faqs/etc. about that. I might be tempted to create a (very small) side SaaS-type project (and I'm located in Europe), and the main reason I haven't done it yet is that GDPR compliance looks really, really scary to me.

Being compliant with regulations such as the GDPR is expensive. Lawyers, security, and annual third party testing. I don't profit off EU users so I block all non-USA traffic and avoid the issue entirely.

It’s like saying complying with criminal law is expensive because lawyers are expensive.

If you've been responsible for implementing GDPR compliance I think you may have a different perspective.

It's like saying complying with truth in advertising laws is expensive: most companies barely have to think about it because they comply by default but for some companies it is extremely expensive.

Of course it's extremely expensive for them because they're trying to get as close to breaking the law as they can without actually breaking it. That requires expensive lawyers, constant monitoring and extremely fast response cycles. E.g. there are a lot of big companies making good money of exaggerated but legal health claims and their claims are all not just vetted by a team of expensive lawyers but also documented and tracked in such a way that if they do end up getting sued they can immediately find out where they are using that particular claim and withdraw all advertising material using it to comply with a cease and desist.

So, yes, if you want to run a business that is either intended to be willfully negligent for no good reason or exploit users with as little informed consent as you can get away with (likely because what you want to do is not in their best interest), you'll need a team of expensive lawyers.

But compared to actual nuclear storage (which is highly regulated for good reasons), or storing certain financial data (which requires PCI compliance), or storing medical records (which in the US requires HIPAA compliance) or filing your taxes correctly, GDPR compliance does not actually require an expensive external audit and certainly not a regular one.

Of course SOC2 compliance or ISO compliance are different matters and they may be involved in demonstrating GDPR compliance to business customers but they're neither necessary nor sufficient to comply with the GDPR or the ePrivacy directive.

Well, you could have had that for cheap: being US-based currently makes you non-compliant by default thanks to your government's warrantless surveillance (look up Privacy Shield and why it died).

But, no, none of these things are required to be GDPR compliant. Of course if you want to build a business on processing PII (and especially if it's any of the protected categories, e.g. you want to process personally identifiable medical data) the GDPR requires more effort from you because it's harder to maintain your users' privacy while doing this. And if you actually have no business doing this but still need to find a way to coerce your users into surrendering their data against their own interests (e.g. behavioral analytics, insurance risk scoring, etc), it's even harder to do this in a compliant way and opens you up to more scrutiny (rightfully so, I might add).

These things are not required to be compliant. These things may be involved in demonstrating compliance. But the lengths you have to go to to demonstrate compliance is very much a function of how privacy invasive your business is. A nuclear power plant will have more detailed radioactive waste management and radioactive material containment plans than a watch repair shop that occasionally handles radium-coated mechanical parts.

Specifically, other companies may insist you go to greater lengths to demonstrate your compliance to them if they want to do business with you, the same way you don't just buy nuclear waste containment equipment from some guy on eBay.

I did mean it literally when I said treat PII as radioactive.

I do love this argument against GDPR (or any data protection) because it often comes down to "Screw the US consumer, I'm profitable because they have no protections, so no one should have any."

... which is kinda the US business sentiment in general, I suppose.

Funnily enough, I work in technology in Europe and have consulted on GDPR compliance.

Organisations either care a lot of about their data obligations and have dedicated teams and reviews, or simply don't care, and don't want that cost passed on to them. And service providers, not wanting to lose a sale, just go ahead with whatever is easier. In this case, they shot themselves in the foot by not conducting due diligence for what would have been a fairly easy to recognise issue.

(or worse, were advised, and that advise was incorrect. But based on what I can translate in the original document, that is may not have been the case.)

Reply on news.ycombinator.com