5 ms·

recaptcha v3 will require the human to have a Google certified android device (i.e. no GrapheneOS or LineageOS etc.) and a dedicated iOS app which leaks device

by heroh 5mo ago

recaptcha v3 will require the human to have a Google certified android device (i.e. no GrapheneOS or LineageOS etc.) and a dedicated iOS app which leaks device ID and other data. Google will get to know every user browsing the web and link it to a smartphone. Since they’re rolling out government issue ID verification at the OS level, this change will allow Google to identify a random web visitor to a govt ID. https://support.google.com/recaptcha/answer/16609652?hl=en https://support.google.com/recaptcha/answer/16609652?hl=en

brookst 5mo ago
More info on how an iOS app can leak device ID? I thought Apple did away with access to device IDs and only provides a per-developer ID.
- gruez 5mo ago
  The "device ID" part is probably false and a red herring. What actually matters is that google can correlate which challenges a given device is solving, so if it's solving 10k challenges per day, it can be marked as being suspicious.
  - repelsteeltje 5mo ago
    Sounds pretty much like they're identify the device, then. Or is "device id" Apple lingo for a specific tech?
    - gruez 5mo ago
      No, on both android and ios device id implies some sort of identifier that's reusable across apps. Otherwise a uuid that you generate and write to storage could qualify as a "device id".
      - repelsteeltje 5mo ago
        So, essentially a super cookie? That is, generated once (at random or arbitrarily) and then included with proof of work? But not a fingerprint or otherwise linked to identity? But then that would not work against correlating fraud detection as sketched above. A client could simply reset the app every now and then to generate a new UUID.
        gruez 5mo ago
        >So, essentially a super cookie? That is, generated once (at random or arbitrarily) and then included with proof of work? You're just describing a regular cookie. >But not a fingerprint or otherwise linked to identity? You'll have to reverse-engineer the app to figure out whether it's actually fingerprinting, and whether it's fingerprinting to make sure it's a real device (vs emulator) or it's fingerprinting to uniquely identify someone. I suspect they're complying with app store guidelines and not doing the latter, because it's not worth the PR hit to just to vaguely improve a product responsible for <1% of their revenue. >But then that would not work against correlating fraud detection as sketched above. A client could simply reset the app every now and then to generate a new UUID. The attestation result contains a count of attested keys generated in the past 30 days, which detects this case without a "supercookie" that persists across uninstalls. https://developer.apple.com/documentation/devicecheck/assessing-fraud-risk https://developer.apple.com/documentation/devicecheck/assess...
        repelsteeltje 5mo ago
        > You're just describing a regular cookie. Yes regular cookie from Google's perspective, but super in that it works across sites. If for some reason you don't just take Google's word you might suspect they collude and share / sell your identity to the site as well... > The attestation result contains a count of attested keys generated in the past 30 days, which detects this case without a "supercookie" that persists across uninstalls. Ah. So there is something special limiting control over the UUID? Or is there some way of correlating the physical device to the attestation history? Why wouldn't I be able to reset and re-enroll in the app and then have it generate me a fresh new cookie attestation history?
- heroh 5mo ago
  It’s in the Apple app store App Privacy disclosure [1] Location (“coarse location”), identifiers (“device id, user id”) ^ both are deemed a necessity for app functionality, with deviceID required for analytics too. [1] https://apps.apple.com/us/app/recaptcha/id6746882749 https://apps.apple.com/us/app/recaptcha/id6746882749
  - brookst 5mo ago
    I don't see "device id" on that page, just "Identifiers" I don't believe that iOS apps get a stable device ID. It may be that Google is generating one, and it can be shared across Google apps. But I'm pretty sure there is no global device ID that's common across all apps. The original point stands that if you use recaptcha and you're signed in to a Google account on the device and you then use another Google app and you've done some form of identity verification with Google, then Google could link identity to recaptcha. But I think the claim was over-broad about device ID.
