3 ms·

Also if you root your Android phone, wireshark their app, trace the traffic, and check the Manifest you'll see they are sending user's personal identifiers (non

Also if you root your Android phone, wireshark their app, trace the traffic, and check the Manifest you'll see they are sending user's personal identifiers (non-resettable hardware IDs) to servers in China. There's absolutely no way why uploading this data (or reading it in the first place) would be in any way necessary to provide the app's functionality. And they dump/read files in shared storage spaces to cross-tracking with other Chinese apps. If you try to install it into Secure Folder on Samsung it gets disabled.

Avery3R 7y ago
To do exactly what they say in the post. Associate alt accounts with a main account that has been banned.
- avocado4 7y ago
  No, it's still not ok to track hardware IDs even (especially) for that reason: https://developer.android.com/training/articles/user-data-ids https://developer.android.com/training/articles/user-data-id...
  - Avery3R 7y ago
    How else would you do the tracking?
  - hombre_fatal 7y ago
    The most damning thing your link says is that it's not a best practice.
    - yorwba 7y ago
      The best fit is probably the "Anti-fraud: Enforcing free content limits and detecting Sybil attacks" use case, since that is about preventing a single user from creating multiple accounts. (Although the content limit for a banned account is to stop it from producing more content, not consuming it.) The official recommendation: Use: Instance ID or GUID. On Android 8.0 (API level 26) and higher, SSAID is also an option, as it's scoped to the app-signing key. Why this recommendation? Using a GUID or Instance ID forces the user to reinstall the app in order to circumvent the content limits, which is a sufficient burden to deter most people. If this isn't sufficient protection, Android provides a DRM API, which can be used to limit access to content, includes a per-APK identifier, the Widevine ID. So I guess best practice in this case means they should use DRM instead.
tonyaiken 7y ago
Most analytics function isn’t necessary to provide the app’s functionality, and yet it’s very common to have it.

Avery3R 7y ago

To do exactly what they say in the post. Associate alt accounts with a main account that has been banned.

avocado4 7y ago
No, it's still not ok to track hardware IDs even (especially) for that reason: https://developer.android.com/training/articles/user-data-ids https://developer.android.com/training/articles/user-data-id...
- Avery3R 7y ago
  How else would you do the tracking?
- hombre_fatal 7y ago
  The most damning thing your link says is that it's not a best practice.
  - yorwba 7y ago
    The best fit is probably the "Anti-fraud: Enforcing free content limits and detecting Sybil attacks" use case, since that is about preventing a single user from creating multiple accounts. (Although the content limit for a banned account is to stop it from producing more content, not consuming it.) The official recommendation: Use: Instance ID or GUID. On Android 8.0 (API level 26) and higher, SSAID is also an option, as it's scoped to the app-signing key. Why this recommendation? Using a GUID or Instance ID forces the user to reinstall the app in order to circumvent the content limits, which is a sufficient burden to deter most people. If this isn't sufficient protection, Android provides a DRM API, which can be used to limit access to content, includes a per-APK identifier, the Widevine ID. So I guess best practice in this case means they should use DRM instead.

tonyaiken 7y ago

Most analytics function isn’t necessary to provide the app’s functionality, and yet it’s very common to have it.