This paragraph stood out to me:
> The intention here seems to be that aigt is the timestamp when the ID was generated. So if that timestamp deviates from current time by more than 7776000000 milliseconds (90 days) a new ID is going to be generated. However, this implementation is buggy, it will update aigt on every call rather than only when a new ID is generated. So the only scenario where a new ID will be generated is: this method wasn’t called for 90 days, meaning that the browser wasn’t started for 90 days. And that’s rather unlikely, so one has to consider this ID permanent.
If we assume that Xiaomi aren't literally trying to spy for a government and are in fact just poorly calibrated on what's legitimate to collect for product analytics purposes, this paragraph highlights why that's still incredibly dangerous despite "good intentions".
I remember the UK government investigation into Huawei concluding that not only was their security posture insufficient for critical infrastructure, but their engineering practices were likely a decade away from being at a point where they could start to claim good security practice.
This paragraph seems to suggest a similar problem at Xiaomi. This should have been caught at a security review stage during design, it should have been caught at the code review stage, it should have been caught by automated tests, it should have been caught by QA, it should have been caught once live by data tests, it should have been seen once live by analysts, it should have been fixed at so many different points. The fact it wasn't suggests that these stages either don't exist or are insufficient.