On the one hand it wouldn't surprise me if the Qualcomm modem accesses the network on it's own - it very much wants to be a black box - on the other hand I doubt this story for two reasons:
- WiFi is implemented on the Android side. In all Android implementations I've seen, the WiFi module is part of the SoC or a separate chip, and Android runs the regular wpa_supplicant and so on. The chip cannot see the contents of packages, it only passes the bytes to the MAC (not sure if it is called that with WiFi).
(Now, of course in the case of a SoC the chip could, with driver support, peel back the encryption and inject it's own traffic, just like some IPMIs can share an ethernet connection with the OS. I just have not seen this yet.)
- In Android, it is usually the responsibility of the OS to fetch the AGPS data / almanach. You have a HAL consisting of a proprietary library (.so) that you get from the GPS vendor, some glue code, and a gps.conf. The gps.conf file lists the URLs to get the AGPS data. I'm not sure if the download is performed in the .so or in Java code, but anyway it is totally in the OS and not in the modem, at least in the cases I know. When a custom ROM, even a "degoogled" one, is made, you include a customized kernel and custom drivers, and the AGPS URLs are part of this "driver".
Thanks, this should be the top comment.
Both, Sony and Google, provide driver downloads for their smartphones[1][2].
In this case, the tested "de-Googled" OS (/e/OS) did exactly what it promised to do: removed all network connections made by Google – and not by Qualcomm or anybody else.
Since Pixel smartphones now use Google's own Tensor chips (which are based on Samsung Exynos), they obviously don't make any connections to Qualcomm servers.
This blog post is clearly an ad for NitroPhone, which is simply a Google Pixel smartphone with a different open-source OS pre-installed.
GrapheneOS[3] is only targeting Google Pixel line-up at the moment, and therefore is able to make sure that even A-GPS URLs are "de-Googled" on the latest models.
But the older Google Pixel models with Qualcomm chips make exactly the same connections – from the driver, not from the firmware[4]:
> GrapheneOS has modified all references to these servers to use HTTPS rather than a mix of HTTP and HTTPS. No query / data is sent to the server.
[1] https://developer.sony.com/develop/drivers/
[2] https://developers.google.com/android/drivers
[4] https://www.reddit.com/r/CalyxOS/comments/pym8l1/comment/hev...
Thanks - somehow I completely glossed over that possibility. This kind of biased rage bait has no place in privacy stories.
Thanks for the insights!
For example, how is the chipset getting “List of the software on the device” unless the chipset is aware of the operating system?
They don’t actually do any packet data analysis to see what it includes as far as I can tell, so other than seeing some packets go through, the rest feels like idle speculation.
Also, why didn’t they try GrapheneOS which is what their own devices use? Surely if the goal is to try and deduce that the chipset is involved, rather than a driver, then that’s the logical place to start?
A company that sells trust should know better than posting ads disguised as an approximate technical blog.
Someone credible: please write and submit such a blog post to HN so that we can have the discussion from that perspective instead. The current perspective is broken; discussion-wise.
The chipset is aware of the operating system, or rather the other way around. Manufacturers use kernel modifications and user space libraries provided by Qualcomm for their chipsets.
Qualcomm drivers are blobs, and they’re basically the main game in town for android, so the drivers would be shared by even their own device.
They stopped short of investigating what was causing the pull of the A-GPS data. It could have been something in the distro they used, that the other distro didn’t.
It’s such a hand waivy piece overall
I worked with aGPS a bit when I started my career. As I recall at that time, the chipsets only accessed the aGPS service if something asked the chipset for the current GPS coordinates of the device. The chipset could avoid the long load times of the locations by using the network to assist the GPS and get the current state. And because this is part of the cellular network standards, this would just be another thing the chipset did when working with the network, like receiving an SMS, or registering with the network so it can be notified of an incoming call or packet of data.
I wasn't aware that aGPS could also be done over WIFI, but I suppose it makes sense that it can. That might involve the OS as well, as other comments have pointed out to get to the WIFI network.
So I'm not ready to jump on that Qualcomm chipset is the culprit, or this is nefarious, unless we're sure there is no software process asking the chipset for the GPS coordinates / triggering an aGPS call, and that the identifying information alleged is actually in those messages and this isn't just some generic policy statement. And that this actually always goes over wifi, and when connected to a cellular network, it doesn't use the network operators aGPS. The network operator already knows all the alleged details based on the global standards of how a cellular device communicates with the network.
This surely isn't "the chip" doing this. It's the driver suite provided by Qualcomm, which is (obviously) required for a functioning device. The open Android distros still need drivers, and are essentially copying these files verbatim without review.
Somewhere Qualcomm has a privileged daemon able to get this info.
The "no packet analysis" is an interesting angle, because it would take all the fun out of complaining about plain http: would we prefer open messages with a known low amount of things to hide, or hidden messages with an unknown amount of secrets?
That's enough under GDPR, which is the point of the article. Even though the GDPR requires active informed consent, there are still so many layers openly sharting on that requirement, and no one holds the big players accountable.
Wireshark logs or you're just doomsday speculating. Show me the call to izatcloud.net with more than just http header identities every AdTech/MarTech company is already capturing from your web traffic and deanonymizing you.
What else do you need ?
Evidence/details of the very specific claims that go beyond that.
Class action lawsuit time.
jokes aside, I also don’t understand the criticism. The author even took the effort to write Qualcomm, and they admitted to this!
This is the same. Quadcomm have the capability, and the claimed legal right. It essentially doesn't matter whether they do, or do not, actually execute on it today.
I would, yes. There's some reason that they claimed the legal right to do so. That they aren't actually doing it at the moment I check means nothing, because they could start doing it at any time in the future.
Sorry, but you're the one who is missing the point. The very act of making a network request gives away your geolocation + time of use https://kieranhealy.org/blog/archives/2013/06/09/using-metad...
You could use an on-device firewall app, too; but OEMs / ODMs can always bypass it as they pretty much control not only the software but the hardware, as well.
They installed a custom OS which apparently includes Qualcomm's indoor positioning service iZat, but is missing the EULA item to allow the user to enable/disable the service.
iZat exists for at least 6 years, and the vendors who implemented it usually have a separate checkbox in their startup wizard to allow it to work.
Example screenshot after a quick google search: https://lgk20.com/wp-content/uploads/2021/09/57-60.jpg
> Affected users could try blocking the Qualcomm XTRA Service using a DNS-over-TLS cloud-based block service, or re-route this traffic yourself to the proxy server from GrapheneOS […]
if these requests were being made below the OS, akin to IME, you wouldn’t be able to substitute the DNS like that.
unless they mean that you could reroute things upstream of the phone — but most users don’t deploy their own fleet of LTE towers, so i doubt that’s what they meant.
I know you didn't personally design it so I'm not asking you these questions, more just thinking through this (although anybody knows the answers I'd appreciate hearing them so I can be more informed).
Why does this need to be built in at such a low level that not even flashing a new OS can see it/stop it? Why can't it be something users can opt in to, or at a minimum opt out of? Whether sinister or not, it's a "call home" mechanism built into to the lowest levels of the hardware, an area where users are powerless, even though they "own" the device.
It's done by the ROM, at the OS level, not the chipset. Some custom ROMs will proxy this request to mask your IP.
Nobody has shown evidence of that. The article certainly didn't
You can remove the services that download the extra GPS data, nothing stops you from doing that, aside making GPS unusable :)
Then they conspicuously plug their phone, which doesn't have a Qualcomm chip, and linking to its store. I'd like to see more presented before being accepting of such a story.
> Investigating this further we can see that the packages are sent via the HTTP protocol and are not encrypted using HTTPS, SSL or TLS.
So why not just post the actual data, instead of:
> To clarify, here a list of the data Qualcomm !!may collect!! from your phone according to their privacy policy:
Also, how does Qualcomm's privacy policy affect me as a user directly? I didn't agree to that. Or do I "accept" it because it gets passed over by manufacturers?
I need a source for this, because my personal security model rests on the idea that Apple is NOT doing something like this.
Number 1 in marketing according to ChatGPT.
Just curious, where did you find this?
<rant because I hoped for more outrage on this and am not seeing it>
This makes me mad. I'm so sick of this type of thing. It's a horrible time too because the embedded 5G chips are about to be part of everything, sending telemetry back about where they are and what they're being used for. I think it's utterly ridiculous that if you aren't ok with this type of thing, then you have to go way out of the mainstream to find products, and often there's no viable option. "Ownership" now means nothing.
Imagine if you bought a car from somebody, and they secretly kept a spare key and periodically used your car to run their personal errand. Would you be ok with that so long as they always had it back before you needed it so you never knew they were doing it?
That's what is happening when you "buy" a device and the device maker uses it to run code that serves only themselves (without receiving permission), to the detriment of your privacy. I can only hope RISC-V combined with people willing to care can lead to a return to a time when people actually own stuff and ownership is something we respect.
</rant>
It's worse than that. It's like you bought a house from somebody and they secretly left cameras all over the living room, bedroom, bathroom, and kitchen so they can get 'telemetry' ostensibly to improve the next house they build, for 'safety' in case there's an accident, and to 'protect the children'.
I think people are so overwhelmed and anxious that there's no space for fighting back against this kind of over-reach. And even if you did have the time and space and energy, how would you even go about it?
https://www.reuters.com/technology/tesla-workers-shared-sens...
So they can also exfiltrate audio and video
It's just an instruction set architecture and it's still going to be made in large SoC fabs by Qualcomm-class companies that want to save a buck on ARM licensing. There's no way to win here.
Perhaps though, with RISC-V options there could be a real solid open source option (aka a Linux phone). It wouldn't have to be nearly as mature and polished as the duopoly, but at least something that allows people to participate in modern society (much like desktop linux is now).
This is happening already. Teslas can be controlled remotely, and it does not have to be the owner of said Tesla.
Yes, somehow people are okay with that. The world we live in gets scarier and scarier every year.
One could accurately summarize progress since the Industrial Revolution as asking whether we could (and how), and not whether we should (and why). You can see this expressed in the growing focus on STEM education vs. the liberal arts and results in things like remote-controlled Teslas.
Cave Johnson said, "science isn't about why; it's about why not". The traditional counterbalance of that "why not" -- classical education, religion, etc. -- have all been falling behind.
1) AFAIK Teslas cannot be driven remotely. But even if they could Tesla is not using cars for errands, like wtf c’mon. And if they wanted to do that and paid me for it, I might be interested in helping the environment.
2) Tesla is able to remotely unlock a vehicle if they verify the owner. This replaces a call to a locksmith and/or the towing company and is way more convenient. So yes, people are okay with being able to have their car remotely unlocked by a third party who they authorize, we always have been.
Good bye high speed chases.
This has been widely known for more than a decade (Sorry I can't provide with a source. I was expecting Google search-in-the-past feature to work, but it doesn't).
As to whether the privacy policy has been declared properly or not, it depends on the OEM: See for instance https://www.bsr.at/mediafiles/Handbuch/CipherLab/User_Guide_... which shows Qualcomm's IZat default integration (This documentation shows an Android 7, but that screen has existed since at least Android 4.4)
> Sure, other chip makers do sketchy things, but is that really where we're at in 2023?
Literally all chip makers literally do that exact thing (except maybe the Unique ID part), just because that's how you're supposed to do A-GPS. For A-GPS you need at some point an oracle that is capable to give you an approximate location. There are some privacy-compatible ways to do that, but I'm not aware of anyone who even looked at it. (Looks like GrapheneOS skims that feature altogether, that's a way that works)
> It's a horrible time too because the embedded 5G chips are about to be part of everything, sending telemetry back
Even though Qualcomm can make things worse, the vast majority of IoS already do just that, and don't require 5G.
Of course I overall agree with you on lost ownership of modern electronic devices (and as you point out, everything became electronic devices), I'm just saying that it's nothing new. I think you need to get back at least a decade to see the unstoppable start of it (though DRMs are much older than that)
> I can only hope the RISC-V combined with people willing to care can lead to a return to a time when people actually own stuff and ownership is something we respect.
What does the ISA change in that regards? I would guess that the currently most deployed RISC-V device are nVidia graphic cards. And you're probably very aware that you don't fully own nVidia graphic cards. I'm also aware of other RISC-V devices in the field that are even more locked down.
> This has been widely known for more than a decade (Sorry I can't provide with a source. I was expecting Google search-in-the-past feature to work, but it doesn't).
Yep. Nitrokey's post was disappointing but understandable from a marketing perspective.
The thing that needs more discussion is the closed source stuff Android OEMs / ODMs run at higher ARM privileges rendering all of Google's grand ceremony around Android security moot (other than on Pixels may be).
The shocking news is that modern smartphones connect to a huge list of locations for various purposes. A large laundry list of providers can collect your ip addresses. But there’s little way around that. Every phone with a GPS chip will download that almanac from somewhere. Qualcomm uses Qualcomm. Broadcom will likely use Broadcom.
The whole article is "Qualcomm privacy policy says they can do xyz" and then extrapolating from there.
And they have clever lawyers to write their privacy policies. We don’t, so we have to “round up” in a sense unless we want to be blamed for agreeing to things.
The Qualcomms of the world created this situation, we just have to deal with it.
This sort of thing is exactly why I won't be replacing my smartphone when it dies. The only way to avoid being abused by tech companies is to avoid using their products as much as possible. This is where I'm at.
I don't see any other solution in the near term. Tech has been weaponized against us.
Sent from my Librem 5.
For me, this is much broader than some specific technology device. This is about an epic struggle between the "consumer" class and some elite technocratic class.
To quote Ron White:
"And then they squared off with me in the parking lot, and I backed down from the fight, cause I don't know how many of them it would have taken to whip my ass, but I knew how many they were going to use. That's a handy little piece of information, right there."
It might be, but we haven't seen the packet captures yet. I'm not trusting this shallow analysis (from a source I don't have any particular reason to trust) without seeing more details or corroboration.
I miss the dumb everything days, where the manufacturer simply could not spare compute power on additional features like telemetry.
Good point, there's no reason a manufacturer couldn't build it in. My thought was more along the lines of lower barrier of entry that would enable more competition (Qualcomm is near monopoly and has pretty anti-competitive practices that make it super hard to compete with them), and hopefully there will be more transparent options out there. As a user of GPS I'd like the option of enabling something like this because the old days of taking forever to sync with the satellites did suck. But I want to be able to decide for myself, not have the decision forced upon me by the chip's firmware.
> I miss the dumb everything days, where the manufacturer simply could not spare compute power on additional features like telemetry.
Oh man, me too. The nostalgia for this burns like a fire in my soul.
Indeed. The only "smart" things that I'm willing to have anymore are those that I've built myself. Apparently, very nearly no commercial manufacturers can be trusted anymore.
GPS has a built-in error for the civilian use, and a higher-accuracy system for military use. The concerns when it was deployed included unwanted parties using GPS as a guidance system component for missile / drone attacks, etc.
This led to the early GPS enabled phones needing an enhancement to their positioning system. The early releases (think car navigation systems) would be tuned to un-do the GPS offsets, but as that was rarely a 100% solution, they would "smart match" to the nearest viable alternative. This is why in many older car systems, you are sometimes registered as being on the feeder road (or a parallel road) until the system can no longer resolve your travel with your map position.
For smart phones, the error was deemed to great to have decent customer satisfaction, so enhancements to GPS came into being. The phones would listen for nearby markers (typically wifi stations) and report them back to a data warehouse, effectively building a dynamic map of all the wifi points. Then one could anchor that map based on non-moving items (like cell phone towers) and obtain fine-grained positioning information by running relative strength matches to the nearest 3 or 5 wifi access points.
The system updates eventually for broadcasters that change ids, are powered off, are relocated, etc. It has error checking built-in to reduce confusion around one or two new / missing / relocated markers.
All of this was driven by customer demand, and the data collection necessary was mentioned in the past. As the maps are unlikely to ever be placed inside of phone devices, and would require intensive storage to duplicate into each phone, as well as intensive bandwidth to update each phone, odds are that the calls to the manufacturers (which are selling "enhanced GPS" positioning systems) will continue for a very long time.
The solution? Pressure the government to release accurate GPS positioning, so industry will see the running of an independent positioning system as redundant and not-cost effective. Then, when you get a position with GPS, you get an accurate position, and you need not send a signal to correlate nearby signals with your true position.
Does it suck? Yes. Is the current system subject to abuse? Yes. Is the current system abused? (I'm a skeptic of human nature, so) Yes, but its abuse patterns seem to be nearly identical to its use patterns, with the difference being that the companies providing this service can use it to help people find their way to the grocery or to help other people find their way to a specific customer.
Qualcom and others have a very vested interest in not abusing the system, as they would lose their competitive edge should the government decide to take action against them. That said, many people worry about the government being the party abusing the system.
I wouldn't say this is equivalent to them "running a personal errand". If they were remotely enlisting your device in some computational task, sure.
But modern cars do grant the car company the "keys" to your car:
- Tesla's system - GMC OnStar (since 1996!) - Ford SyncConnect (since 2017) - HondaLink - BMW Assist - VW Car-Net
Even if you don't subscribe to the service they can still remotely access your vehicle...
Most people don’t walk in the field and have never seen or been bothered about the gopher or his little hole.
So everybody brushes this guy off as paranoid and his fears as exaggerated.
Then one day in your small walk you stumble upon the hole and start panicking yourself and trying to raise the problem.
You are wondering why isn’t everyone outraged by the gophers. Even that guy that used to warn everyone daily about the seems to not care anymore.
Well, it’s not that he doesn’t care. He is tired and defeated.
I dont understand how this would change anything.
You putting quotes around words such as "buy" and "ownership" push people away from your view, and any view like it, unless they have already adopted it that view or a similar one.
if you want this to change, stop ranting, stop scare-quoting normal English words because you disagree with the way they are used, and approach the problem logically. asking rhetorical questions and being angry is not how you get people thinking about this.
state your case, (we know it, but state it anyway) without emotion of any kind, and without unanswered questions. start by verifying what this article is claiming using your own device. the entire article could be BS designed to enrage people and to see how far it spreads before it is fact-checked.
it is very difficult to listen to someone who is ranting and who is speaking from a point of emotion unless you are emotionally invested yourself. it is much easier to ask someone to think about facts than it is to ask them to feel about emotions if you want them to think about what you are trying to say.
this turned out to be the case.
Well, it's an ad for another phone. That doesn't take away from the truth, but it's marketing even if it's true.
Qualcomm needs to know if a vendor is lying about the number of chipsets it has used. They need to know if the vendor claims 10M cheapo handsets and 1M expensive handsets - they need to know if the numbers are actually reversed!
This backdoor can get them the evidence they need to invalidate a license with a vendor - cut of chipsets shipments - and start a new negotiation. Remember, Chinese vendors will cheat like bananas. Chinese vendors asked for a HUGE discount on domestic phones - and they go it - but at the cost of a higher-than-normal royalty for exports. They are probably cheating, it's what they do.
https://www.reuters.com/article/us-qualcomm-m-a-broadcom-tim...
Chinese mobile phone Xiaomi R1 spies on it's users
(or any chinese manufacturer using snapdragon 630)
https://www.qualcomm.com/news/onq/2014/09/izat-location-tech...
https://investor.qualcomm.com/news-events/press-releases/det...
Disclaimer: work at Qualcomm but have nothing to do with any of this
Was it a connectivity self-test or empty GET request? That's not ideal, but fairly benign.
Or was it a "phone home" reporting the device's ID, SN, IMEI, etc? That's a lot worse.
Or, did it truly contain PII or geolocation data? that's really bad. It matters a LOT what's inside the request, and it seems a little dishonest to not include it in the report.
The one issue with using GrapheneOS's connectivity check is that you're broadcasting to the network that you're someone of interest. An Android phone connecting to Google isn't great for privacy but it is normal. An Android phone connecting to a GrapheneOS domain isn't.
Thanks that's an interesting thought.
I had similar thoughts, but going the other way around. I was wondering whether you gave more entropy be not using Google's generate_204, than by using it (= do more IPs do generate_204 calls). But after trying to compute some estimates, I ended up thinking that not sending generate_204 was still better than sending it.
But yes, as you point out, the entropy provided by pinging /another/ generate_204 is much much higher. At this point, it depends if you want to lower the information you send to Google, or your carrier.
PS: Just in case, Android's connectivity check pings a "generate_204" endpoints that as mentioned literally just responds with a 204
Here's a decent summary from 2013:
https://forum.xda-developers.com/posts/41576274/
One could just as easily download these A-GPS files ("GPS almanacs") oneself instead of letting Google Play Services or GrapheneOS or whatever do it. There's no need to send any data to any server. Just send a minimal HTTP request.
GET /xtra3grc.bin HTTP/1.1
Host: xtrapath2.izatcloud.net
Connection: close
In those instances, I use an app from F-Droid called GPSTest to let me know when GPS is ready.
It would be nice if we compiled our smartphone OS ourselves, then we could edit configuration files, like the one that enables A-GPS, and/or remove code we do not like. XDA seems to be the closest to that ideal.
https://android.googlesource.com/platform/hardware/qcom/gps/...
https://android.googlesource.com/platform/frameworks/base/+/...
The file even used to specifically refer to the XTRA service, but was updated to be vendor agnostic.
GrapheneOS also calls out these requests:
> HTTPS connections are made to fetch PSDS information to assist with satellite based location.
All of this to push your own platform without any data backing it up aside from an http connection and privacy policy. Pretty alarmist. Not that anyone is advocating for unauthorized connections to the manufacturer of your hardware, but the author should at minimum capture what is being sent (if anything) and what is being received in return. From what I can see this is a preseed for GPS data that speeds up GPS acquisition time by sharing the latest constellation data so the phone doesn't have to sit there for 5-30 seconds listening for enough satellite beacons to determine the position. It should not require any input data to provide it's function - that request should be a simple GET to an endpoint that has no extra query params or headers.
If you want to be concerned about something, be concerned about the very likely fact there is nation-state level backdoors sitting in that very same firmware (or hardware itself) that isn't using observable channels to operate. The plethora of "chatter" on the cellular network just to receive phone calls is orders of magnitude more than this request, and much of it is handled in the radio firmware invisibly which also has root-level access to much of the system.
A good read on these matters:
https://www.direkt36.hu/en/putyin-hekkerei-is-latjak-a-magya...
Talking about /e/os /their competitor/ in the beginning to make them seem less-competent:
>Surprisingly, the deGoogled phone's first connection is to google.com.
>This makes us wonder. /e/OS did replace Google’s connectivity check, but did they somehow miss out to replace the Google Play Store URL?
/e/os has microG so I'd guess it's on by default and this is "google device registration" that is necessary for safetynet.
Then in the main part they talk about AGPS. Instead of showing the unencrypted traffic that supposedly contains the private information, they just quote qualcomms privacy policy. They make a big deal about the phone requesting agps data even when the location is turned off (unlike theirs amazing one that only requests the agps data when you turn the location on.) My phone also requests agps data only when I turn the location on and it sucks because If I don't have internet access, without fresh agps data the phone can take a really long time to get GPS fix (Especially in bad conditions like snowy forest where I wanted o check if I was still on the right trail but couldn't get fix at all.). It's an oversight on /e/os side not to proxy the agps requests but it can be done. Many service providers do it which seems worse and if you want, you can easily tell android to use a different server, just follow this reddit post: https://old.reddit.com/r/privacy/comments/cldrym/how_to_dego...
I'd love to see more competition in mobile cpu space but fearmongering about qualcomm being evil without any substance is not the right thing to do. What is far more worrying is that both qualcomm and exinos chipsets have terrible track record when it comes to vulnerabilities.
When calling out a specific brand like that, I was surprised by the "probably".
Why not first confirm it, such as by testing, or by getting a statement from the brand or Qualcomm?
- Unique ID - Chipset name - Chipset serial number - XTRA software version - Mobile country code - Mobile network code (allowing identification of country and wireless operator) - Type of operating system and version - Device make and model - Time since the last boot of the application processor and modem - List of the software on the device - IP address
The A-GPS system downloads current satellite orbits (Ephemeris) from Qualcomm instead of waiting for all relevant satellites to transmit all of them on their own. This reduces the time it takes to fix the position.
I would've preferred that they show the actual data transferred, instead of what the policy says they may transfer.
Which resolves to 161.189.173.187, a mainland China IP address,
with hostname
ec2-161-189-173-187.cn-northwest-1.compute.amazonaws.com.cn
But the only fool-proof solutions are mathematical/technological ones where privacy invasions aren't possible.
As far as catching child molesters, the cops should simply kick down their doors the old-fashioned way.
https://old.reddit.com/r/CalyxOS/comments/pym8l1/calyxos_con...
I wish to point out this alternative: Let's increase transparency instead.
Require all data sent and received to be in a common well-documented format (XML.)
Require the following be documented in the XML (1) The program sending it, (2) the program receiving it, (3) what it means, and (4) what it is used for.
There should be a single place to go to see all data coming and going so the administrative user of the device can review all data coming and going.
A lot less shenanigan's would happen online if every value sent and received had to be well documented with
Because that a new Windows install sends and receives so much complicated garbage that that networking people can not understand what is going on, this would require rewriting everything. I'm willing to do it.
Edit: I've long since sink-holed `izatcloud.net`, and have seen countless look up to this subdomain for the duration of ownership of a Pixel 4a (running GrapheneOs).
How long has this been going on for?
If the list of data in this article wasn't exposed by Qualcomm, then it's exposed in other ways like via SS7 in certain scenarios or to the OS and apps. Granted, app permissions are at least a user choice but we all know how that works these days. At least Qualcomm's using it to improve their product and not just harvesting for advertisers.
Also, like others have said, this is a shallow blogspam article trying to sell a "secure" phone. Ick.
That is the main problem to me. Manufacturers building spyware into their products is just the consequence resulting from those products being closed paired with being connected, and the manufacturers' ability to get away with it. Putting aside conspiracies, spying people still is a lucrative business, therefore I don't expect any manufacturer to resist that opportunity. It's up to people to educate themselves about the dangers when trusting a device that is closed and goes online.
Learn how to mitigate security cause you are not going to win the battle head on, simple truth that is hard to swallow.
1) laws that enshrine the right of owners/users to circumvent bullshit like this (a right to digital self defense) and that prevent corporations from making it unreasonably difficult to do so.
2) a healthy community of hackers building the kind of contraception we need to protect ourselves from bullshit like this. I don't know what that is when it comes to an SoC, but we need it.
We can't rely on the companies not to do these thing (in fact you can set your watch by it), so we should just focus on protecting the right to route around it.
If one particular vendor has 25% Black market Qualcomm chips inside for which Qualcomm never gets a royalty then I think they would definitely be getting a phone call from Qualcomm pretty soon...
>During operation, the covert operating system (AMSS) has complete control over the hardware, microphone and camera.
W-T-F
Microphone and camera control?! If this is true, it's a government spy's wet dream, and a privacy nightmare.
I'll never knowingly use one of their products again.
(that said, I'm not sure this particular service is used, especially if you use a custom firmware which provides an open source replacement to many of the original firmware components. GPS does not work very well until the userspace itself sends an xtra A-GPS file to the modem)
www.obeliskone.com
Intel runs Minix on their CPU's in their "management engine" to deal with boot security and other things which means it is able to override the host OS and even parts of the CPU itself and access the network, storage and memory independently.
Edit: found the policy
Firstly, the Nitrophone is just a Pixel 4A which contains a Qualcomm Snapdragon 765G CPU. I am confused at how the author claims it is free of Qualcomm control. They are unquestionably an active participant in mass surveillance efforts and there are much more covert ways of doing that when you control a CPU, like making your random number generator not actually that random, potentially compromising -all- TLS, or only activating firmware location tracking features when particular domains or traffic is observed. There are countless ways to hardware backdoor a device that are not as crude and obvious as the ones this article observed.
Secondly, the sole signing key for phone software is under the exclusive control of Daniel Micay who is an undeniably brilliant engineer, but I suggest looking into how they communicate online and comments by anyone who has ever worked with them before. Supply chain integrity for GrapheneOS stops and ends with one person, who has rejected all attempts by me and others to pursue reproducible builds etc for accountability.
Third, GrapheneOS still contains many proprietary blobs with full control over various portions of the hardware. The GrapheneOS team has no choice, because the supported hardware components have not been reverse engineered yet and cannot function without them. The only blob-free Android is Replicant OS but it only runs on reverse engineered but sadly ancient devices long out of production and ancient builds of Android missing many years of security patches. The state of open and private mobile computing is truly a shit show.
Fourth, even if you had a fully trusted hardware and software stack, a device that connects to cell towers, even a dumb phone, will be pinged by three or more towers at a time. All of them collude to log the location of every single phone connected. The only way out is living on Wifi only with airplane mode full time.
Fifth, even if you open source hardware and software you -still- have to worry about state sponsored supply chain attacks at the factories.
Bunnie had it right in his talk on this. https://hackaday.com/2019/12/29/36c3-open-source-is-insuffic...
The only way forward is to essentially go back in time to decisions we made back in the 90s and start over again, which is what the Precursor project seeks to do.
That is the only hope I have for a high trust messaging device in my pocket any time soon. There is an alpha matrix client, so fingers crossed.
Still, there is nothing stopping Exynos from doing the same, but I grant it is better they are running from qualcomm.
The request to android.clients.google.com though is required in order to checkin the device and receive a device ID and security token [2], which is needed for Firebase Cloud Messaging and push notifications [3]. The checkin include hardware details such as available features (GPS, WIFI, Microphone, EGL version) [4] but sensitive details such as HW MAC address, serial numbers and SIM operator ID are spoofed. [5, 6]
Basically if you're running deGoogled and still rely on Google Services, there _will_ be a few calls to Google owned servers. MicroG avoids sending sensitive HW and user data though, more can be read in this thread: https://github.com/microg/GmsCore/issues/1508
[1] https://doc.e.foundation/support-topics/micro-g [2] https://github.com/microg/GmsCore/blob/master/play-services-... [3] https://github.com/microg/GmsCore/blob/master/play-services-... [4] https://github.com/microg/GmsCore/blob/master/play-services-... [5] https://github.com/microg/GmsCore/blob/master/play-services-... [6] https://github.com/microg/GmsCore/blob/master/play-services-...
GDPR is almost certainly engaged here too, as the article states.
I'm angry enough about this to be out for blood now. This is absurd.
As to aGPS being necessary this depends on how often you use GPS. Without aGPS it takes a while for the device to lock after a total cold start but once it has locked it should be able to reacquire lock within a short timeframe. As long as you do not move more than 100 km from the position you were when you last switched off GPS, the clock is within 20 seconds and you're not breaking any speed limits you'll get a fix within a few minutes assuming the receiver can see some satellites. In other words, GPS works fine without aGPS.
If it's being done by the firmware on the Qualcomm SOC then a firewall in Android is not going to save you.
So yes, Android - or rather the Linux kernel on which Android is built - is going to "save me" in that I am in control over which application (including whatever Qualcomm uses) gets to send data. Apple users are out of luck since iOS does not allow this type of filtering but Android does.
It's a privileged app ( a service in Android lang ) that once fetched sends the data to the modem, where GPS is actively implemented, and augmented by such extra data.
Android, being built on top of Linux which contains Netfilter as I explained elsewhere [1] which allows you to block network access no matter whether the data originates from some hardware chip or somewhere else. The only way data could make its way off the device is if the radio firmware made a covert connection to Qualcomm which could be used to totally bypass the Linux kernel. That connection would not use the system IP stack and it could work even if the user does not have data active. It would need cooperation from network operators (all over the world) to get the data out of the carrier's network to Qualcomm. This is not what this article is about, it is quite possible that the likes of the NSA are up to this type of shenanigans since they may be able to force carriers to do their bidding [2] but Qualcomm is just another corporation looking to 'get to know their customers'. Read the article and you'll see that the data is exfiltrated through Android. A default block for outgoing data - like I use - blocks this just as well as it blocks other similar attempts.
[1] https://news.ycombinator.com/item?id=35707645
[2] https://www.pbs.org/wgbh/frontline/article/how-att-helped-th...
The kernel never even sees it.
Addendum: To the people downvoting, the article is clear:
> During operation, the covert operating system (AMSS) has complete control over the hardware, microphone and camera. The Linux kernel and deGoogled /e/OS end-user operating system function as a slave on top of the hidden AMSS operating system.
That's the only sane way to have a working device that needs to handle signals.
It's not hidden in any way, and the kernel/Android actively talks with it, configures it, turns it on/off.
> We also didn't place a SIM-card in the phone either so it could only send and receive data over the WIFI network which we are monitoring with Wireshark. Wireshark is a professional software tool which allows us to monitor and analyze all traffic being sent over the network.
If the claims of Qualcomm using its hidden AMSS operating system for data exfiltration were true it would not matter whether the device has a SIM card installed or not. Even without a SIM card the thing is still able to reach cell towers, it still has an IMEI, it can still be used to call emergency services (112 or 911 etc), it just won't have an IMSI. Mobile operators are by law mandated to enable connectivity to emergency services to all devices so those connections are passed to their destination. Without an IMSI they do not know who to bill for connectivity so they do not pass any other traffic for such devices. Even with a SIM and thus an IMSI there is no guarantee the subscriber has paid for data so again the operator will only provide connectivity when there is some account to bill it to.
> After we provided our WiFi password in the setup wizard, the router assigned our /e/OS de-Googled phone a local IP address and it started generating traffic.
The data is exfiltrated through WiFi - which goes through the Linux kernel, using the Linux driver for the WiFi hardware. A default block for outgoing traffic puts an end to this just as surely as removing the battery does bar any covert manipulations of the device.
Realise that those who wrote this article are trying to sell you something, hence this rather poor article which tries to insinuate Qualcomm has somehow managed to get mobile operators to cooperate in a scheme to send private customer data through a covert channel. Realise also that they claim their 'Nitrokey' device does not contain a Qualcomm modem. That is quite possible... but it does contain a radio modem and the accompanying RT OS to control it - radio firmware delivered as a blob to be installed on that Nitrophone which is nothing more than a rebranded Google Pixel - using a Samsung Exynos 5300 modem - with GrapheneOS installed.
This is a sales pitch, nothing else.