As the article mentions, this is for assisted GPS. I've worked quite a bit with this system on android and implemented (or rather fixed) it for a custom android device. I've also worked with separate Qualcomm modems in the past. They are basically a whole small Linux computer in a package. You supply voltage, antennas, and connect via serial or USB, and then you can send AT commands to control it.
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".
> 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.
This seems like a really shallow dive into what’s going on, and seems to exist largely to plug their own hardware?
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?
Yeah, it manages to subvert its own message by transparently trying to be as scary as possible by being vague and jumping to its own conclusions, in what is clearly a sales pitch. It would be enough to say "hey, did you know that most phones send tracking data to the manufacturer when you download AGPS information? Our phone doesn't do that", instead of saying "oh, this phone makes a connection to a Qualcomm, server even on an open-source ROM, but we couldn't find which bit was making that connection so it must be the firmware. Also we won't actually show what data the phone was sending despite it being unencrypted. buy our phone instead!". I don't know what they did to investigate what was going on in the ROM they used but it clearly wasn't very much as it's something the ROM authors are clearly aware of: https://community.e.foundation/t/connections-to-izatcloud-ne... (this is the first result on google for "e/OS" "izatcloud"). It's annoying because it's pretty unnecessary to add the unsubstantiated claims to actually deliver their core marketing message, they just felt the need to put down the use of open-source ROMs on other hardware.
100% this. I was assuming we'd see some Wireshark showing this "personal" data being transferred and some proof that it was the Qualcomm chip doing it. What we ended with was a "trust me bro" explanation and a sales pitch.
According to GrapheneOS: "HTTPS connections are made to fetch PSDS information to assist with satellite based location. These are static files and are downloaded automatically to improve location resolution speed and accuracy. No query or data is sent to these servers".
> how is the chipset getting “List of the software on the device” unless the chipset is aware of the operating system?
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.
Yea, I'm pretty confused by this write up and a bit skeptical. I would really like to see better information about what they're seeing to conclude that the allegations are credible.
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.
> For example, how is the chipset getting “List of the software on the device” unless the chipset is aware of the operating system?
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.
Idle speculation, idle speculation that picks up just where the compliance handwaving stops: the legal team takes the better safe than sorry approach of listing everything they might perhaps infer from the particulars of aGPS refresh, and the blogger basically continues that line of thought: wow, that would be pretty wild.
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?
> 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.
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.
This is all assumptions. Just because izatcloud.net is owned by Qualcomm = they must be exfiltrating personal data? c'mon! Then you go and peddle your own NitroPhone as a "Qualcomm free" alternative? You're just gaslighting your customers to buy. This is a very short-sighted article based on lax assumptions and NO WIRESHARK to back it up. Just because a firmware makes a call home doesn't mean it's sending your personal data. Does it have access to all the hardware? It should, it's a MF'ing driver for a CPU. Name me another CPU that doesn't have access to the hardware via it's user-space blob? The consequences outlined in the article are true for EVERY mobile device, laptop, tablet, consumer electronics w/ wifi.
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.
A quite overblown article from a company pitching their own "secure phone".
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.
An odd article. They find traffic from one domain, don't disclose what the traffic is despite being unencrypted, then make speculation that it's extracting a list of things based on a privacy policy Qualcomm provided—when the authors could have just documented what they found to begin with to inform the reader based on evidence.
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.
I wonder why they didn't actually post the data that's being sent over. Especially because it says:
> 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?
This kind of restates what was discussed here yesterday. Android's constant leaking of data to Google is hardly any news, but Qualcomm's firmware doing the same in plain text to izatcloud.net is newsworthy. Apparently Apple is doing the same. Someone has a nice geolocation database of practically everyone in the world.
This seems like much bigger news than it's being received as. Sure, other chip makers do sketchy things, but is that really where we're at in 2023? We're so beaten down by proprietary user-disrespecting hardware/software that we just shrug it off?
<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.
>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.
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?
Sorry, but trying to be optimistic about RISC-V is only going to lead to more pain.
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.
> This seems like much bigger news than it's being received as.
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.
It seems like much smaller news than what they pretend it is. If you open up the suspicious domain in a web browser, it does explain what it is, who it belongs to. It’s a download location for a GPS almanac, used in assisted GPS. See http://izatcloud.net/
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.
This article just has little to no information in it, at least not enough to get all up in arms about. Supposedly this nefarious information is sent in the clear but no analysis was done to see what it actually happening? They're just guessing?
The whole article is "Qualcomm privacy policy says they can do xyz" and then extrapolating from there.
This angers me as well. At the same time, this sort of thing is so very common. It's hard, and unhealthy, to be in a perpetual state of outrage.
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.
The reason some of us have given up on these things may be due to reaching one conclusion or another regarding true motivations & capabilities involved. We all have a finite amount of time to struggle on this planet and picking battles is an important part of living.
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.
It is upsetting, but I am not sure how it can be countered. I am genuinely asking what is the alternative here. We go back to the lack of trust. You basically have to assume everything is trying to communicate with mothership. You mention RISC-V, but was it ever really tested against the same proposition?
I miss the dumb everything days, where the manufacturer simply could not spare compute power on additional features like telemetry.
You have a nice green field in your little town. There is this one guy that notices a gopher every so often and starts panicking and trying to get support to bring some professional to push them out.
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.
> 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.
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.
I think you guys are ALL missing the point. Imagine if you bought a brand new car but later found out it had a stolen engine? This is probably why Qualcomm is collecting data from its chipsets. Qualcomm gets a 5% royalty (5% of the cost of the entire handset) payment from each vendor.
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.
Outrage is not going to bring about a solution. Either “the gov’mint” has to step in and regulate or consumers have to vote with their wallets. Many of us own iPhones because we choose to trust Apple’s ecosystem over Google’s.
Did I miss something in the article? They see the connections were made, it was plain http, but they didn't actually show any of the real payload/data? Instead they quoted the list of what Qualcomms policy says could be collected? Seems like low hanging fruit...
Disclaimer: work at Qualcomm but have nothing to do with any of this
Interesting research. I have booted up Pixels using Qualcomm chips and have not seen the elusive izaticloud.
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.
This is old news. Smartphones have been using A-GPS for many years. The izatcloud.net domain was registered in 2012. The gpsonextra.net domain was registered in 2006.
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
It's really easy to block A-GPS when using Location. NetGuard can certainly do it. Not using A-GPS might mean GPS is slower to start up in some instances. But it's not very long IME.
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.
If the data is as they say sent via http then surely they can show a sample request with what data is _actually_ sent from the device instead of the list of what Qualcomm says might be sent (which was probably drafted by CYA lawyers instead of engineering)?
I think it would be meaningful to introspect that data since clearly it's not encrypted using https - this would be trivial with a MITM proxy on the gateway.
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.
The situation is likely far less scary. The article seems to intentionally overblow the accusations without going into any depth in order to push the advertisement for their phone.
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.
> In spite of its reputation for bolstering users' privacy, all Fairphone models contain a Qualcomm chip probably loaded with the AMSS blobware. The Fairphone has therefor the same issue with sharing of personal data with the Qualcomm XTRA Service.
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?
AFAICT from the article, the A-GPS download request may (they didn't show any payload analysis of an unencrypted payload...) include:
- 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.
Contrary to mediatek chips who openly send it to China or apple chips who also openly send it to Apple, and of course let's not forget the intel management engine ;)
[+] [-] captainmuon|2 years ago|reply
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".
[+] [-] krn|2 years ago|reply
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
[3] https://grapheneos.org/
[4] https://www.reddit.com/r/CalyxOS/comments/pym8l1/comment/hev...
[+] [-] wrs|2 years ago|reply
[+] [-] palata|2 years ago|reply
Thanks for the insights!
[+] [-] dagmx|2 years ago|reply
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?
[+] [-] rcxdude|2 years ago|reply
[+] [-] strictnein|2 years ago|reply
[+] [-] veeti|2 years ago|reply
https://grapheneos.org/faq#default-connections
[+] [-] solarkraft|2 years ago|reply
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.
[+] [-] kevin_nisbet|2 years ago|reply
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.
[+] [-] ajross|2 years ago|reply
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.
[+] [-] usrusr|2 years ago|reply
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?
[+] [-] mschuster91|2 years ago|reply
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.
[+] [-] gabereiser|2 years ago|reply
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.
[+] [-] rickdeckard|2 years ago|reply
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
[+] [-] nwcs|2 years ago|reply
[+] [-] Springtime|2 years ago|reply
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.
[+] [-] s1k3s|2 years ago|reply
> 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?
[+] [-] jruohonen|2 years ago|reply
[+] [-] freedomben|2 years ago|reply
<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>
[+] [-] callmeal|2 years ago|reply
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?
[+] [-] joezydeco|2 years ago|reply
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.
[+] [-] yakireev|2 years ago|reply
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.
[+] [-] phh|2 years ago|reply
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.
[+] [-] Xylakant|2 years ago|reply
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.
[+] [-] fckgw|2 years ago|reply
The whole article is "Qualcomm privacy policy says they can do xyz" and then extrapolating from there.
[+] [-] JohnFen|2 years ago|reply
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.
[+] [-] bob1029|2 years ago|reply
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."
[+] [-] JeremyNT|2 years ago|reply
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.
[+] [-] A4ET8a8uTh0|2 years ago|reply
I miss the dumb everything days, where the manufacturer simply could not spare compute power on additional features like telemetry.
[+] [-] anecdotal1|2 years ago|reply
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...
[+] [-] noncoml|2 years ago|reply
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.
[+] [-] Synaesthesia|2 years ago|reply
[+] [-] 27fingies|2 years ago|reply
I dont understand how this would change anything.
[+] [-] naikrovek|2 years ago|reply
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.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] SV_BubbleTime|2 years ago|reply
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.
[+] [-] williamDafoe|2 years ago|reply
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.
[+] [-] dstroot|2 years ago|reply
[+] [-] beembeem|2 years ago|reply
https://www.qualcomm.com/news/onq/2014/09/izat-location-tech...
https://investor.qualcomm.com/news-events/press-releases/det...
[+] [-] kayson|2 years ago|reply
Disclaimer: work at Qualcomm but have nothing to do with any of this
[+] [-] joemazerino|2 years ago|reply
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.
[+] [-] 1vuio0pswjnm7|2 years ago|reply
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.
It's really easy to block A-GPS when using Location. NetGuard can certainly do it. Not using A-GPS might mean GPS is slower to start up in some instances. But it's not very long IME.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/...
[+] [-] figgyc|2 years ago|reply
[+] [-] robhlt|2 years ago|reply
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.
https://grapheneos.org/faq#default-connections
[+] [-] tgtweak|2 years ago|reply
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.
[+] [-] StingyJelly|2 years ago|reply
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.
[+] [-] neilv|2 years ago|reply
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?
[+] [-] lallysingh|2 years ago|reply
- 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.
[+] [-] chaosbolt|2 years ago|reply