Smartphones with Qualcomm chip secretly send personal data to Qualcomm
nitrokey.com
nitrokey.com
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.
From the technical point of view, only Daniel Micay's GrapheneOS currently takes security really seriously by providing constant system updates. It seems that you either have to use GrapheneOS, or buy an iPhone, if you care about both – security and privacy.
The people who are attacking Daniel Micay often incorporate a lot of his work into their own projects. And, naturally, that might make many of them feel inferior or even incompetent – if they are doing this for years to stay in the competition.
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?
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.
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
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?
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.
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.
This is just A-GPS to work and has been like that for over a decade.
The Wikipedia page has about as much information as a blog post would https://en.wikipedia.org/wiki/Assisted_GNSS?wprov=sfti1
Or better yet, from the GrapheneOS devs themselves https://reddit.com/r/privacy/comments/12yii9u/_/jhojlr7/?con...
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.
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.
What else do you need ?
Class action lawsuit time.
Evidence/details of the very specific claims that go beyond that.
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...
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.
Example: https://lgk20.com/wp-content/uploads/2021/09/57-60.jpg
The question about data-collection is asked during initial setup (iirc depending on Android version it's either on the very first page of the startup wizard labeled "Important Information", or it's shown as a Notification after the Wizard is completed), but I admit Sony has a quite elaborate list of License Agreements and they make it quite "frictionless" to just confirm everything.
Anyway, I can't tell how Sony implemented it across all its models and years, but to stay on-topic, community-OS's are not really a benchmark for End-User License Agreements on privacy-data (which is what that company in this article was benchmarking against its commercial product)
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.
You can remove the services that download the extra GPS data, nothing stops you from doing that, aside making GPS unusable :)
Nobody has shown evidence of that. The article certainly didn't
It's done by the ROM, at the OS level, not the chipset. Some custom ROMs will proxy this request to mask your IP.
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?
Just curious, where did you find this?
No need to require a constant background download.
I may actually use gps once or twice a week only, disable geolocalisation when it is possible on all apps I am using.
There is no justifiable reason to say gps is not possible without this. Besides you should be able to decide you don't mind waiting 15 minutes to get full gps service.
Why would you expect any private data to be sent when requesting static file? That would slow down both the client and server.
The main SoC definitely isn’t, Apple design their own SoCs, are you talking about some other chip?
it’s almost certainly part of the distro since they claim you can block it. If it was the chipset, you wouldn’t be able to.
I need a source for this, because my personal security model rests on the idea that Apple is NOT doing something like this.
Why do you think that is a reasonable assumption?
Number 1 in marketing according to ChatGPT.
<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>
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.
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.
Could you clarify what you mean? Here Maps allows you to download maps into your device and use it to navigate offline (without internet connection in devices with built-in GPS). I've been using this for (I think) more than a decade now and it works great. They also release maps updates frequently to download and update your maps. I believe Google maps has also begin offering similar offline map features.
This was called "selective availability" and that practice stopped in 2000. There is no longer any intentional error being introduced.
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.
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).
There are already lots of options within the ARM instruction set. The problem is that Qualcomm makes the best modems and the best (non-Apple) processors and uses their wireless patents and chip lead to squash competition.
> Perhaps though, with RISC-V options there could be a real solid open source option (aka a Linux phone)
The issue isn't the ARM instruction set. We have Linux smartphones (beyond Android) that you can buy today. You can buy a PinePhone and run Ubuntu Touch, postmarketOS, Mobil, LuneOS, and more. You can buy a Librem or Volla Phone or Fairphone. If you want out of the duopoly of Apple and Google, there are devices you could have shipped to you today!
The problem isn't the ARM instruction set and getting RISC-V processors wouldn't make much of a difference for Linux (or FOSS in general) on smartphones. The ARM instruction set isn't what is keeping the tech giants in power.
Right, it’s the fact that (I’m assuming) simple stuff like checking my email is a nightmare on any phone that isn’t iPhone or Android. I know I could probably switch email clients, but is that worth it?
And all the other apps that either suck on the web or don’t even exist.
It’s such a chicken and egg problem that even Microsoft couldn’t crack it, despite making a perfectly good OS and hardware. By the time you are two years late to the party it’s already over.
I kind of want to modify that old adage to now read "cheap, open, documented. You can pick two."
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 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).
You're mentioning security, which is interesting, because here it's not a question of security (don't get me wrong, izat did have security flaws in the past, and I wouldn't bet that modern devices are all properly corrected), but only to who you are sending your private data to.
It's also fun that you mention Google doing security around Android... because the vast majority of people do send their private data to Google!
My personal take is that if we want to control who we send our data to, we need to start from the easy steps: I personally use a modified Android to send the least amount of data to Google. Disabling gps xtra is pretty easy. I think I already have it disabled, but I'll check.
I mention security because, by running blobs (sometimes entire OSes) in TrustZone EL3 / Hypervisor EL2 rings, OEMs / ODMs can pretty much do anything they want, including connecting to WiFi / LTE networks to phone home, analyse contents of the RAM, scan UFS / eMMC, track inputs / keys, and what-not; all without Android (Kernel EL1 + Userspace EL0) ever knowing anything about it.
> It's also fun that you mention Google doing security around Android... because the vast majority of people do send their private data to Google!
Agree. One good thing about Google tightening up Android APIs (and CCD certifications) in the name of security (and compatibility) is it only leaves Google with the keys to snoop on users. Careful "De-googling" of the ROM can take one a long way, indeed.
> My personal take is that if we want to control who we send our data to, we need to start from the easy steps: ...
And install the Rethink Firewall (network monitor) while you're at it, phh (:
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 for the Aperture ref.
Aperture Science
We do what we must
because we can.
For the good of all of us.this is yet another face of Moloch
Liberal arts is a natural ally and fellow traveller with science and technology. In fact much of early science grew out of liberal arts endeavours. Geometry from sculpture and perspective in art and architecture. Chemistry from developing pigments for painting.
Good bye high speed chases.
I see a huge difference between the ability to physically break into a car and having a datastream to a company that can be used to unlock the car. The latter is much more problematic -- especially if I can't choose who does or does not have that ability.
This is all a subset of the problem that modern cars are surveillance platforms.
There’s a difference between the government legislating obscure and weak backdoors into all microchips so the NSA can spy on you, and a car company providing features consumers want, agree to, and pay for, in a secure way. One is a surveillance platform, the other is a good product. It’s silly to equivocate the two. Thats what I’m responding to.
If it's not for their own use, whose use is it for? It's literally just for their use. They may promise that they won't use that backdoor for purposes that aren't for your benefit, but that's just their promise. And how do they define "for your benefit"?
How secure from other attackers that back door is is only one aspect. It's important (and important to remember the truism that "if there's a way to access it legally, there's a way to access it illegally"), but not the only issue. Even if we assume that hackers really can't get in that way, the backdoor and the data collection are still unacceptable to me.
It would help me understand your concern if you pointed to the data collection and use thereof that you consider unacceptable.
The way I see it, you’re essentially uncomfortable with Tesla being able to update the software on your system (which is also opt in BTW). Do you feel this way about all products that auto-update?
This was the only point I was actually making, yes.
> But don’t go spewing certifiable nonsense about how Tesla backdoors your car and steals your personal data for profit.
Aside from niggles about what constitutes a "back door", I was not doing that.
> There is nothing in their terms or privacy policy that indicates this is happening, and data collection that could expose PII is opt in.
None of that is actually reassuring, but the reason why is a whole other, very large, discussion.
> The way I see it, you’re essentially uncomfortable with Tesla being able to update the software on your system (which is also opt in BTW).
No, I'm uncomfortable with the data connection to Tesla. I'm uncomfortable with their data collection, and I'm uncomfortable with them having any sort of control over the car.
> Do you feel this way about all products that auto-update?
Yes. I consider auto-updating to be harmful. But the reasons why are another long, separate, conversation.
Again, I have no idea what you mean by "their data collection". What data are they collecting and how specifically is it being used in an untrustworthy, and harmful way? Our interests are aligned to get to the bottom of how Tesla handles data, because I don't want to own a car that is spying on me and you want a world where the internet doesn't exist (only half tongue in cheek).
EDIT: Also just so you're aware, did you know the car part of a Tesla works entirely offline at 100% capacity? Did you know the infotainment system, hud, etc. software can crash and you remain in complete control and full operation of the vehicle while it restarts. If you went in an disconnected the LTE antenna you'd have a connection-less Tesla. The fact that Tesla has designed the car this way speaks just a little to the quality of their engineering. The car is more like a plane than you'd think.
As I understand it, they are collecting data about the operation of the cars.
> and how specifically is it being used in an untrustworthy, and harmful way?
I didn't claim that it was. I was expressing my objection at it being collected. I have the same objection to similar data collection by software, electronics, etc.
Allowing data collection is an act of trust. Tesla (like most companies) has not earned that trust, and speaking generally, this trust has been so commonly abused that I give nobody the benefit of the doubt.
> you want a world where the internet doesn't exist
Your tongue may only be half in your cheek, but this statement literally could not be more wrong.
> did you know the car part of a Tesla works entirely offline at 100% capacity?
I would certainly hope so! If it didn't, I'd be saying that Tesla's design was inherently broken. I'm not saying that.
Since you are claiming I have opinions that I do not have, I clearly have done a terrible job explaining what my opinion is. It's pretty simple: the collection of usage data has been widely abused for a long time. Because of that, I have zero trust in almost any company that they won't abuse any data they get about me or my use of my machines. I think that's been well-earned. Teslas (as well as other cars) collect a great deal of data. I object to that.
It isn't because "Tesla sucks" or anything specific to Tesla. It's because Tesla (and not only Tesla) is engaging in a practice that historically has been abused.
You're missing the part where it's not inherently linked to your PII without your consent (for example during a troubleshooting session).
> Since you are claiming I have opinions that I do not have, I clearly have done a terrible job explaining what my opinion is.
/eyeroll. I said I was playing.
Okay. I understand what you're saying. Removing all other noise, you just don't want data collected and Tesla hasn't done anything to earn your trust.
My response is simply that I think this is a blanket assessment that comes from an uninformed position about how Tesla's product actually works vs other car manufacturers vs tech companies in general, and that you're unfairly lumping Tesla in with #abusivebigtech. There's a lot of security research and evidence that supports the conclusion that Tesla does give a shit about both the security of their platform and the privacy of their users. In the absence of evidence suggesting Tesla abuses user trust, I do not presume guilt because that's a pretty harmful MO. Since your argument is essentially "but they're big tech", I can't help drawing the conclusion that your position on this topic boils down to that of a HN curmudgeon.
---
Anyway... car manufacturers aside, I'm also really struggling to understand what your proposed solution is where service providers don't have any data about users. (Let's not even get into in-product functionality like needing to uniquely key a user's account or send them communications.) Serious question: have you ever built a product? Not having any data whatsoever is great (I've tried it, trust me I used to think very much like you do)... for about 30 seconds until one of your users has a problem. They write in and oh shit now you've got their email. Let's sweep that under the rug for a second, you read their request for support and what do you do? You have absolutely no way to help them so your response is limited to "we don't collect software telemetry in any way sorry frustrated user, you're SOL". That's generally understood to be a wholly unacceptable response from a company the user is paying for a working product, so what privacy conscious companies with good product experiences do is [ask the user if they can] collect anonymous diagnostic and usage information. This gets you a little further, but you still can't do anything to help that user who wrote in because you can't find their telemetry since it's all totally anonymous. So you realize the lesser of two evils is to collect anonymized telemetry. This data doesn't contain the user's PII, but if the user consents, they can share the necessary identifier with the company when they submit the support request, and voila you can investigate and solve the user's issue, leaving the user happy.
The point is that you can't just unilaterally obliterate all data collection and remote connections and end up in a perfect world. You have to have a conversation with users about what data is collected and whether it's okay for it to be collected. I think this idea that the "good" state for software products is zero data and anything more than that is abusive is in fact harmful. It's harmful to product user experiences and it's harmful to protocols and standards when they weirdly hyper focus on specifying things in ways where access to unique identifiers is either nonexistent or controlled (rather than just designing for user permission). It gives incredible power to central authorities when you tell everyone they can't know anything about anyone, unless they're a blessed platform. Anyway I'm rambling at this point, but I'm really just curious how your vision for software actually works in practice. I don't see it without some radical shift where everyone refers to each other by the mnemonic version of their public keys or something incredibly foreign.
No, I'm not missing that. It's just not a significant point to me, in large part because I think that the definition of "PII" is too narrow. For instance, I consider the identity of the specific car I drive as being PII.
> you just don't want data collected and Tesla hasn't done anything to earn your trust.
Yes, exactly. And that's not a special stance about Tesla. It's my stance with most companies.
> I think this is a blanket assessment that comes from an uninformed position about how Tesla's product actually works
I'm sure that's true. But, honestly, I have no motivation to spend the time and energy to inform myself about how Tesla handles this stuff. To do so in any meaningful way is a moderate research project that I'd have to have some real reason to engage in. I don't think it's unreasonable to follow a larger heuristic until there's some reason to pay attention to a particular product or company.
> I can't help drawing the conclusion that your position on this topic boils down to that of a HN curmudgeon.
Draw whatever conclusion you wish. I haven't arrived at my attitude arbitrarily or through some sort of "big tech bad" mentality. It's due to years of actual experience.
> Serious question: have you ever built a product?
Not that it matters, but yes, many. Several rather successful ones. The odds are reasonable that you're even using one or two of them.
> You have absolutely no way to help them so your response is limited to "we don't collect software telemetry in any way sorry frustrated user, you're SOL".
This just isn't true at all. I've never had to say anything like that. Blanket telemetry is not necessary to help customers with malfunctions -- if it were, then all the software that I (and everyone else) sold and supported before telemetry was even possible would have been impossible to support.
That said, I have occasionally gathered telemetry as part of the support process. But it's on a case-by-case basis with the full cooperation of the customer, not a blanket thing the I subject all customers to.
And, to be clear, I'm not opposed to telemetry in general. I'm opposed to forcing it on people, or engaging in it without their informed consent.
> I think this idea that the "good" state for software products is zero data and anything more than that is abusive is in fact harmful.
My position is certainly not that all data collection is abusive. My position is that our industry has been widely abusive in terms of data collection.
So VIN (vehicle identifier) is not included in the data collection, and, though Tesla collects the anonymized data by default in the US (this is not true in countries with stricter laws requiring any data collection to be opt in instead of opt out), you opt in to sharing anything that de-anonymizes it as needed. You also generally opt in to the collection of larger or more sensitive data (even in the US), on a use-case bases. I can go into settings and enable/disable road segment data, for instance. The Tesla privacy policy is a 5 min read and deliberately accessibly worded.
I know you're acting in good faith, but I see this theme reappear on HN (and generally) where people cry out for change, society responds, and then the people who asked for change are too jaded to believe that it's possible that somebody listened. Or it's "too big of a research project" to care. That's the reason I'm even arguing the point here. If we were talking about Facebook I wouldn't give it the time of day because there just isn't anything redeemable about their past actions or current product. But you're talking about how you are compelled to go buy an old used gas guzzler as your next car because there isn't a car company today that is possibly trustworthy. As a person who cares about privacy and security, and as a Tesla owner, I'm simply challenging you to maybe check your gut heuristic on Tesla, because they make a really good product, have been positively received in the security community, and have a privacy policy that reads like they care about treating your data with respect. I could be wrong in the future and you get to say I told you so. But if not, they might be a solution to your problem once you're in the market.
Nobody will "own" their car, anyway.
And if that doesn't happen, then I guess I won't be using a car. Which is probably the best idea in terms of environmental impact, anyway.
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.
If there is any good news about this it is that Full Self Driving appears to be a more difficult problem than Elon expected and they are struggling with it.
The problem is not that an automaker wanted to have functionality that could legitimately unlock cars for legitimate customers. The problem is that creating this functionality entailed making a much larger backdoor that will invariably be abused by independent attackers, police, the company itself, etc - to do much more than merely unlock the doors.
There have been numerous talks at security conferences and solid research done on the security of Teslas. I don’t think you realize how sophisticated these things are. The infotainment system and the CAM bus are not the same software, for example. And attackers aren’t gaining remote access to them either (Teslas use stronger ssh keys than you do). So I’m not sure how this mega backdoor FUD even plausibly exists. A car isn’t a safe either, if law enforcement has a warrant for my car, or house, they’re going to forcibly break in if needed (heck they’ll even do that for a safe). Seems better to have Tesla legally complying/cooperating with law enforcement than the alternative where people use force.
I’m not saying we should build backdoors into everything for the kids, just to be clear. But I can be a happy consumer/user of a car with remote unlock functionality that’s implemented more responsibly than your npm account without devolving into “zomg Tesla backdoors your life to give you that feature” histrionics. That’s just not true. Like you, I would love to see, just like I argue for phones, the ability for enthusiasts and/or hyper paranoid people to install their own software roots in a supported manner if they don't want another party having access or if they want to delegate to a different 3rd party. And let me turn it on/off, sure. But having a car with remote unlock is not some gateway drug selling your digital soul.
SSH !?! This supports my point - a remote command prompt is much more functionality than what is required to unlock doors. It's not really appropriate to talk about this level of control as if it's merely a necessity for remote door unlocking.
You're the one engaging in histrionics here - sour grapes about the lopsided relationship that was included with functionality you enjoy, as well as strawmanning those concerned with how ownership is being eroded as rare enthusiasts or "hyper paranoid". FWIW it's perfectly consistent to pragmatically trust specific manufacturer(s) today, while still being concerned about the societal effects of centralized control continuing to be normalized.
It's certainly possible to implement the same functionality you're enjoying in ways that put the owner in charge and treat the company as a possible attacker. But it takes more rigorous design and development, and isn't likely to happen on its own as long as people continue to carry water for simplistic centralization.
Yeah. I'm not so naive to try and argue `unlock` is the only thing Tesla can do to your car remotely. Like I've said, they can update your car if you agree. If they can update the car then they can do whatever the hell the hardware allows, in theory. This is true for anything (software/firmware/younameit) that can be updated. Are you reading this on a computer with a modern OS?
I never said we shouldn't be critical of centralization and eroded notions of ownership. I am rebutting the sensationalized "Tesla has a persistent backdoor to your car and is using it to spy on you" spin on the issue. At this point in my life I'm becoming more of a tech pragmatist. One thing that has become clear to me over the years is that people don't want to be single points of failure. Putting people in that position yields poor products/user experiences. I believe there's a way to legislate and lay ground rules for ownership and access to consumer hardware that allows custody to be responsibly shared between a company and a consumer. I don't believe we're socially there yet, but making up fake news about how companies are spying on users and can't be trusted doesn't help progress the dialog. (TFA is another example of not advancing the dialog, which is how this all ties in.)
Trust is always an issue and always present. We have to make trust decisions. What I'm advocating for is making decisions based on facts and evidence, not FUD and slippery slope speculation. What I'm arguing is that it's important whether Tesla is acting in a way that is culpably deceitful and has given users reasons to not Trust them. If the evidence shows Tesla is being dishonest and operating in a way that is not in accordance with their privacy policy, then yeah grab the pitch forks I'll be there right next to you. This goes for anybody asking for trust, not just #companieselonmuskhastouched.
Otherwise name an EV that isn't cloud connected, is somehow innately more trustworthy, and that saves me 5k/year on gas.
I had hoped we weren't going to go down this path. It's not the responsibility of the free world to try to pry the exact details from closed systems to demonstrate their exact insecurities. Based on the functionality they have (remote update) plus the various bits that have been reported about their infrastructure (remember that reddit post about MSWin+bubblegum?) plus the general pattern when any proprietary system says "trust us we're sooper sequre", Tesla (any every other centralized system) really does not deserve any benefit of the doubt that they have done work to actually design a telemetry/privilege minimizing system.
> If the evidence shows Tesla is being dishonest and operating in a way that is not in accordance with their privacy policy
Meh. The penalty for violating privacy policies in the US is zilch, and even if it weren't such policies are generally non-binding and can be retroactively changed at any time. Without a privacy law ala the GDPR, the sensible thing to do is to assume that any piece of information you feed into the surveillance industrial complex will be stored indefinitely and may eventually be used against you.
> What I'm advocating for is making [trust] decisions based on facts and evidence
I feel like we could have some common ground here, but your previous arguments have carved off way too much in defense of lazily-implemented centralized control, based on seeing no evil. If it's possible to architect systems such that they don't backhaul information to their manufacturer or give their manufacturer ongoing control, then we should criticize those that do - regardless of the pragmatism of using them anyway because they are the least worst option and/or beneficial in other aspects.
I myself use many things that compromise my own privacy through suboptimal implementations, but I'm not going to sit here and defend the companies because they haven't been caught doing anything too hostile at the moment. Rather I accept that they're inherently attackers that I've chosen to trust (NSA definition) with some amount visibility into and control over my activities due to other benefits they provide - while remaining generally interested in more secure alternatives.
Actually you're wrong. It is the responsibility of the person making an accusation to back up their accusation with credible evidence and facts. That's how things work in the free world, at least. Presumption of guilt is just too dangerous and detrimental to a free society and so presumption of innocence is ingrained in our entire legal and judicial framework.
I'm not defending Tesla in the face of evidence that they are naive and abusive. There's simply not evidence in the first place that they're naive and abusive (and if there is, you've certainly failed to procure it). There is, in fact, the opposite, as reported by security researchers and as stated in their privacy policy.
> Tesla (any every other centralized system) really does not deserve any benefit of the doubt that they have done work to actually design a telemetry/privilege minimizing system.
It's not the benefit of the doubt. I was literally in the room at Defcon when Kevin Mahaffey and Marc Rodgers gave the talk that kicked off the Tesla bug bounty and security research program in 2015. And they had good things to say. Certainly their impression was not "this shit's dubious IDK if we can trust Tesla's security engineering" which you seem to be implying is your default impression because Tesla is #bigtech.
https://www.cnet.com/roadshow/news/tesla-hackers-explain-how-they-did-it-at-def-con-23/
Here are some privacy policy excerpts:
> Your Tesla generates vehicle, diagnostic, infotainment system, and Autopilot data. To protect your privacy from the moment you take delivery, Tesla does not associate the vehicle data generated by your driving with your identity or account by default. As a result, no one but you would have knowledge of your activities, location or a history of where you’ve been. Your in-vehicle experiences are also protected. From features such as voice commands, to surfing the web on your touchscreen, your information is kept private and secure, ensuring the infotainment data collected is not linked to your identity or account.
> Tesla enables you to control what you share. Within your vehicle’s touchscreen you may enable or disable the collection of certain vehicle data (Software > Data Sharing), including Autopilot Analytics & Improvements and Road Segment Data Analytics. If you choose to enabled data sharing, your vehicle may collect the data and make it available to Tesla for analysis. This analysis helps Tesla improve its products, features, and diagnose problems quicker. The collected information is not linked to your account or VIN and does not identify you personally.
Do you have evidence that Tesla is not honoring its privacy policy? If you want to change my mind, show me the data on how Tesla's systems are insecure/naive/user-hostile and I'm happy to continue the conversation.
PS
Consider this: you can buy a Tesla in the EU, no? You think Tesla has code like `if user.country == "USA" && user.state != "CA" { user.abuse() }`? I think it's actually more likely that, since Tesla is a global company, that they have a better security and privacy story than most strictly-USA focused companies. I actually trust small US startups far less than mature multinational corporations with my data. I've been at both and large companies have swaths of lawyers making sure people are in compliance with the law where small startups have trendy founders that prefer to ask forgiveness rather than ask permission.
This isn't tenable for security, especially in light of computational complexity. Rather it is up to the party claiming "trust me" to show that they are trustworthy. One major way of doing this is to publish source code that is easier to audit than having to reverse engineer. There is a long history of proprietary companies claiming to be secure while actually being an absolute mess internally. In the face of that dynamic, it is reasonable to be suspect of proprietary systems a priori.
> Do you have evidence that Tesla is not honoring its privacy policy? If you want to change my mind, show me the data on how Tesla's systems are insecure/naive/user-hostile and I'm happy to continue the conversation.
The argument isn't that Tesla is not honoring its "privacy policy" or is currently abusing its backdoors today. Rather it's that the systems they have shipped can be easily abused tomorrow. I've used the words "insecure" and "naive" about the security of Tesla's cars versus Tesla as the attacker - a threat model that bug bounties generally don't address. I do agree that currently, Tesla is (seemingly) not doing much attacking of their customers. The point is that can change tomorrow and the software has been seemingly designed so there will be little the owners of cars can do to protect themselves.
I looked through your comment history to see where you're coming from. Surely as a Linux user you can appreciate that there is a stark difference between software that is widely expected to respect your own interests as the user (and has been decently scrutinized for this quality), and mostly opaque software that has been created by a company to chiefly serve that company's interests? Especially software that has Internet access, so that its behavior can change when the company's interests change?
https://electrek.co/2023/03/24/tesla-hacked-winning-hackers-...
Tesla literally paid people 100k to pentest their car so they could fix any bugs/issues found, so that you don't get hacked.
But with another car, I can choose who (if anyone) I'm willing to give that ability to. I certainly wouldn't want it to be Tesla.
You could design one of those apps to end-to-end encrypt all comms with the car, but I don't think most people would appreciate the usability hit.
Correct. And that (along with everything else related to it) is why I won't own a car that was made too recently.
Anyway, if you don't want to use vehicles which communicate with a server then good for you. Really. But if you’re taking such a stance I hope it’s based on informed data and consistent principles and not cringy FUD.
There is nothing that leads me to believe that a Tesla is a “surveillance platform” despite it being a machine that is capable of becoming one. It’s a car. It gets me from A to B. Thats the agreement I have with the manufacturer. I primarily use my app/phone instead of physical keys. I opt in to sharing diagnostic info with Tesla to improve the experience. It’s all pretty above board.
None that I'm aware of.
> Tesla comms are encrypted.
Which is very good, but still leaves the problem of Tesla getting the data.
> if you’re taking such a stance I hope it’s based on informed data and consistent principles and not cringy FUD.
I'm taking this stance because the history of the tech industry's practices in this area is full of so much abuse that nobody gets the benefit of the doubt anymore.
> Thats the agreement I have with the manufacturer.
I'm glad that you are comfortable with that level of trust with Tesla (or any car company). I am not. Which is, I suppose, why you'll own a Tesla and I won't.
Let me put it this way. In this case, specifically, what you're claiming is pretty outrageous and, if true, sounds like something I should take more seriously too. If you can give me examples of Tesla abusing users' trust and operating in a way that is not in accordance with their privacy policy, user consent, and/or general understanding of techno-decency, then please surface the evidence to support your claims so I can consider your argument more seriously. Otherwise what you're claiming does not align with my experience owning a Tesla and my knowledge about how they're designed and engineered.
The pragmatic in me understands that there is always a risk that a future software update will change the behavior of a product in a way that is not in my interests. That is a risk I take by using any software product and something that responsible people keep an eye on, agreed. I'm just not going to categorically avoid software that can be updated out of fear that it could start spying on me. If it starts spying on me without my consent, good bye.
I also understand that we may even have different tolerances for living with connected hardware and software. If you're the type of person that compiles their own firmware and updates their own devices offline after personally vetting the software, I'd buy your concern about trust a little more too. But honestly it just sounds more like you're saying "yuck Tesla, I wouldn't trust them to build a respectful product", while ignoring the fact that you're likely posting this from a smartphone, if you know what I mean.
I have made no specific claims, I think. If I did, they were unintentional. What I'm claiming is more general: that in the tech industry, data collection on users has been so widely abusive that I am not comfortable trusting any company with data collection by default. Specific companies can earn my trust, of course. No car company has done that, therefore I trust none of them with my data.
Is this the claim you're referring to?
> But honestly it just sounds more like you're saying "yuck Tesla, I wouldn't trust them to build a respectful product"
I do not intend to be singling Tesla out except insofar as Tesla (as I understand it) engages in more data collection than other car manufacturers. That said, I'm a bit more suspicious of Tesla just because of Musk. Not a lot more suspicious, but some.
> while ignoring the fact that you're likely posting this from a smartphone
I'm not. But I also have mentioned here that when my current smartphone dies, I won't be replacing it with another -- specifically because it's become so difficult to render them safe that it absorbs too much of my time and energy. That makes the cost/benefit of a smartphone too unfavorable for my tastes.
But with the smartphone I currently have, I do not use it for very much online stuff -- certainly not for web browsing -- anyway, because of safety concerns.
Why can't we just hold the opinion that HTTP and operating an automobile are two separate things entirely?
I've been driving for 20 years without web crap and I've never sensed the need to share telemetry with anyone during that process.
I guess because people want to listen to Spotify while they drive and have navigation data fed to their HUD...
100% agree. WTF. I'm losing a bit of faith recently in HN, a significant number of people seem to have gone full tinfoil hat.
Edit: downvote all you want, nutters, but this entire discussion is mostly people ranting about things we don't even know to be true, with the justification "well if they aren't for sure doing it now, they will!"
What happened to being data driven?
1. Your comment was kind of a "me too" comment that added nothing (or little) of substance to the conversation. On HN these types of comments are typically downvoted, regardless of topic or whether the voter is wearing a tinfoil hat.
2. You complained about the downvoting, and in addition added a personal insult to the downvoters. Personal insults are typically downvoted on HN as well.
3. You dismissed and strawmanned the "entire discussion" as "mostly people ranting about things we don't even know to be true." This type of thing is also frequently downvoted as it doesn't add anything substantive.
I recognize your username from this thread, you were one of the accounts that came to mind as a big bandwagon offender of the "it's all bad and there can be no nuance" rhetoric :).
Have a good day! And I mean that quite sincerely. It's a beautiful spring day here and I'm just visiting my desk momentarily after spending the last hour waking up the swimming pool and preparing it for this weekend. Time to go back outside and forget about the Internet for a while.
Other than this reply, I've ceased posting in this discussion and hidden it to avoid the temptation.
Let me put it into perspective: making your Tesla (a heavy vehicle probably driving 1 person) drive more is not helping the environment.
If you want to help the environment, don't drive a Tesla, find something that burns less energy (like a smaller car, or public transports, or an electric bike).
Well you are winning on the fix cost of building the vehicle (obviously). But you are still moving people in a vehicle that weighs 2 tons. The fact that it is an EV does not mean that you use less energy to move that weight, does it?
So yeah, if someone decides not to buy a Tesla or equivalent because they can use your shared one, you are winning. Now if someone uses your Tesla instead of any lighter vehicle that would use less energy during its life than the Tesla (which represents a lot of vehicles, not only bikes and public transports), then you are losing.
So let me repeat this: if you buy a Tesla because you think it's a "green" move, then save your money. You should buy a Tesla because you want a cool, expensive, heavy sport vehicle. That's bad for the environment, but I guess that's the cost of being cool.
I dont understand how this would change anything.
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.
Not giving these bastards money is a good start.
[0] practical, not possible.
> for some companies, like Google or Facebook, it's pretty hard for a consumer to actually give them money in the first place, nor is practical [0] to not use their products.
Well, the only Facebook product I use is WhatsApp, and that's to talk with one person in Europe who only uses WhatsApp. The only Google product I use is YouTube, and I only use that with an account that is not used for any other purpose, and on a tablet that is not used for any other purpose.
So my experience is that avoiding these companies is entirely practical. All you give up is a small amount of convenience.
Sent from my Librem 5.
The cost/benefit ratio of having a smartphone is no longer favorable, so I won't have one. That seems like a reasonable stance. I don't know what's unwise about it -- whether or not I own a smartphone will not affect the world in any way.
But it will: in addition to not giving money to Qualcomm and co, I am giving money to the alternatives and constantly reminding all banks and organizations that alternative systems exist apart from the duopoly (whenever they offer me their apps).
I don't need to go to all the hassle of trying to validate what phones and apps are safe or not to make the point.
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
For a high profile target you might also be able to track their approximate location if you know their starting point and their acceleration profile - speed up, slow down, turns, time taken. Enough, at least, to execute an ambush.
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.
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 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...
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.
https://www.reuters.com/article/us-qualcomm-m-a-broadcom-tim...
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."
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.
Chinese mobile phone Xiaomi R1 spies on it's users
(or any chinese manufacturer using snapdragon 630)
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.
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.
There are all kinds of licensing agreements that go along with physical products. For example a book or videotape that is licensed to be used in a library costs more than a book or videotape for personal consumption
And is it sending any data that would be then determine it if so?
It just seems pretty far fetched to me that this is at all the point. Not impossible, but very improbable.
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
No thanks. What's better about it than a regular Android phone with one of those privacy-oriented OS, privacy-wise?
Also, two comments on HN, both about this phone?
Do you have anything constructive to say about the PinePhone? "Absolute trash" does not really cut it.
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.
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...
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.
Do you have any documentation on this? Even firmware such as Intel ME or UEFI implementations connect directly to the Internet itself. So I have a hard time believing the firmware on a Qualcomm SOC does not directly connect to the Internet itself.
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.
In fact, the article claims:
> During operation, the covert operating system (AMSS) has complete control over the hardware, microphone and camera
Correlation does not equate causation but they want you to think it does so you run to their web shop to buy a rebranded Google Pixel 7 (with Samsung's Exynos 5300 radio modem and accompanying firmware which has just as much control over the hardware as Qualcomm's AMSS has...).
The AMSS has control of the hardware, but there's different components, each implementing different functionality, they may be able to talk with each other using various IPC mechanism, and they do, but mostly using Android as a middleman ( Linux )
WiFi ( known as cnss on QCOM ) is implemented in a different block than GPS, they don't have direct communication in place. It's routed via the Linux kernel ( and userspace processes )
> 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.