Is Google reCAPTCHA GDPR Compliant?
wideangle.co
wideangle.co
That is a weird use of the word "cookie". In normal usage, it doesn't mean a technology that accesses or stores the information, it is that information itself.
"Pixels" is also weird. I think that they mean tracking pixels, which are one-pixel images that are just there so that the browser has to request them from the server and the server can notice that request. They are a subclass of "Beacons". Calling them a "technology that can access or store information on a person's device" seems misleading. Also, reCaptcha wouldn't need them. They already have Javascript running on my PC, they don't need a tracking pixel to contact the server.
And yes, running JS in a users browser to store or access information is exactly the same. Taking a browser fingerprint and storing it server side is also the same, just harder to get caught doing. This whole trying to maliciously take these laws literally need to stop.
Also, I'm not trying to "maliciously take these laws literally". The law isn't limited to cookies, so you can't get around it by using a narrow definition of the word "cookie".
Or perhaps the author does have a technical background, which is why they attempted to give a clear yet simple explanation for the non-technical?
People hear cookies are bad, they get pestered by cookie banners, so it makes sense to use cookie as an umbrella term. Their definition of tracking matches the law which is the important part.
(The main exception to their list is scripts, which are only cookie-like to the extent that they use cookies or other client side storage)
Could be a unique pixel that does or does not exist in the browser cache (is or isn't fetched (fought?)).
A pixel can store information as long as the cache works as expected.
I've seen this a number of times in design meetings: someone will say "oh, an account registration form, we will of course need a CAPTCHA there", everyone will nod their heads and move on. In reality, in most of those cases, no one will ever conceivably even try to automate/script the thing being designed.
Spammers will spam everywhere they can. My minuscule personal site suffers from it very rarely, but I can imagine anyone getting a lot of page views making it worth it.
I don't event want to know what my site would look like without my own countermeasures + reCaptcha + if it was a service where a user account has any kind of "value"...
Is such an account using a lot of resources?
I appreciate the sentiment, as I had it, but rest assured any future publicly accessible form I build will get at least a CAPTCHA in front of it.
I did once run into an issue where a signup form was abused by a spammer, but that was a simple fix (tip: in verification emails, do not include any information that the user typed in the form).
If you are careful with your forms, you don't need captchas. Captchas add a lot of friction for some users, so if they can be avoided, they should be.
Proof of work isn't a CAPTCHA.
or was it more complicated, like not needing to store which fake account had which details?
Hi <name>, thank you for signing up...
The spammers put their spam message in the name field, so my server started sending messages like this:
Hi Get free cialis now http://example.com, thank you for signing up...
And if they really are targeted, I don't think CAPTCHA will help much.
Once you release something to the wild you need to have robust controls in place to prevent one person or group of people from using all your resources.
I wouldn't release a product that doesn't have rate limiting of some kind, of which a captcha is one way to rate limit.
Always trust people to push the boundaries of your app as far as they possibly can. I have yet to build a system where someone doesn't. And that includes tools I've built for inhouse users:(
Whether intentionally or not, they always find a way to push the boundaries:)
Edit: And come to think of it, A TON of websites do "smarter captcha" or whatever you want to call it, because in one of my computer I enabled the resist fingerprinting setting on Firefox, and I get a captcha every visit on some sites that NEVER show a captcha (I think it might be cloudflare driven, but unsure). Like Walmart comes to mind, it shows me a pill looking thing where I have to hold the mouse click until it fills.
I discovered a classmate was involved in some event, and found the event's website. They didn't have a captcha. By your logic, this was the right choice.
In reality, my dumb ass decided it would be fun to script something that would register millions of users (another classmate ran the script with me). After a few hundred thousand registration, the website was brought to its knees. I was a bit shook, but didn't think much of it.
Next morning I come into class, and was reprimanded by my teacher. Turns out, the owner of said event had threatened to sue the school and me, among other things. What had happened was their servers were down, their email server was brought to its knees, their web servers had died, and generally I had caused a lot of damage without even thinking about it. It caused them to potentially lose some money. None of this was my intention, of course, but I didn't know much better.
Point is, kids will kid, and spammers will spam. There are plenty of bots that just scrape the internet and fill out forms indiscriminately.
Captcha may or may not be the best option here (I'm always of the opinion it's not, especially not reCAPTCHA), but something has to be put in place, even if to stop the majority of bad actors.
one per library per day...
This is a classic example of how "just do this" kind of thinking can lead to terrible results.
Do you now see how "just limiting the sign ups from one IP each day" can go very very wrong?
For lots of these countries their total allocation of IPv4 addresses is < 20 per 1000 people and the nature of their access (through glorified internet cafes) mean that you will have some IP addresses that really are totally legit, yet have LOTS of users.
One size fits all is very dangerous on the Internet.
One the one hand, I assume bad due to cheap equipment. On the other, it's not like v6 addresses are expensive and you need some way of addressing every subscriber anyway. As more people sign up (as the country gets more people with internet access), you need more equipment which could support v6 out of the box, and the excuse for CGNAT I've always heard is old equipment that is harder to upgrade than to put a NAT router in front of. Could go either way from my POV.
If the roll-out is good, then all those people are already taken care of and the minority left on v4 CGNAT aren't bothered by the collective rate limit.
(To preempt the eventual remark that users can generate a billion addresses in v6: rate limiting on v6 works by limiting whatever prefix the ISP gives out to subscribers, like /56, not individual addresses the way it's often done with v4.)
As an aside, it should also be kept in mind that not every use case involves signing entire countries up for their service, even in an ideal case.
In fiber some do the same, although thankfuly most place v4 behind a cgnat while offering ipv6.
The whole 1 ip 1 user even if dynamic quite false and is a mess.
If you're collecting sign-up data for something local, then most likely not.
FWIW, I learnt about this the hard way.
As far as I could tell this was an internal form that wasn't publicly accessible
There are more than enough people running automated crawlers, probably fed from Google "inurl: contact-form" searches or whatever, and just blanket spam you.
https://www.ra-plutte.de/lg-muenchen-dynamische-einbindung-g...
This makes it impossible to use any components hosted by third parties without getting consent by the users. And for components hosted in a different country than the visitor, even consent might not make using those external components legal.
This is bad and not in line with reality. The IP can only be turned into personal information via cooperation of the users internet provider.
So in Europe, the whole internet is made illegal based on a wrong assumption.
By this argument, isn't the same true of a physical home address?
> I do think considering IP address personal is a bit of a reach, especially given the common case of ephemeral addresses.
Except that isn't strictly "the common case". DHCP leases are often for long-ish periods of time on fixed line broadband services. The IP for my home router, for example, has been the same for weeks or months at a time.
If you can look up a user account by IP address, then the IP address is personal data.
There's nothing wrong with receiving IP addresses on your website, though. You can log IP addresses and use them for detecting fraud and other kinds of abuse without requiring consent. Third parties can do the same, as long as they follow the law and as long as you clearly document what information you're sharing/making users share in your privacy policy.
You can't use personal information for tracking and ad purposes without consent, though, and you can't partner up with other companies that do it for you. It doesn't matter if you're tracking IP addresses, cookies, passive fingerprints, or some kind of supercookie; you need a legitimate reason or explicit consent to process that kind of information.
Not 100% true, you can often trace back users by IP using leaked databases and through companies that sell user data. Might not be legal, but you definitely don't need cooperation from a ISP.
Therefore even on a technical level this EU legal interpretation is insane, hundreds or thousands of people can potentially use the same IP address, how is that personal information then?
I don’t think it’s insane because the more common use is just to pattern match to identify the individuals. While lots of people may share, many do not (eg, everyone in my home shared an external IP but that is frequently just one person).
Google can use this IP and browser traffic to separate out individuals (eg, I don’t watch YouTube and my kid never checks vanguard) to the level they convince advertisers that they know the individual. I expect this is why my kindergartner sees ads for car insurance.
ISP knows exactly who used IP at that point in time (they are even obliged by law to log them). Therefore IP from which a request was sent can be used to uniquely identify the device, with 100% certainty. Therefore it is (usually) a personal information.
https://commission.europa.eu/law/law-topic/data-protection/r...
and Person B has a document saying an 80 year old male living at 1600 Pennsylvania Avenue has Chlamydia
do you think only Person A holds private information?
Is the password personal data?
You have to draw the line of correlation difficultly somewhere.
No, just websites which include components hosted by third parties. This is not the whole internet (e.g. HN doesn't include third party components).
HN is also hosted by a different company. They get your IP too.
HN doesn't communicate my IP to this service.
> HN is also hosted by a different company. They get your IP too.
If they store my IP, they should treat it as PII to be compliant
All European providers as well as major international provider like AWS [1] have compliance statements. The EU companies are more likely to take it seriously, e.g. Hetzner only logs the first three segments of your IP (i.e 24bit IPv4 or 48bit IPv6). Every other EU-based provider I've used at least offers it as an option. If you run your own server, there are nginx and apache modules [2] that anonymize your logs.
It's real. We're 100% serious.
[1] https://d1.awsstatic.com/legal/aws-gdpr/AWS_GDPR_DPA.pdf [2] https://www.supertechcrew.com/anonymizing-logs-nginx-apache/
There are six lawful grounds for processing personal data under GDPR; only one of those grounds is consent. Consent is not always necessary, nor is it always sufficient.
An IP address is potentially personal data, because it could relate to a natural living person. There are all sorts of legitimate reasons to use that data without consent, the most obvious being to fulfil a request by the user. You will run into issues if you're using that data in ways that aren't strictly necessary - keeping logs indefinitely, using that data for marketing purposes, sharing that data with third parties without good reason and without adequate safeguards etc.
As they did in the judgement I linked to.
A judge can always claim you could have used a local version of whatever external resource you used.
YOU provide the service so YOU are responsible for the way your user's data are processed and must ensure that it's processed according to the rules (requiring consent when necessary)
If you can use a local version of an external resource, you should. Minimisation is an integral principle of GDPR. There are plenty of circumstances where it would be impractical or impossible to perform a necessary function without sharing data with third parties, but that still needs to be done with appropriate thought and care.
I would have a great deal of confidence in embedding a resource provided by Stripe; I would have absolutely no confidence in embedding a resource provided by Google.
All GDPR is asking mostly is: you only gather minimal PII to provide a service (if needed at all). If you use PII for another purpose than providing the service or meeting operational purposes (like fraud detection or monitoring your infra), then you must obtain the consent of the user (for marketing or selling your users data for example). This extends to your providers too (like Google Analytics...)
The problem is that a lot of "internet services" take for granted that they can do whatever they want with the data they got for a specific purpose... even without informing the user! And that's not good... so GDPR has been created.
But if your service is "fair" to the user (meaning: you only use the datas to provide the service), then there's no problem...
Yes it's selling: You provied the data, Google gives you hosted services back. If you think embedded fonts are useful for you, you can host them. Then you pay the bill and not your users.
reCAPTCHA, in this case can be consider as "fraud detection".
Can we do it without PII? Yes. Maybe. With lots of effort and less optimal result.
Does this fit the "necessary" provision of GDPR? This depends on which court you ask.
reCAPTCHA does not add "direct" value to the user, it even cost some harass... but it is a life saver if your service is big spam target.
This is based on some very faulty knowledge of GDPR and the law.
You are allowed to process data without the consent of the user for various things. This would include their IP address. You're allowed to have third party data processors process data on your behalf without user consent for various things.
The Google Font ruling was partially due to who Google is. Google data mines, they're famous for it. So giving Google data they can use to map to your internet persona which may even be linked to your name directly is obviously something many people want to do only when they consent. The fact Google Fonts could be self hosted was another part of the reason for the ruling. That is, sharing the information wasn't required to be able to perform what the actions they wanted to perform, use a font.
Data processing done by US companies is not currently GDPR compliant. However, no one is enforcing that. It would be a complete mess and there are far too many. In reality, everyone is ignoring it waiting for the new laws to be created to make it legal. The reason the US companies are an issue is a US court can issue a judgement to a US company and they are forced to comply no matter where the data is.
> This is bad and not in line with reality. The IP can only be turned into personal information via cooperation of the users internet provider.
This is also not true. If you visit a website that sells B2B accounting software and your IP is identifiable to a company. You could phone up the company and ask to talk to the person who is responsible for finance. If there is only one person, boom easily identifed. There are also various other ways.
> So in Europe, the whole internet is made illegal based on a wrong assumption.
Really, your comment is wrong based on multiple wrong assumptions.
Is based on a wrong assumption.
> ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;
This is not out of step with reality nor a wrong assumption, it is simply a definition. It is motivated somewhat in the considerations of the GDPR.
> (26) The principles of data protection should apply to any information concerning an identified or identifiable natural person. Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person. To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. This Regulation does not therefore concern the processing of such anonymous information, including for statistical or research purposes.
> (30) Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.
It’s not a direct identifier but with geo-ip or other data, it can identify an individual (eg, have 100 possibilities and geoip narrows it down to only 1 in that region based on IP).
The PII aspect isn’t based on getting a link from the provider. The PII aspect is based on the IP itself standing out in data and allowing reidentification. It’s not 100% accurate, but accurate enough to make money off advertising.
Except when it is. I have a semi-permanent home IP (it only changes when the MAC address on my router changes and I get assigned a new lease) and only one user in my home. My IP address pretty uniquely identifies me.
I don't understand the point keyboard warriors who insist IP doesn't identify a person and IP isn't PII are trying to make.
Are they just being pedantic? Because yes, often an IP is shared. Yes, obviously the legal system shouldn't assume a IP equals a person. That would be very problematic.
But when it comes to mere tracking, an IP can absolutely identify directly a person. So why not just treat it as such all the time? What's the downside of considering IP to be PII?
Good.
There's very few legitimate uses for third party hosted proprietary components.
Why it became standard to load simple things like scripts or fonts from third parties, that can be trivially hosted locally, is beyond me.
(I'm not a lawyer.)
That's a very extreme take. They're how many services actually exist.
Also, consent to an embedded video? My brother in Christ, your browser requested the video.
This kind of attitude is why I block JS and cross-origin requests by default. Unfortunately this is not a reasonable option for the less technically inclined who deserve protection too.
Hell, even a small startup with a few thousand euros can start to track and trace user behaviour on a massive scale that in reality you wouldn't or shouldn't be able to do.
The tooling (free, cheap and not) at our disposal nowadays makes everything so easy that even something that in theory should not serve as identifier can be used to identify you - so let's start with the most common ones: IP, email, etc.
The Internet in Europe is not illegal - it's just pure BS that a simple page like reuters.com contains references to 14 external scripts when loaded, when actually all you need is 2 maybe 3 scripts (the CDN to load images and videos + the page itself) - the rest is crap used explicitly to identify and market people - that's it: Ads, Ads and probably uglier things to do just to profile people online.
Instead of finding an innovative solution (how about mandating ISPs to make IP addresses unmappable to a user?) they only know one solution: Making things illegal, even if in almost all cases the use is benign or even makes a lot of sense.
I can't see how this would work in practice: you'd still have the same IP when visiting site A where your real identity is known, and site B where you didn't give them consent to access your information. The only reasonable course of action is to classify your IP as an identifying info, as site A and B exchanging info would result in your exposure (or site A and B being the same site, but you logged as different users...)
Perhaps your point was on giving user different IPs for every site, potentially for every request, but then the consequences would have to be handled worldwide.
Not true. Google is used so widely that they can track and profile me all over the internet, because they can easily combine on which page I've requested fonts from them. And once I log into YouTube, they can link all those information about medical conditions I googled directly to me personally.
- on the benign intent and accidental violation: is it natural to go load fonts from a third party service in the first place ? I get why we arrived at this point, but hosting yourself the base resources you're using for your site shouldn't feel like some huge burden or leap from the norm.
If we really see a shared benefit to having fonts on some common platform, I'd also wish it wasn't Google. Perhaps Cloudflare or Fastly ?
- on IP being worthless to Google: is the "unless they get any link to your identity" even hypothetical ? I am a paying Google customer and extensively use their service. And we all do to some extent; trying the "let me live my daily life but block and avoid anything that touches Google" game would still be as critically punishing today as it was 4 or 5 years ago.
Ironically, even in the USA with the CCPA they are trying to regulate this somehow. This is just not something you can leave untouched. Without even mentioning other non-EU countries (China/Russia/India, etc.) that have even stricter data regulations.
> Making things illegal, even if in almost all cases the use is benign or even makes a lot of sense.
What is there benign about sending your IP address to 10-15 external services that have nothing to do with providing you the service in the first place? Try to install the NoScript extension and you'll see that 90% of the websites only require the main domain to be unblocked to be used. A few more websites require allowing 1-2 additional more scripts (CDN or ... payment systems/redirects, etc..). The rest is just your data being treated like toilet paper for marketing purposes. And I wouldn't even mind if they stopped there (marketing website A buys the data, and they target you with some crappy ads you won't even click on): no, they sell, and the buyer resells, etc.
Is this really what makes a country innovative? Advertisements? I thought that innovation was self-driving cars, electro cars, new ways to fight diseases, digitalizing bureaucracy (which can be done without giving away your personal data to random online companies), etc.
But if you are a small company in Europe that for example is producing a better and lighter cardboard box, you will have to hire a data privace specialist because you may get sued by some random idiot if you accidentially link to Google Fonts as a convenient way to display fonts, this certainly binds a lot of valuable mindshare and resources and therefore is bad for innovation. You cannot believe how much startups here have to think about GDPR even if they do not collect any data at all. Read the other answers in this thread. There are others who say that linking to Google Fonts is equal to selling your customers' data to Google. What a joke!
Of course startups here - and everywhere else! - have to think about applicable law. Just like if you want to start a transportation company you'll have to think about applicable law. If a company does not collect any data at all then the GDPR is a complete no-brainer.
Try this and see if you can make it work for you: to identify an individual you need ~33 bits. An IP address, even though it doesn't quite get you there gives you a very large fraction of the number of bits required. Adding a few more makes the individual identified. So therefore it is a very good idea not to allow access to the IP address to unrelated parties from a privacy point of view.
<quote> If you don't understand why including third party resources for developer convenience is a bad idea then you probably shouldn't be building commercial websites.
An IP address can be trivially combined with the ISPs data and provide the exact user of an IP during any point in time.
> An IP address can be trivially combined with the ISPs data and provide the exact user of an IP during any point in time.
Not even then.
Sounds good to me, that's the way it should be. I shouldn't have to use third party extensions to stop my browser from automatically loading facebook crap every time I visit websites that aren't facebook. Companies should only include 3rd party components in their websites if there is a very good reason for it, and only then after the user has explicitly consented to it.
That is simply not true, please do not spread misinformation like this.
Using/Embedding third-party resources is allowed IF it is e.g. technically necessary to provide the service or core functionality at all.
Collecting personal information and using a third-party service to do so in a shop checkout? That's okay.
Collecting personal information and shoving everything into Google Analytics because you want to know how many people visited your site? Not so okay, there are less intrusive ways to do that.
Did I get that right?
That's nuts.
French newspapers don't seem to agree with your interpretation of GDPR, as you are almost always facing a “consent or pay”-wall…
Hitting refresh until I got one with an example picture was pretty common until I learned some vocab.
I should really make a browser extension for this.
A quick check with the network inspector doesn't obviously show this data being sent.
And obviously to punish a company, the EU would need to prove this data is sent - a hard thing to do when the code of recaptcha is deliberately designed to prevent reverse engineering and analysis.
The generated fingerprint for these scripts is personal data, it pretty much directly refers to you as a person, that's the intention of the system. That's not necessarily a problem, though. These types of detection algorithms are perfectly allowed without explicit consent, just like other types of fraud and abuse detection.
There are two basic choices to avoid that - in some cases you can just host the resources yourself so the client browser does not connect to hosts operated by others, or you can operate a proxy so that the client browsers requests are relayed and anonymized before going to a third party.
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.
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.
What's next? Capture a picture of your webcam to check if a real person is sitting in front of the PC?
Twitter also requires the employee to be in a dedicated room with a door that closes. At least they used to.
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.
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
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 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.
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.
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.
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.
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?
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.
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.
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.
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.
... which is kinda the US business sentiment in general, I suppose.
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.)
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.
> mCaptcha makes interacting with websites (computationally) expensive for the user. A well-behaving user will experience a slight delay (no delay when under moderate load to 2s when under attack; PoW difficulty is variable) but if someone wants to hammer your site, they will have to do more work to send requests than your server will have to do to respond to their request.
For example a raspberry pi (using as a substitute for a phone) can do about ~100 hashes a second while my laptop does ~2400. That's 24x faster so if it took my laptop 2 seconds it would take a mobile device ~48 seconds.
See the issue yet? :P
EDIT: According to the screenshots of XMRig for android you only get about ~35H/s which means it would take over 2 minutes to pass a captcha on a phone.
According to the docs (https://github.com/mCaptcha/mCaptcha/blob/master/docs/CONFIG...), you can set three difficulty levels:
MCAPTCHA_CAPTCHA_AVG_TRAFFIC_DIFFICULTY
MCAPTCHA_CAPTCHA_PEAK_TRAFFIC_DIFFICULTY
MCAPTCHA_CAPTCHA_BROKE_MY_SITE_TRAFFIC_DIFFICULTY
The defaults are set such that avg traffic takes ca 0.02s on an average system. Even if you have a really really slow system, I don’t think you‘ll ever spend more than 2s there.
According to the screenshots of XMRig for android you only get about ~35H/s while my laptop does ~2400. That's 68x faster so if it took my laptop 2 seconds it would take a mobile device ~130 seconds.
It screws with mobile users and makes the whole crypto PoW thing about it using too much energy many times worse. Not to mention botnets could make use of enough computing power to easily outpace any captchas thrown at it.
Is that for the specific proof of work algorithm mCaptcha uses? While I don't think you're going to get something that runs equally quickly on a low-end phone and high-end desktop, if it depends entirely on sequential operations and is not optimization-friendly you should be able to get much closer than 68x?
I think we‘d need to compare apples to apples, and not use Monero mining as a benchmark for mCaptcha. Also, as I wrote in another comment, the average case (server is not under attack) is 0.02 seconds on a laptop, and probably 0.4s on an Android device even if we do use xmrig-android as comparison. Compare that to manually identifying stairs on pictures with crappy quality (10 seconds?).
If you've got a bot farm tunneling traffic through residential IP addresses (hello, free VPN clients!) then those extra tries aren't such a problem.
Hell, some spammers are paying actual people to solve reCAPTCHAs. Those people do nothing but click fire hydrants all day. There's no way to prevent those clickfarms from working without some advanced traffic analysis that will break the internet for a significant amount of people behind weird carrier middleboxes.
reCAPTCHAs are excellent at keeping away very basic bots, like Python scripts that just call HTTP endpoints. If you're trying to fight bots using browsers (WebDriver and friends), blocking bots becomes significantly harder, to the point your normal users will start to suffer if you set an effective bot prevention limit.
reCAPTCHA v3 doesn't involve clicking on images.
Slightly longer summary: if consent is granted, then you can use ReCAPTCHA³, but a bot programmer would just choose to have the bot click no on the consent prompt. Denying access after nonconsent is allegedly² illegal because attaching negative consequences to the 'no' button makes the 'yes' button no longer be considered a freely given consent¹.
¹ https://autoriteitpersoonsgegevens.nl/themas/internet-slimme... "Mag een website of app mij toegang weigeren als ik geen tracking cookies accepteer? \n\n Nee. U moet de mogelijkheid krijgen om tracking cookies te weigeren. Zonder dat dit nadelige gevolgen voor u heeft." Basically says: can I be denied if I say no to consent? No, it may not have negative consequences. (Don't y'all love national authorities' information about EU-wide legislation? So much fun translating for english audiences)
² because a judge can overturn what the data protection authority (DPA) claims. I am not aware of case law on this, but I am not a lawyer.
³ assuming this French DPA speaks for all of the EU, which is not an automatic truth, but almost always the case. There may be implementation differences but I am not aware of any significant ones. The only annoying part is that each country's DPA has to put their stamp on it to reaffirm it for that country, and humans tend to have a bit of RNG in what opinion they end up forming based on the same text.
Users however tend to be greatly annoyed and inconvenienced by reCAPTCHA, which has grown increasingly difficult to decipher for real users. It is basically insulting to present real users with a CAPTCHA.
As a developer, personally I am very happy with this decision, and am thankful that the GDPR is finally making management take user privacy into account.
1. Analytics
2. Third-party resources
3. CDNs
4. DDOS protection services
5. reCAPTCHA
Anything else?
Though you're right that captcha/fonts etc should have been benign uses, if it could be anonymized/proxied then maybe that would have been a good solution.
BTW the sides could simply respect the Do-Not-Track flag but somehow they prefer to annoy their users, just like it's on purpose to blame privacy laws.
In addition, reCAPTCHA also accesses the domain gstatic.com. As can be read on Google websites, this domain is also used by other tools. Thus, cookies can potentially be exchanged via this domain.
If you store a cookie to know to not track you don't need consent as long as you don't track which users have this cookie.
https://www.justsecurity.org/10318/video-clip-director-nsa-c...
I still believe that the first step to stop tracking should be done on client side (block 3rd party cookies by default, delete cookies on tab/window close, except those manually whitelisted, to stay looged in), but google still collects way too much data on all of us.
But more seriously, that's not how it works. The regulations are already very permissive for smaller businesses. The heavy fines exist for the worst offenders. If you can demonstrate you made a conscious effort and just fell short and have already started trying to make amends when notified, that's often good enough. Of course if you just throw your hands up and decide privacy is just too hard, you'll be treated like any other loose gun.