> 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.
Genuinely, I really want to see Purism succeed and increasing numbers of competitors in that space, because we need tools that don't require so much blind trust. Whether caused by inept software devs, scope for malicious code / backdoors in firmware, analytics spyware, and whether this stuff is well intentioned or not, if it can be abused, it will be.
Open source and verifiable down to the firmware is the only chance we have at any real level of trust, otherwise as is always apparent in these conversations, it often falls otherwise to who you think could compromise your device and making your bed with it, like USA not China or vice versa
The problem is that purism doesn't pay as much as all the tracking, preinstalled bloatware, random 3rd party utilities and other stuff. This will never ever be solved through competition,because people either don't care, or there aren't enough of those who do. Legislation is the only way to make it work, but then again, that's hardly an option for most of the world.
While I agree with your intent, the problem is that, many open source software is not verifiable.
Remember that a Kaggle competitor was openly cheating with his published code? (cf. https://www.theregister.com/2020/01/21/ai_kaggle_contest_che... ) Eventually he got caught, but it's sometimes extremely difficult to spot a well-hidden malicious code in a plain sight. We need to be much better at analyzing software.
While having the source available is not a panacea, it would seem that, at least in the case you mentioned, not having the source code would have allowed for the cheating to continue with impunity, as there would have been no way for anyone to begin to discover what had been going on. That would suggest that having the source available is a necessary part of establishing real trust, even if it's not sufficient.
> While I agree with your intent, the problem is that, many open source software is not verifiable.
To me, this sentence reads as "That a nice idea, but untenable in practice." rather than "Open source is necessary, but shouldn't be considered sufficient." which strikes me as counter-productive to the objective of easily verifiable software.
Yeah, you are definitely correct on the lack of verification tools and I hope research on that one day breaks out of academia and into more common usage. The Kaggle story is great. One mildly related thing is Purism's bootloader tampering detection with their "librem key". Naturally it does nothing to verify the running code, but it does feel like knowing you're running the code you thought you were has some merit.
I think maybe some replies have interpreted my comment as naively assuming that open source firmware would would mean complete trust. I just think it is a good step on the journey.
Purism is never going to end up with fully open source baseband firmware. It's not going to happen because the radios are subject to several regulations which means customers can't be able to modify that firmware. There's going to always be a trust hole.
People should push for open source as much as possible. At some point it will be easier to lobby for the new regulations when everything else is fully open source. See also: https://forum.pine64.org/showthread.php?tid=11815
The regulations around radios exist because the spectrum is limited and emissions propagate over a wide area. You and I (assuming you're in the US) have the same standing to use radio spectrum. If I go and modify my phone's firmware to increase the power output I could literally jam communications from your phone.
It's very different than if I modified the firmware on my hard drive or UEFI on a PC. I might fuck up my stuff but it doesn't affect you. I can fiddle with my hard drive firmware all day but I'm not going to block a 911 call you're trying to make.
Also a company giving out modem firmware is an exception and not a rule. It re-classes the device as a hobbyist/experimental device and if they go traipsing around with it they could potentially face fines (unlikely but possible).
Again it's not about lobbying it's about a limited spectrum and people being stupid/assholes not realizing or caring their pocket radio affects others. You live in a world where shitheads try to make their cars louder on purpose and you can pick up dozens of WAPs because everyone sets the power to the highest number the interface allows.
Using wrong spectrum and jamming communications of others can be illegal without forcing proprietary firmware. It's like making all cars illegal, because someone blocks access roads for a fire brigade.
It's not forcing proprietary firmware. The firmware could be entirely open so long as end users couldn't freely modify it on their devices. Competition between baseband manufacturers drives them to keep firmwares proprietary.
Every radio regulation agency on the planet? Most radio hardware is capable of operating outside of regulated limits. The device firmware is usually what keeps the devices running within their regulated limits and gets those components licenses to be sold. Anyone selling regulated devices running outside of their regulated envelope faces fines and even criminal charges.
Cell phones only work because the millions of devices run within strict limits and behave reasonably. There's not a lot of difference between a properly operating radio and a radio jammer. Purism isn't going to find a baseband vendor that's going to risk their licenses by allowing for open source firmware.
In the US a baseband processor's entire software stack that controls the radio front end must be certified. They'll also have the modems to talk to the cellular networks. BPs use their own CPU(s) and an RTOS firmware that's FCC certified.
This is why a baseband processor is a fully separate component from a device's application processor(s). Since the AP doesn't talk directly to the radio it doesn't need to be certified and can be updated without recertification. The BP can also get certification and any manufacturer using that BP doesn't need to re-certify it. The interfaces are also such that the AP can't (or shouldn't be able to) tell the BP firmware to boost the output power above legal limits or something.
Radios that have "open" soft modems don't typically have fully software controlled radio front ends. The radio front end will have its statutory limits baked in electrically or have very limited software control. The modulation on the back end isn't as important as the front end. Broken modulation just means you can't talk to anyone, an overdriven transmitter is effectively a radio jammer or can give someone an RF burn.
Part 2 covers recertification of changes to radio equipment (everything touching the front end of the radio). Part 24 cover broadband PCS while Part 15 covers WiFi and Bluetooth since they're ISM band components.
If you're actually interested read the regulations and look up some FCC IDs for devices.
We'll never have real trust until we get the ability to fabricate our own processors in our own home just like we already have the ability to write our own software.
This doesn't help completely unless you fabricated the fabricator on trusted parts as well. Unless you trust it there is nothing to prove that the fabricator isn't inserting back doors into whatever it prints.
Well, I would love to print out my own cpu in the garage, but until then, I would also be happy, if the factories producing security critical HW, get frequent audits by qualified personel. Certifying and reviewing the build process.
as much as I am eager to see open source mobile OS succeed, tracking happens at the app level.
What happens when I install the FB app on a Purism enabled device?
My way to go until now has been installing as many OSS apps on my smartphone as possible, to the point that even the keyboard and the launcher on my smartphone are installed through f-droid.
That's the main reason why I prefer Android phones over Apple ones.
I don't think Facebook is likely to release a Linux based app. If they did it would likely be electron style. There also lots of Facebook apps that wrap the mobile website inside of a stand-alone "app" available on F-Droid. I also wonder what type of permissions API even exist that would allow you to view contacts as an app inside of Purism. Maybe Gnome has something kind of API already for apps to access built-in contents but this far there hasnt been a lot of proprietary software released for Linux that embeds spyware because of the low # of users and increased difficulty and general lack of distribution platform. But Purism is also really far away from being a viable platform for non-techies at this point.
|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.|
If the very first people (presumably the "higher ups"/more prestigious designers) in the design process miss such things, it is very hard to call them out in a societal construct that is the business construct that has become Xiaomi and the Chinese Government.
It's hard enough in some companies for QA to question software engineers and not catch backlash in the US when making games. Companies like EA, Atari and Nintendo are notorious for it. Apple used to shitcan QA who didn't treat "the talent" nice enough, and they weren't a quasi governmental entity.
You're right, of course. But man, that's a big frog in your throat to go up to your manager and say, "Sir, I'm sorry but this whole process has issues. Here's the fix, but it means a redesign of a core process." That's tough. That's double tough.
This is something that a company with a mature security posture needs though. Yes it's hard, but that's the point.
There are many ways to work around this, having teams whos incentives are tied to finding issues, maybe in a different reporting chain or office or country to those writing the software is one way.
I think incentivizing and anonymizing issue finding by restructure sound like amazing ideas, to be honest. Having batch issues come in to the devs via bug tracking software and conversations be labeled with a user ID rather than name would make a world of difference; so would basic professionalism. An understanding that it isn't team against team. Sdets (and manual testers) are not adversaries to devs or management... Though, I think a lot of devs realize this but project management/producers have a harder time understanding this. This is where I think a basic understanding of coding and the development pipeline would help a lot.
If your design is "accidentally" indistinguishable from intentional state-sponsored surveillance, does it really matter whether you arrived at it through malice or incompetence?
>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.
ASFAIK, Xiaomi does not sell any critical infrastructure equipment, nor is it installed anywhere; not entirely sure why GCHQ or NCSC would be involved, especially when there is ambiguity around which/what equipment they should be conducting a code review upon?
With regard to Huawei, there was no decisive conclusion, despite a comprehensive security review. Furthermore, it has been business as usual for currently installed equipment. All future decisions will be based around the 5G infrastructure.
Presumably phones used by government employees in relation to sensitive data are security critical? I'm not aware if their phones are being used in the wild in such a way but it's not hard to imagine such use cases.
Here in Europe, Huawei and Xiaomi are two of the most popular phone brands I see in shops. Even if the government isn't actually buying them to issue as "work phones" for employees, those employees are certainly buying them for personal use, carrying them to sensitive places, and leaking their own life details.
You'd have to be a complete idiot to believe that the CCP isn't happily digging through all the data they send back.
Right, I meant is it allowed by Chinese law to NOT spy for the government. As I understand it, to be allowed to operate in China as a Chinese company, you are under the obligation to provide any information you collect to the gov't upon request. Is that not the case?
You guys are familiar with the Snowden disclosures and how all telecom companies and very likely all major tech companies are spying for the US government right?
At this point, this is table stakes for big tech and it's completely anti-democratic. China may have a very good domestic dragnet but clearly it's playing catch up compared to the foreign intelligence assets the USG (and five eyes) has.
If you're going to cite Snowden, please be accurate.
Remember that one of the leaks was that the NSA tapped unencrypted Google backhaul in transit without Google's knowledge.
There's a difference between panopticon fearmongering and citing specific information we should be wary of. The former leads to apathy. The latter leads to action.
That was ATT. It (and all the other exposed operations) hardly support the statement that "all telecom companies and very likely all major tech companies are spying for the US government".
The US defense and intelligence apparatuses have been deeply intertwined with private enterprise for many decades. This is a matter of historical fact. But I totally understand if it's more comfortable for you to believe that now things are different despite the fact that no one was ever held to account for what happened in the past.
Right, that's why I said "very likely" instead of "proven". However, at the point it's pretty clear the tech companies are all competing for pentagon contracts (e.g. Project Maven, JEDI, etc) so the 2013 information has significant potential to be dated.
Thinking America's largest monopolies and America's government and foreign policy are at odds over more than superficial things is probably not an accurate view of the world. America uses our corporations to advance nebulously defined "national security interests" and corporations use the government to get rich(er).
Google publishes a transparency report with aggregate information on government requests for user data, and regularly challenges requests to reduce their scope. To pretend that this is the same as China is a joke.
Splitting hairs here, but the wording of your question gives the impression that one could choose not to collect any data and then be free of said obligations, but I don't think that's the case. Does anyone know?
There is a difference between being required to collect data that they wouldn't otherwise need for a legitimate business purpose, and being required to provide access to data they've already collected to their government. I'm no expert but it seems like a Chinese company could design products that don't collect a bunch of extraneous information, without violating Chinese law.
if you mean this in the sense that "all chinese companies are automatically spy agencies", then no, that's certainly not true. But would they have to comply with a government request - yeah, probably, just like any other company.
That feels like a distinction without a difference. The gov't has access to all the the data of all Chinese companies, and those companies are not required to divulge that to their consumers.
Another possible explanation is this isn't a bug, but intended behavior. If the browser hasn't been used for 90 days, this might be a good indication that the phone has changed hands, and you need to generate a new ID.
I know Xiaomi is not the best brand to buy for privacy, but I consider their products one of the best in terms of value for money
I own a few Xiaomi devices, I simply install Blokada on each one of them and I think you would be surprised by how many non Chinese domains it blocks, Google being one of the worst offenders.
EDIT 2: paradoxically knowing that Xiaomi is a Chinese company make buyers more aware of the privacy risks involved. It breaks that false sense of security associated with electronic devices that many people believe in.
About your second edit: If you live anywhere on earth that isn't in the geographical area of China it would likely be better to have data going to China than the big US corps. For most it is unlikely the data could be used against you in anything from ads to a police raid, unlike with something like Google collecting it where it will almost for sure be used and useful.
I hear this a lot, but it strikes me as being short sighted. That only works if the status quo remains so forever. Maybe 5 or 10 years from now, relations between the Chinese and US governments gets cozier, and part of their deal includes sharing of this kind of data.
Or maybe the US government knows it can't legally collect certain information on its own citizens, but can rely on China to collect it, and then purchase it from the Chinese government.
Then there's the overall argument against: I don't want any government collecting data about me, period. It's none of their damn business, regardless of the chances of me having to interact with them in any capacity.
The pessimist in me assumes that's because it's a good cover for the intelligence agencies data sharing agreements between the US, China, India, Russian, North Korea, et al.
There are a lot of binaries other than Android that run on Smartphones that you cannot possibly control from within Android even with fully-privileged apps (let alone restricted user-space apps). And, even within Android, because Blokada doesn't support "Block connection without VPN", there's no guarantee that apps don't bypass the VPN it sets up. Besides, Blokada leaks DNS requests over TCP (only handles the UDP ones) [0]. All of this is discounting the fact that Blokada has a hard-coded list of applications it blanket allows by-default [1].
Also, these fingerprinting bits in their code-base doesn't inspire confidence either [2][3].
I'd not consider Blokada a serious security app at this point, though it does have the potential to be one.
> 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.
Seems more likely this was done on purpose so if they got caught they could say "Junior engineer made a mistake. So sorry."
My corollary to Hanlon's Razor is "When you and/or your associates have been caught being malicious multiple times, Hanlon's Razor no longer applies to you."
That can be explained as a bug, but tracking what you typed into youtube search boxes doesn't seem like a bug and has no justification in terms of performance optimization.
> 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.