repelsteeltje 5mo ago
So at 3x times the monetary rate, Google is literally selling it's customers?!
- gruez 5mo ago
  >Google is literally selling it's customers?! You can characterize this commercial arrangement as whatever you want, but not meaningfully different than what they had before, where they were getting users to click boxes and charging businesses per "verification".

by heroh 5mo ago

brookst 5mo ago

More info on how an iOS app can leak device ID? I thought Apple did away with access to device IDs and only provides a per-developer ID.

gruez 5mo ago
The "device ID" part is probably false and a red herring. What actually matters is that google can correlate which challenges a given device is solving, so if it's solving 10k challenges per day, it can be marked as being suspicious.
- repelsteeltje 5mo ago
  Sounds pretty much like they're identify the device, then. Or is "device id" Apple lingo for a specific tech?
  - gruez 5mo ago
    No, on both android and ios device id implies some sort of identifier that's reusable across apps. Otherwise a uuid that you generate and write to storage could qualify as a "device id".
    - repelsteeltje 5mo ago
      So, essentially a super cookie? That is, generated once (at random or arbitrarily) and then included with proof of work? But not a fingerprint or otherwise linked to identity? But then that would not work against correlating fraud detection as sketched above. A client could simply reset the app every now and then to generate a new UUID.
      - gruez 5mo ago
        >So, essentially a super cookie? That is, generated once (at random or arbitrarily) and then included with proof of work? You're just describing a regular cookie. >But not a fingerprint or otherwise linked to identity? You'll have to reverse-engineer the app to figure out whether it's actually fingerprinting, and whether it's fingerprinting to make sure it's a real device (vs emulator) or it's fingerprinting to uniquely identify someone. I suspect they're complying with app store guidelines and not doing the latter, because it's not worth the PR hit to just to vaguely improve a product responsible for <1% of their revenue. >But then that would not work against correlating fraud detection as sketched above. A client could simply reset the app every now and then to generate a new UUID. The attestation result contains a count of attested keys generated in the past 30 days, which detects this case without a "supercookie" that persists across uninstalls. https://developer.apple.com/documentation/devicecheck/assessing-fraud-risk https://developer.apple.com/documentation/devicecheck/assess...
        repelsteeltje 5mo ago
        > You're just describing a regular cookie. Yes regular cookie from Google's perspective, but super in that it works across sites. If for some reason you don't just take Google's word you might suspect they collude and share / sell your identity to the site as well... > The attestation result contains a count of attested keys generated in the past 30 days, which detects this case without a "supercookie" that persists across uninstalls. Ah. So there is something special limiting control over the UUID? Or is there some way of correlating the physical device to the attestation history? Why wouldn't I be able to reset and re-enroll in the app and then have it generate me a fresh new cookie attestation history?
heroh 5mo ago
It’s in the Apple app store App Privacy disclosure [1] Location (“coarse location”), identifiers (“device id, user id”) ^ both are deemed a necessity for app functionality, with deviceID required for analytics too. [1] https://apps.apple.com/us/app/recaptcha/id6746882749 https://apps.apple.com/us/app/recaptcha/id6746882749
- brookst 5mo ago
  I don't see "device id" on that page, just "Identifiers" I don't believe that iOS apps get a stable device ID. It may be that Google is generating one, and it can be shared across Google apps. But I'm pretty sure there is no global device ID that's common across all apps. The original point stands that if you use recaptcha and you're signed in to a Google account on the device and you then use another Google app and you've done some form of identity verification with Google, then Google could link identity to recaptcha. But I think the claim was over-broad about device ID.

repelsteeltje 5mo ago

So at 3x times the monetary rate, Google is literally selling it's customers?!

gruez 5mo ago
>Google is literally selling it's customers?! You can characterize this commercial arrangement as whatever you want, but not meaningfully different than what they had before, where they were getting users to click boxes and charging businesses per "verification".