11–20 of 346 posts
Interesting research. I have booted up Pixels using Qualcomm chips and have not seen the elusive izaticloud. The one issue with using GrapheneOS's connectivity check is that you're broadcasting to the network that you're someone of interest. An Android phone connecting to Google isn't great for privacy but it is normal. An Android phone connecting to a GrapheneOS domain isn't.
Interesting research. I have booted up Pixels using Qualcomm chips and have not seen the elusive izaticloud. The one issue with using GrapheneOS's connectivity check is that you're broadcasting to the network that you're someone of interest. An Android phone connecting to Google isn't great for privacy but it is normal. An Android phone connecting to a GrapheneOS domain isn't.
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.
This seems like a really shallow dive into what’s going on, and seems to exist largely to plug their own hardware? For example, how is the chipset getting “List of the software on the device” unless the chipset is aware of the operating system? They don’t actually do any packet data analysis to see what it includes as far as I can tell, so other than seeing some packets go through, the rest feels like idle speculatio…
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.
That's why you install a firewall on your phone and disallow all outgoing traffic by default - possible with Android, impossible with iOS as far as I know - and keep those drivers away from the 'net. Yes, the device works, you just see loads of 'connection errors' in logcat but those just tell me things work as intended by me by not working as intended by the likes of Qualcomm. As to aGPS being necessary this depends…
That's why you install a firewall on your phone and disallow all outgoing traffic by default - possible with Android, impossible with iOS as far as I know - and keep those drivers away from the 'net. Yes, the device works, you just see loads of 'connection errors' in logcat but those just tell me things work as intended by me by not working as intended by the likes of Qualcomm. As to aGPS being necessary this depends…
If it's being done by the firmware on the Qualcomm SOC then a firewall in Android is not going to save you.
Contrary to mediatek chips who openly send it to China or apple chips who also openly send it to Apple, and of course let's not forget the intel management engine ;)
MediaTek is not Chinese. You might be thinking of HiSilicon.
Interesting research. I have booted up Pixels using Qualcomm chips and have not seen the elusive izaticloud. The one issue with using GrapheneOS's connectivity check is that you're broadcasting to the network that you're someone of interest. An Android phone connecting to Google isn't great for privacy but it is normal. An Android phone connecting to a GrapheneOS domain isn't.
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