3 ms·

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 link

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?
  - gruez 5mo ago
    >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... That's just third party cookies. >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? You can get a new uuid, but then that'll be associated with a key that has a high attestation count, which is also suspicious. It's like detecting spam from an account that has 1000 posts in 1 hr vs an ip that created 1000 accounts in one hr making one post each. Both are suspicious.
    - repelsteeltje 5mo ago
      I still don't get how those 1000 posts tallied with previous UUID would get correlated with the new UUID. If it's only source IP address or similar finger prints, those are relatively easy to get rid off, hide, renew. (At least, when your goal is to do as many fake attestations as possible rather than use your device for something more useful)
      - gruez 5mo ago
        >I still don't get how those 1000 posts tallied with previous UUID would get correlated with the new UUID. The point is that you can flag accounts/uuids based on monthly attestation count alone, without correlating all the posts to a given account/uuid.
        repelsteeltje 5mo ago
        Yes, but isn't there an unplugged hole in the account creation (or fresh install) if that gets you a new UUID with 0 monthly attestation count?
        gruez 5mo ago
        You buy a new phone, install the app, and get an uuid with 0 attestation count. Now what? If you try to use that uuid to farm attestations, it'll be easily linked to that uuid. If you try to uninstall/reinstall, the attestation count will count up, eventually making making the newly created uuids immediately suspicious. You might try to create one uuid per month and then try to farm those indefinitely, but they could require you to reattest every month, which should come back with 0-1 attestations, but if you were farming uuids that'll be immediately caught.

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?
- gruez 5mo ago
  >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... That's just third party cookies. >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? You can get a new uuid, but then that'll be associated with a key that has a high attestation count, which is also suspicious. It's like detecting spam from an account that has 1000 posts in 1 hr vs an ip that created 1000 accounts in one hr making one post each. Both are suspicious.
  - repelsteeltje 5mo ago
    I still don't get how those 1000 posts tallied with previous UUID would get correlated with the new UUID. If it's only source IP address or similar finger prints, those are relatively easy to get rid off, hide, renew. (At least, when your goal is to do as many fake attestations as possible rather than use your device for something more useful)
    - gruez 5mo ago
      >I still don't get how those 1000 posts tallied with previous UUID would get correlated with the new UUID. The point is that you can flag accounts/uuids based on monthly attestation count alone, without correlating all the posts to a given account/uuid.
      - repelsteeltje 5mo ago
        Yes, but isn't there an unplugged hole in the account creation (or fresh install) if that gets you a new UUID with 0 monthly attestation count?
        gruez 5mo ago
        You buy a new phone, install the app, and get an uuid with 0 attestation count. Now what? If you try to use that uuid to farm attestations, it'll be easily linked to that uuid. If you try to uninstall/reinstall, the attestation count will count up, eventually making making the newly created uuids immediately suspicious. You might try to create one uuid per month and then try to farm those indefinitely, but they could require you to reattest every month, which should come back with 0-1 attestations, but if you were farming uuids that'll be immediately caught.