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

[3] https://grapheneos.org/

[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?

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...

https://grapheneos.org/faq#default-connections

The chipset is aware of the operating system, or rather the other way around. Manufacturers use kernel modifications and user space libraries provided by Qualcomm for their chipsets.

Qualcomm drivers are blobs, and they’re basically the main game in town for android, so the drivers would be shared by even their own device.

They stopped short of investigating what was causing the pull of the A-GPS data. It could have been something in the distro they used, that the other distro didn’t.

It’s such a hand waivy piece overall

I worked with aGPS a bit when I started my career. As I recall at that time, the chipsets only accessed the aGPS service if something asked the chipset for the current GPS coordinates of the device. The chipset could avoid the long load times of the locations by using the network to assist the GPS and get the current state. And because this is part of the cellular network standards, this would just be another thing the chipset did when working with the network, like receiving an SMS, or registering with the network so it can be notified of an incoming call or packet of data.

I wasn't aware that aGPS could also be done over WIFI, but I suppose it makes sense that it can. That might involve the OS as well, as other comments have pointed out to get to the WIFI network.

So I'm not ready to jump on that Qualcomm chipset is the culprit, or this is nefarious, unless we're sure there is no software process asking the chipset for the GPS coordinates / triggering an aGPS call, and that the identifying information alleged is actually in those messages and this isn't just some generic policy statement. And that this actually always goes over wifi, and when connected to a cellular network, it doesn't use the network operators aGPS. The network operator already knows all the alleged details based on the global standards of how a cellular device communicates with the network.

This surely isn't "the chip" doing this. It's the driver suite provided by Qualcomm, which is (obviously) required for a functioning device. The open Android distros still need drivers, and are essentially copying these files verbatim without review.

Somewhere Qualcomm has a privileged daemon able to get this info.

The "no packet analysis" is an interesting angle, because it would take all the fun out of complaining about plain http: would we prefer open messages with a known low amount of things to hide, or hidden messages with an unknown amount of secrets?

That's enough under GDPR, which is the point of the article. Even though the GDPR requires active informed consent, there are still so many layers openly sharting on that requirement, and no one holds the big players accountable.

Wireshark logs or you're just doomsday speculating. Show me the call to izatcloud.net with more than just http header identities every AdTech/MarTech company is already capturing from your web traffic and deanonymizing you.

What else do you need ?

Evidence/details of the very specific claims that go beyond that.

Class action lawsuit time.

jokes aside, I also don’t understand the criticism. The author even took the effort to write Qualcomm, and they admitted to this!

This is the same. Quadcomm have the capability, and the claimed legal right. It essentially doesn't matter whether they do, or do not, actually execute on it today.

I would, yes. There's some reason that they claimed the legal right to do so. That they aren't actually doing it at the moment I check means nothing, because they could start doing it at any time in the future.

Sorry, but you're the one who is missing the point. The very act of making a network request gives away your geolocation + time of use https://kieranhealy.org/blog/archives/2013/06/09/using-metad...

You could use an on-device firewall app, too; but OEMs / ODMs can always bypass it as they pretty much control not only the software but the hardware, as well.

They installed a custom OS which apparently includes Qualcomm's indoor positioning service iZat, but is missing the EULA item to allow the user to enable/disable the service.

iZat exists for at least 6 years, and the vendors who implemented it usually have a separate checkbox in their startup wizard to allow it to work.

Example screenshot after a quick google search: https://lgk20.com/wp-content/uploads/2021/09/57-60.jpg

> Affected users could try blocking the Qualcomm XTRA Service using a DNS-over-TLS cloud-based block service, or re-route this traffic yourself to the proxy server from GrapheneOS […]

if these requests were being made below the OS, akin to IME, you wouldn’t be able to substitute the DNS like that.

unless they mean that you could reroute things upstream of the phone — but most users don’t deploy their own fleet of LTE towers, so i doubt that’s what they meant.

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.

It's done by the ROM, at the OS level, not the chipset. Some custom ROMs will proxy this request to mask your IP.

Nobody has shown evidence of that. The article certainly didn't

You can remove the services that download the extra GPS data, nothing stops you from doing that, aside making GPS unusable :)

