Hacker News new | past | comments | ask | show | jobs | submit login

If they looked for identifying information in cookies or browsing history people would be even more upset and spammers would just simulate it with browser bots... which is why I believe it takes a black box approach to each detection regardless of external state. Besides obviously the cookies set within the iframe of the recatcha.

This of course doesn’t help explain why Firefox is so heavily targeted by what’s supposed to be a neutral utility like Google Analytics...

I've heard that being signed into your Google account can make the challenges simpler, presumably reducing things like the noise and the slow-fade load animations.

That too could be isolated to a single reCAPTCHA session, keeping within the scope of a single iframe or page load.

The idea of tracking your history across multiple reCAPTCHA loads across multiple domains to build a user profile is what sounds like a giant privacy red flag, even though it's entirely possible given the current implementation.

Additionally asking hosts to include JS directly onto their domain which sets 3rd party cookies/data across every page in addition to tracking referring domains is equally a bad idea. reCAPTCHA 2/3 does require loading 3rd party JS directly on page, which I'd imagine is necessary to create callbacks in the frontend upon verification (as iframe content messaging is very awkward):


Ideally the JS simply loads an iframe of the captcha HTML and handles the callbacks from events in the iframe. That's it. It shouldn't be touching anything else on your website. I'd be curious to see a reverse engineering to see how much the JS really does...

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact