Google’s latest flagship smartphone raises concerns about user privacy and security. It frequently transmits private user data to the tech giant before any app is installed. Moreover, the Cybernews research team has discovered that it potentially has remote management capabilities without user awareness or approval.
Cybernews researchers analyzed the new Pixel 9 Pro XL smartphone’s web traffic, focusing on what a new smartphone sends to Google.
“Every 15 minutes, Google Pixel 9 Pro XL sends a data packet to Google. The device shares location, email address, phone number, network status, and other telemetry. Even more concerning, the phone periodically attempts to download and run new code, potentially opening up security risks,” said Aras Nazarovas, a security researcher at Cybernews…
… “The amount of data transmitted and the potential for remote management casts doubt on who truly owns the device. Users may have paid for it, but the deep integration of surveillance systems in the ecosystem may leave users vulnerable to privacy violations,” Nazarovas said…
You can’t say no to Google’s surveillance
Yes you can: https://grapheneos.org/
I was just wondering earlier today if Google kept the bootloader open to allow custom OS installation only because they had other hardware on the phone that would send them their information anyways, possibly through covert side channels.
Like they could add listeners for cell signals that pick up data encoded in the lower bits of timestamps attached to packets, which would be very difficult to detect (like I’m having trouble thinking of a way to determine if that’s happening even if you knew to look for it).
Or maybe there’s a sleeper code that can be sent to “wake up” the phone’s secret circuitry and send bulk data when Google decides they want something specific (since encoding in timestamps would be pretty low bandwidth), which would make detection by traffic analysis more difficult, since most of the time it isn’t sending anything at all.
This is just speculation, but I’ve picked up on a pattern of speculating that something is technically possible, assuming there’s no way they’d actually be doing that, and later finding out that it was actually underestimating what they were doing.
I don’t mean to discredit your opinion, but it is pure speculation and falls in the category of conspiracy theories. There are plenty of compelling arguments, why this is likely completely wrong:
- Google Pixels have less than 1% of the global smartphone market share, in fact, they are currently only sold in
12(the Pixel 9 is sold in 32 countries, my bad, I had an outdated number in mind) countries around the world. Do you really think that Google would spend all the money in research, custom manufacturing, software development and maintenance to extract this tiny bit of data from a relatively small number of users? I’d say more than 90% of Pixel owners use the Stock OS anyways, so it really doesn’t matter. And Google has access to all the user data on around 70% of all the smartphones in the world through their rootkits (Google Play services and framework, which are installed as system apps and granted special privileges), which lets them collect far more data than they ever could from Pixel users. - Keeping this a secret would also immensely difficult and require even more resources, making this even less profitable. Employees leave the company all the time, after which they might just leak the story to the press, or the company could get hacked and internal records published on the internet. Since this would also require hardware modifications, it’s also likely that it would get discovered when taking apart and analyzing the device. PCB schematics also get leaked all the time, including popular devices like several generations of iPhones and MacBooks.
- Lastly, the image damage would be insane, if this ever got leaked to the public. No one would ever buy any Google devices, if it was proven that they actually contain hardware backdoors that are used to exfiltrate data.
You’re right that it’s pure speculation just based on technical possibilities and I hope you’re right to think it should be dismissed.
But with the way microchip design (it wouldn’t be at the PCB level, it would be hidden inside the SoC) and manufacturing work, I think it’s possible for a small number of people to make this happen, maybe even a single technical actor on the right team. Chips are typically designed with a lot of diagnostic circuitry that could be used to access arbitrary data on the chip, where the only secret part is, say, a bridge from the cell signal to that diagnostic bus. The rest would be designed and validated by teams thinking it’s perfectly normal (and it is, other than leaving an open pathway to it).
Then if you have access to arbitrary registers or memory on the chip, you can use that to write arbitrary firmware for one of the many microprocessors on the SoC (which isn’t just the main CPU cores someone might notice has woken up and is running code that came from nowhere), and then write to its program counter to make it run that code, which can then do whatever that MP is capable of.
I don’t think it would be feasible for mass surveillance, because that would take infrastructure that would require a team that understands what’s going on to build, run, and maintain.
But it could be used for smaller scale surveillance, like targeted at specific individuals.
But yeah, this is just speculation based on what’s technically possible and the only reason I’m giving it serious thought is because I once thought that it was technically possible for apps to listen in on your mic, feed it into a text to speech algorithm, and send it back home, hidden among other normal packets, but they probably aren’t doing it. But then I’d hear so many stories about uncanny ads that pop up about a discussion in the presence of the phone and more recently it came out that FB was doing that. So I wouldn’t put it past them to actually do something like this.
I know this isn’t the topic here, but I really wish these researchers would unroll what all Apple harvests from Apple devices. It’s quite a lot as well. Could help pop that “we’re so private” myth.
So what phones do you all have?
Is there a noticeable performance and/or battery life improvement when phone is on GOS?
In my experience, no. Since Google doesn’t apply any battery optimizations in their stock OS, apart from those already present in AOSP, it makes sense that battery life is essentially the same in GrapheneOS.
Installing GrapheneOS removes all the Google crap.
What is the advantage over Calyx/Lineage/iode OS on compatible devices? I just don’t want Google to have any of my money at all. Buying a privacy solution from them recoups their loss.
Can’t speak to what others are saying about Graphene but Calyx is amazing if you prefer a FOSS-centric option but still want GMS/GSF compatibility. Bootloader relocking is a requirement for their devices.
Calyx doesn’t actually support Google Play Services or Google Services Framework. It uses microG, a sometimes buggy workaround that requires root access and has pretty poor compatibility. GrapheneOS on the other hand uses the official Google Play binaries, but isolates them in the Android application sandbox, instead of installing them as system apps with special privileges (like it is the case on stock Android). You can read more about it at https://grapheneos.org/features#sandboxed-google-play
I don’t know about Calyx or Iode but Lineage doesn’t allow for a locked bootloader. This is a massive security hole and without security, sooner or later, your privacy will be violated.
Currently, GrapheneOS on a newer Pixel are the only phones that Celebrite can’t breach. Celebrite machines are cheap enough that the border guards and your local cops probably have one. In my country, it’s the law that a cop is allowed to examine a phone during a traffic stop.
Mainly the locked bootloader that GrapheneOS offers. It’s more secure, and GrapheneOS emphasizes security over all else, but privacy features are part of that security.
I like calyx, might try graphene some day. But I absolutely won’t run Google’s play services ala graphene. It’s sandboxed, supposedly, but why run it at all?
Calyx uses microG, a much smaller, fully open source emulator of Google’s services.
but why run it at all?
Because it is unfortunately required by some apps. microG is not a viable alternative, as it requires root access on the device, which drastically reduces the security. It also has worse compatibility than Sandboxed Play services, and doesn’t offer much of a benefit. It still downloads and executes proprietary Google blobs in the background in order to function. Apps that require Google services also include a proprietary Google library, making microG essentially useless. It’s an open source layer that sits between a proprietary library and a proprietary network service, using proprietary binaries and requiring root access. You gain absolutely nothing from using it, and significantly increase the attack surface of your device.
fully open source emulator
This is simply false, as I explained, only a tiny bit of what microG requires to function is open source
You’re far better off using Sandboxed Play services on GrapheneOS
@RubberElectrons @multi_regime_enjoyer its not actually fully open source, it uses a lot of closed-source libraries, and its not as battle-tested as google’s official one so there really isn’t a reason to use it
GrapheneOS
Do they have passkeys yet
Edit: passkeys support. Last year when I checked they didn’t support pass keys yet.
Yes, @oranki@lemmy.world wrote a great article about that: https://oranki.net/posts/2024-07-10-passkeys-on-grapheneos/
Thank you! Idk why I was down voted, I appreciate it. I did a bunch of research on grapheneos last year around this time and it wasn’t supported yet.
What does that even mean? It’s not the function of an OS to have passkeys.
Grapheneos didn’t support pass keys last year when I checked, so you couldn’t use them at all. There was some APIs broken/missing between the OS to browser comms so you couldn’t use 3rd party apps for pass keys, like proton or bit warden. I have been actively experimenting and adopting passkeys and didn’t want to revert. It sounds like there is support now though, so I will give it a try soon.