News for hackers. Stuff that matters.

A comment on “We would like to apologize to the user for the error on our part this morning”. Parent comment

Re:“We would like to apologize to the user for the error on ... by avocado4 on Wednesday November 27, 2019 @07:30PM (#21653644)
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.

[ Parent | on HN ]
Re:“We would like to apologize to the user for the error on ... by Avery3R on Wednesday November 27, 2019 @07:32PM (#21653655)
To do exactly what they say in the post. Associate alt accounts with a main account that has been banned.
[ Parent | on HN ]
Re:“We would like to apologize to the user for the error on ... by avocado4 on Wednesday November 27, 2019 @07:34PM (#21653669)
No, it's still not ok to track hardware IDs even (especially) for that reason: https://developer.android.com/training/articles/user-data-id...
[ Parent | on HN ]
Re:“We would like to apologize to the user for the error on ... by hombre_fatal on Wednesday November 27, 2019 @08:29PM (#21653918)
The most damning thing your link says is that it's not a best practice.
[ Parent | on HN ]
Re:“We would like to apologize to the user for the error on ... by yorwba on Thursday November 28, 2019 @06:24AM (#21656353)
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.

[ Parent | on HN ]
Re:“We would like to apologize to the user for the error on ... by Avery3R on Wednesday November 27, 2019 @07:40PM (#21653701)
How else would you do the tracking?
[ Parent | on HN ]
Re:“We would like to apologize to the user for the error on ... by tonyaiken on Wednesday November 27, 2019 @11:03PM (#21654490)
Most analytics function isn’t necessary to provide the app’s functionality, and yet it’s very common to have it.
[ Parent | on HN ]