[jsnell]

According to this:

https://github.com/WICG/turtledove/blob/main/FLEDGE_k_anonym...

You'll need to spend a Private State Token to call the k-anon API, minting PSTs is rate limited on the server side, and the client and server still cooperate to make forging PST requests hard (e.g. device integrity attestation, requiring the user be signed into Chrome). What I think this means is that you could undermine the k-anonymity in individual cases by large amounts of manual work, but not do so at scale.

[kgraney]

That's the general idea. We're trying to limit the amount of abuse a single Google Account, device, or other first-party identity can cause. We have some more ideas and details we hope to share over time, but the goal is to keep writes to the API anonymous while preventing, the best we can, sybil attacks. We're willing to ignore/sacrifice some writes to achieve this (since any writes above ~k recent ones don't contribute directly to the utility of the system).

Beyond Private State Tokens we also have new cryptography we're researching that should let us improve unlinkability between issuance and redemption further.

https://github.com/WICG/turtledove/blob/main/FLEDGE_k_anonym...

https://eprint.iacr.org/2023/320

[salawat]

I'm calling bullshit on the unlinkability asserted in the Github reading here. Sure, you can make it so the API in question can't relink, but that doesn't mean you can't use extraneous unmentioned metadata to do it. Without proof that no other systems are siphoning off or tracking individual token state, this just looks like more "Lets use dubious cryptography to get pressure off our backs til a credible researcher we haven't hired/paid to be quiet blows the whistle".

The having to be logged in to Chrome bit is exactly what has me thinking something about that arrangement allows them to deanonymize, otherwise, they wouldn't even be able to measure the difference between real and fake. They'd also be more than happy to make an explicit business related contractual obligation of not sharing logs with them, because they don't need them, 1 and 2, to the uninitiated, it looks like they are trying to make an active attempt to anonymize things in spite of the fact they have enough extra OOB telemetry that they can continue with business as usual.

K-anonymity isn't anonymity at all, and is at best, less identifiable internal to the dataset.