Then they conspicuously plug their phone, which doesn't have a Qualcomm chip, and linking to its store. I'd like to see more presented before being accepting of such a story.

> Investigating this further we can see that the packages are sent via the HTTP protocol and are not encrypted using HTTPS, SSL or TLS.

So why not just post the actual data, instead of:

> To clarify, here a list of the data Qualcomm !!may collect!! from your phone according to their privacy policy:

Also, how does Qualcomm's privacy policy affect me as a user directly? I didn't agree to that. Or do I "accept" it because it gets passed over by manufacturers?

I need a source for this, because my personal security model rests on the idea that Apple is NOT doing something like this.

Number 1 in marketing according to ChatGPT.

Why do you think that is a reasonable assumption?

Just curious, where did you find this?

[1] https://en.wikipedia.org/wiki/GPS_signals#Almanac

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.

<rant because I hoped for more outrage on this and am not seeing it>

This makes me mad. I'm so sick of this type of thing. It's a horrible time too because the embedded 5G chips are about to be part of everything, sending telemetry back about where they are and what they're being used for. I think it's utterly ridiculous that if you aren't ok with this type of thing, then you have to go way out of the mainstream to find products, and often there's no viable option. "Ownership" now means nothing.

Imagine if you bought a car from somebody, and they secretly kept a spare key and periodically used your car to run their personal errand. Would you be ok with that so long as they always had it back before you needed it so you never knew they were doing it?

That's what is happening when you "buy" a device and the device maker uses it to run code that serves only themselves (without receiving permission), to the detriment of your privacy. I can only hope RISC-V combined with people willing to care can lead to a return to a time when people actually own stuff and ownership is something we respect.

</rant>

It's worse than that. It's like you bought a house from somebody and they secretly left cameras all over the living room, bedroom, bathroom, and kitchen so they can get 'telemetry' ostensibly to improve the next house they build, for 'safety' in case there's an accident, and to 'protect the children'.

I think people are so overwhelmed and anxious that there's no space for fighting back against this kind of over-reach. And even if you did have the time and space and energy, how would you even go about it?

https://www.reuters.com/technology/tesla-workers-shared-sens...

So they can also exfiltrate audio and video

https://dl.acm.org/doi/10.1145/3309074.3309076

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.

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."

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.

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.

+1 for the Aperture ref.

  Aperture Science  
  We do what we must
  because we can. 
  For the good of all of us.

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.

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.

I guess because people want to listen to Spotify while they drive and have navigation data fed to their HUD...

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.

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.

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?

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.

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.

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.

Good bye high speed chases.

This has been widely known for more than a decade (Sorry I can't provide with a source. I was expecting Google search-in-the-past feature to work, but it doesn't).

As to whether the privacy policy has been declared properly or not, it depends on the OEM: See for instance https://www.bsr.at/mediafiles/Handbuch/CipherLab/User_Guide_... which shows Qualcomm's IZat default integration (This documentation shows an Android 7, but that screen has existed since at least Android 4.4)

> Sure, other chip makers do sketchy things, but is that really where we're at in 2023?

Literally all chip makers literally do that exact thing (except maybe the Unique ID part), just because that's how you're supposed to do A-GPS. For A-GPS you need at some point an oracle that is capable to give you an approximate location. There are some privacy-compatible ways to do that, but I'm not aware of anyone who even looked at it. (Looks like GrapheneOS skims that feature altogether, that's a way that works)

> It's a horrible time too because the embedded 5G chips are about to be part of everything, sending telemetry back

Even though Qualcomm can make things worse, the vast majority of IoS already do just that, and don't require 5G.

Of course I overall agree with you on lost ownership of modern electronic devices (and as you point out, everything became electronic devices), I'm just saying that it's nothing new. I think you need to get back at least a decade to see the unstoppable start of it (though DRMs are much older than that)

> I can only hope the RISC-V combined with people willing to care can lead to a return to a time when people actually own stuff and ownership is something we respect.

