DeGoogle Yourself

8799 readers

1 users here now

A community for those that would like to get away from Google.

Here you may post anything related to DeGoogling, why we should do it or good software alternatives!

Rules

Be respectful even in disagreement
No advertising unless it is very relevent and justified. Do not do this excessively.
No low value posts / memes. We or you need to learn, or discuss something.

Related communities

[email protected] [email protected] [email protected] [email protected] [email protected] [email protected]

founded 4 years ago

MODERATORS

[email protected]

Who owns your shiny new Pixel 9 phone? You can’t say no to Google’s surveillance (cybernews.com)

submitted 1 month ago by [email protected] to c/[email protected]

105 comments fedilink hide all child comments

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 are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 0 points 1 month ago* (last edited 1 month ago) (1 children)

Just about all of your identifying data is stripped out by the framework before interacting with Google at all: https://github.com/microg/GmsCore/wiki/Google-Network-Connections

That alone makes it an important tool. I'm not too worried about memory exploits as I don't really install apps, but it's an important feature in graphene's toolkit.

For most people who want an Android alternative that's open source but don't have time to fiddle with it, calyxOS seems like a good solution. It just works out of the box.

[–] [email protected] 0 points 1 month ago (1 children)

Just about all of your identifying data is stripped out by the framework before interacting with Google at all

For all of them, we strip device identifier (MAC addresses, IMEI, etc)

This is literally nothing special, as all user-installed apps are denied access to identifiers like the IMEI and MAC address since Android 10. Since GrapheneOS isolates Play services in the Android application sandbox, they don't have access to any of these identifiers either.

I’m not too worried about memory exploits as I don’t really install apps

That's not how memory corruption exploits work. These can occur anywhere in the system, and just need to be triggered by an attacker. This doesn't require you to install an app, receiving a rogue message might for example be enough to exploit a memory vulnerability in the SMS app. Visiting a rogue website, which loads malicious JavaScript can be enough to trigger a memory corruption vulnerability in the Chromium WebView. That's why GrapheneOS doesn't just use hardened_malloc, but it also disables the JavaScript JIT compiler in Vanadium by default, and offers a toggle in the settings to disallow JavaScript JIT compilation in all apps making use of the system WebView component.

[–] [email protected] 0 points 1 month ago* (last edited 1 month ago) (1 children)

Very nice. Can I use the much smaller codebase of microG instead of Google's? Even you do not know how Play Services actually works, and that's a problem.

Further, a memory exploit that leads to compromise would need a chain of privilege escalation. There's a lot in the way of making that trivial even on stock Android. And you know what helps reduce risk of exploit? Smaller codebases.

[–] [email protected] 0 points 1 month ago (1 children)

If you only care about security, you should keep Play Services isolated in a separate profile. That way, even if there happens to be a memory corruption vulnerability in Play services, which isn't caught by hardened_malloc or the hardware MTE in newer devices with ARMv9 chips, the rest of your system would still be safe, since Play services aren't running as root, and in order to compromise the entire system, there would need to be a privilege escalation vulnerability in all of Android, not just Play services.

And you know what helps reduce risk of exploit? Smaller codebases.

Why does CalyxOS include the F-Droid privileged extension then? It's yet another component running with elevated permissions and unnecessarily increasing attack surface. Why does it include Google's eUICC component with elevated privileges and no proper sandboxing?

[–] [email protected] 0 points 1 month ago* (last edited 1 month ago)

Err... That component appears to be built from source per Calyx's Gradle rules? The source is pulled from here: https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/telephony/java/android/telephony/euicc

My hardware is too old to support MTE. I'm running a pixel 3 because I'm more worried about damaging our earthly environment with this constant hardware churn.

I'm sorry you're unhappy that I'm happy. I'm still able to run Android 14 in a reasonably secure manner, I'm able to exchange information with other people easily, without Google getting much information from me, and that's satisfactory. My actual security relevant machinations happen on my much better protected laptop.

Thanks for your input, have a nice day.