etip
etip copied to clipboard
Xiaomi phone-home / tracking
found
com.xiaomi.push.service
(see also https://xiaomi.eu/community/threads/calls-home-to-the-maintainers.43699/ )
with the following domains/IPs:
app.chat.xiaomi.net
42.62.94.2:443
114.54.23.2
111.13.142.2
111.206.200.2
Is it common that those frameworks all hard-code IPs? I'd think this is rather suspicious, and bad news for people who use hosts block files and pihole.
Added to ETIP
TODO: check https://xiaomi.eu/community/threads/calls-home-to-the-maintainers.43699/ for domains
Added some comment in ETIP
@pnu-s Tracker approved
@blaueente The main issue I have with this library is that it does not seem like a tracker to me.
It does not fit with our definition of a tracker which is here: https://reports.exodus-privacy.eu.org/en/info/trackers/ So I don't know whether we can accept it as is.
Even if it is "simply" a push functionality, it leaks lots of information to the backend, as it is quasi-permanently connected, and as it usually submits identity information, allowing the backend to, e.g. correlate IP address to user identity. Add to this various statistics, when the phone is unlocked, etc. It also is embedded on a large amount of apps, allowing cross-app correlation. Thus, it fulfills all criteria of a potential tracker that can be seen on the phone itself. If it is actually used as a tracker can only be decided by the backend, and cannot be observed outside. It all comes down how much one trusts the backend not to do tracking. Which, frankly, in case of xiaomi I don't for multiple reasons: them making profit from user's data in other cases, china not having meaningful privacy laws in the first place etc. It fits my intuitive notion of a "tracker", and one could argue the "tracker" definition should be extended then. Or, maybe have a separate category, such that the user can decide?