The clients currently work logged out (exempting rate limits) and it's not like you can upload a per user copy of the app to play store/app store, so that root of trust needs to start somewhere which is what the nitter team can extract.
Hmmm... I was thinking you could limit based on the unique identifierForVendor[1], but without a way to verify that a given id is legit this would be easily circumvented. An API whereby Apple cryptographically signs a vendor/device-specific ID so you can effectively rate limit without needing any personal info whatsoever would be nice.
A device specific ID would be a fingerprinting mechanism that would conflict with the privacy goals though? It would then have to be resettable, like the ad identifier already is.
They already have a device specific ID, this isn't asking for a new ID. See the link above. It's not considered a fingerprinting mechanism because it's only specific to a device/app-vendor pair, so can't be shared to fingerprint across apps.
The problem is you can't use it for rate limiting because a bad actor could just generate a random ID and use that. That's why an endpoint for validating a given ID was issued for a particular vendor is required for a privacy-preserving anonymous rate limiting implementation.
