4 ms·

This seems like Elon distributed free API tokens to specific 3rd party vendors?

Macha 3y ago
What reason could he possibly have to give them to Nitter, which has at its primary purpose undermining their conversion and engagement attempts? The old token was the twitter web token. I suspect the new one is one of the mobile clients. Maybe new tweetdeck. Though probably the iOS client token makes the most sense, being the hardest to rotate on a whim with app store review.
- I_am_tiberius 3y ago
  Ok thanks.
- tgv 3y ago
  They don't have indivual tokens? Well, let's not give them ideas.
  - Macha 3y ago
    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.
    - jakear 3y ago
      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. 1: https://developer.apple.com/documentation/uikit/uidevice/1620059-identifierforvendor https://developer.apple.com/documentation/uikit/uidevice/162...
      - Macha 3y ago
        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.
        jakear 3y ago
        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.
        immibis 3y ago
        Now you have Google dictating who can make Android phones that actually work. That has to be in violation of GPL somewhere.
        jakear 3y ago
        Uh what? Nobody is saying Google needs to be in control. Where did you even get that from?

What reason could he possibly have to give them to Nitter, which has at its primary purpose undermining their conversion and engagement attempts? The old token was the twitter web token. I suspect the new one is one of the mobile clients. Maybe new tweetdeck. Though probably the iOS client token makes the most sense, being the hardest to rotate on a whim with app store review.

I_am_tiberius 3y ago
Ok thanks.
tgv 3y ago
They don't have indivual tokens? Well, let's not give them ideas.
- Macha 3y ago
  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.
  - jakear 3y ago
    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. 1: https://developer.apple.com/documentation/uikit/uidevice/1620059-identifierforvendor https://developer.apple.com/documentation/uikit/uidevice/162...
    - Macha 3y ago
      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.
      - jakear 3y ago
        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.
        immibis 3y ago
        Now you have Google dictating who can make Android phones that actually work. That has to be in violation of GPL somewhere.
        jakear 3y ago
        Uh what? Nobody is saying Google needs to be in control. Where did you even get that from?