Hacker News Reader

Comment by varenc | Hacker News Reader

I would think that when you're viewing recaptcha on a site, if you have 3rd party cookies disabled the embedded recaptcha script won't have anyway of connecting you with your Google account, even if you're logged in. At least that's how disabling 3rd party cookies is supposed to work.

View on HN

Of course, if you have 3rd party cookies disabled, Google would never link your recaptcha activity to your Google account.

They just link it to your IP address, browser, operating system, screen resolution, set of fonts, plugins, timezone, mouse movements, GPU, number of CPU cores, and of course the fact you've got third party cookies disabled.

"Oh, that's interesting...there is one other user that matches all of that metadata"

Isn't Chrome shifting to blocking 3rd party cookies by default? If that's the new default than the default behavior would be that being logged into Google isn't used as a signal for recaptcha

Do you really think they won't make a hidden whitelist for their own domains?

There'd be no way to hide this. If 3rd party cookies are disabled it's trivial to observe if an embedded google.com iframe is sending my full google.com 1st party cookies in violation of the 3rd party cookie settings. There's no pinky promises involved, you can just check what it's sending with a MITM proxy.

I'm sure they're doing other sketchy things but wouldn't make sense to lie in such a blindingly obvious way. (I just tested it, and indeed, it works as expected)

So like X-Client-Data which in many cases uniquely identified you but was, pinky promise, never used for tracking. Sent only to Google domains.

https://9to5google.com/2020/02/06/google-chrome-x-client-dat...

that would fall under "I'm sure they're doing other sketchy things".

Reply on news.ycombinator.com