What does the ISA change in that regards? I would guess that the currently most deployed RISC-V device are nVidia graphic cards. And you're probably very aware that you don't fully own nVidia graphic cards. I'm also aware of other RISC-V devices in the field that are even more locked down.

> This has been widely known for more than a decade (Sorry I can't provide with a source. I was expecting Google search-in-the-past feature to work, but it doesn't).

Yep. Nitrokey's post was disappointing but understandable from a marketing perspective.

The thing that needs more discussion is the closed source stuff Android OEMs / ODMs run at higher ARM privileges rendering all of Google's grand ceremony around Android security moot (other than on Pixels may be).

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 (:

The shocking news is that modern smartphones connect to a huge list of locations for various purposes. A large laundry list of providers can collect your ip addresses. But there’s little way around that. Every phone with a GPS chip will download that almanac from somewhere. Qualcomm uses Qualcomm. Broadcom will likely use Broadcom.

The whole article is "Qualcomm privacy policy says they can do xyz" and then extrapolating from there.

And they have clever lawyers to write their privacy policies. We don’t, so we have to “round up” in a sense unless we want to be blamed for agreeing to things.

The Qualcomms of the world created this situation, we just have to deal with it.

https://www.qualcomm.com/site/privacy/services

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.

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.

For me, this is much broader than some specific technology device. This is about an epic struggle between the "consumer" class and some elite technocratic class.

To quote Ron White:

"And then they squared off with me in the parking lot, and I backed down from the fight, cause I don't know how many of them it would have taken to whip my ass, but I knew how many they were going to use. That's a handy little piece of information, right there."

It might be, but we haven't seen the packet captures yet. I'm not trusting this shallow analysis (from a source I don't have any particular reason to trust) without seeing more details or corroboration.

I miss the dumb everything days, where the manufacturer simply could not spare compute power on additional features like telemetry.

Good point, there's no reason a manufacturer couldn't build it in. My thought was more along the lines of lower barrier of entry that would enable more competition (Qualcomm is near monopoly and has pretty anti-competitive practices that make it super hard to compete with them), and hopefully there will be more transparent options out there. As a user of GPS I'd like the option of enabling something like this because the old days of taking forever to sync with the satellites did suck. But I want to be able to decide for myself, not have the decision forced upon me by the chip's firmware.

> I miss the dumb everything days, where the manufacturer simply could not spare compute power on additional features like telemetry.

Oh man, me too. The nostalgia for this burns like a fire in my soul.

Indeed. The only "smart" things that I'm willing to have anymore are those that I've built myself. Apparently, very nearly no commercial manufacturers can be trusted anymore.

GPS has a built-in error for the civilian use, and a higher-accuracy system for military use. The concerns when it was deployed included unwanted parties using GPS as a guidance system component for missile / drone attacks, etc.

This led to the early GPS enabled phones needing an enhancement to their positioning system. The early releases (think car navigation systems) would be tuned to un-do the GPS offsets, but as that was rarely a 100% solution, they would "smart match" to the nearest viable alternative. This is why in many older car systems, you are sometimes registered as being on the feeder road (or a parallel road) until the system can no longer resolve your travel with your map position.

For smart phones, the error was deemed to great to have decent customer satisfaction, so enhancements to GPS came into being. The phones would listen for nearby markers (typically wifi stations) and report them back to a data warehouse, effectively building a dynamic map of all the wifi points. Then one could anchor that map based on non-moving items (like cell phone towers) and obtain fine-grained positioning information by running relative strength matches to the nearest 3 or 5 wifi access points.

The system updates eventually for broadcasters that change ids, are powered off, are relocated, etc. It has error checking built-in to reduce confusion around one or two new / missing / relocated markers.

All of this was driven by customer demand, and the data collection necessary was mentioned in the past. As the maps are unlikely to ever be placed inside of phone devices, and would require intensive storage to duplicate into each phone, as well as intensive bandwidth to update each phone, odds are that the calls to the manufacturers (which are selling "enhanced GPS" positioning systems) will continue for a very long time.

The solution? Pressure the government to release accurate GPS positioning, so industry will see the running of an independent positioning system as redundant and not-cost effective. Then, when you get a position with GPS, you get an accurate position, and you need not send a signal to correlate nearby signals with your true position.

Does it suck? Yes. Is the current system subject to abuse? Yes. Is the current system abused? (I'm a skeptic of human nature, so) Yes, but its abuse patterns seem to be nearly identical to its use patterns, with the difference being that the companies providing this service can use it to help people find their way to the grocery or to help other people find their way to a specific customer.

Qualcom and others have a very vested interest in not abusing the system, as they would lose their competitive edge should the government decide to take action against them. That said, many people worry about the government being the party abusing the system.

This was called "selective availability" and that practice stopped in 2000. There is no longer any intentional error being introduced.

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.

I wouldn't say this is equivalent to them "running a personal errand". If they were remotely enlisting your device in some computational task, sure.

But modern cars do grant the car company the "keys" to your car:

- Tesla's system - GMC OnStar (since 1996!) - Ford SyncConnect (since 2017) - HondaLink - BMW Assist - VW Car-Net

Even if you don't subscribe to the service they can still remotely access your vehicle...

Most people don’t walk in the field and have never seen or been bothered about the gopher or his little hole.

So everybody brushes this guy off as paranoid and his fears as exaggerated.

Then one day in your small walk you stumble upon the hole and start panicking yourself and trying to raise the problem.

You are wondering why isn’t everyone outraged by the gophers. Even that guy that used to warn everyone daily about the seems to not care anymore.

Well, it’s not that he doesn’t care. He is tired and defeated.

I dont understand how this would change anything.

You putting quotes around words such as "buy" and "ownership" push people away from your view, and any view like it, unless they have already adopted it that view or a similar one.

if you want this to change, stop ranting, stop scare-quoting normal English words because you disagree with the way they are used, and approach the problem logically. asking rhetorical questions and being angry is not how you get people thinking about this.

state your case, (we know it, but state it anyway) without emotion of any kind, and without unanswered questions. start by verifying what this article is claiming using your own device. the entire article could be BS designed to enrage people and to see how far it spreads before it is fact-checked.

it is very difficult to listen to someone who is ranting and who is speaking from a point of emotion unless you are emotionally invested yourself. it is much easier to ask someone to think about facts than it is to ask them to feel about emotions if you want them to think about what you are trying to say.

this turned out to be the case.

Well, it's an ad for another phone. That doesn't take away from the truth, but it's marketing even if it's true.

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.reuters.com/article/us-qualcomm-m-a-broadcom-tim...

Chinese mobile phone Xiaomi R1 spies on it's users

(or any chinese manufacturer using snapdragon 630)

https://www.qualcomm.com/news/onq/2014/09/izat-location-tech...

https://investor.qualcomm.com/news-events/press-releases/det...

Disclaimer: work at Qualcomm but have nothing to do with any of this

Was it a connectivity self-test or empty GET request? That's not ideal, but fairly benign.

Or was it a "phone home" reporting the device's ID, SN, IMEI, etc? That's a lot worse.

Or, did it truly contain PII or geolocation data? that's really bad. It matters a LOT what's inside the request, and it seems a little dishonest to not include it in the report.

The one issue with using GrapheneOS's connectivity check is that you're broadcasting to the network that you're someone of interest. An Android phone connecting to Google isn't great for privacy but it is normal. An Android phone connecting to a GrapheneOS domain isn't.

Thanks that's an interesting thought.

I had similar thoughts, but going the other way around. I was wondering whether you gave more entropy be not using Google's generate_204, than by using it (= do more IPs do generate_204 calls). But after trying to compute some estimates, I ended up thinking that not sending generate_204 was still better than sending it.

But yes, as you point out, the entropy provided by pinging /another/ generate_204 is much much higher. At this point, it depends if you want to lower the information you send to Google, or your carrier.

PS: Just in case, Android's connectivity check pings a "generate_204" endpoints that as mentioned literally just responds with a 204