GrapheneOS – Break Free from Google and Apple

Original Article ↗ Hacker News Discussion ↗

Banking, Payments & App Compatibility

  • Biggest practical friction: some banking and payment apps rely on Google’s Play Integrity / attestation and refuse to run on GrapheneOS, even with sandboxed Play installed.
  • Many users report all their banks working (often after enabling “exploit protection compatibility mode” or relocking the bootloader); others hit hard failures with specific banks or corporate banking apps.
  • Google Pay generally doesn’t work; alternatives like Curve or bank‑specific NFC apps sometimes do. QR-based payments are a workaround in some countries, but there’s debate over their reliability and convenience (need for internet, slower UX vs NFC).
  • Several users successfully lobbied banks to whitelist GrapheneOS keys or fix over‑strict checks. Lists of compatible banking apps are maintained and frequently referenced.
  • Some ride‑hailing and other “platform” apps occasionally misbehave or ban accounts, but others work fine; many see this as a problem with the services rather than GrapheneOS.

Google Play, Attestation & Dependence on Google

  • Sandboxed Google Play is a core feature: Play Services and the Play Store run as ordinary, permission‑bound apps instead of privileged system components. Supporters call this strictly better than stock Android and better than microG, which still talks to Google.
  • Critics argue needing any Google component undermines the “break free” narrative and prefer microG or no Google at all; others respond that sandboxing meaningfully limits data access and is opt‑in.
  • GrapheneOS leans on Android’s hardware attestation for compatibility with some high‑security apps; this still depends on Google’s infrastructure and Pixel hardware, which some see as a strategic risk.

Device Support, Hardware & Future OEM Plans

  • Only recent Pixels are officially supported due to strict requirements: secure boot, IOMMU‑isolated baseband and radios, separate secure enclave, timely firmware/kernel/SoC patches, long update windows.
  • Many commenters dislike the dependence on Google hardware, but others note Pixels are uniquely bootloader‑unlockable, easy to recover, and relatively well‑secured. Buying used Pixels is suggested to avoid funding Google directly.
  • A partnership with a large Android OEM has been announced: public reveal in 2026, devices meeting GrapheneOS requirements planned for 2027, aiming to reduce Pixel dependence and potentially offer more form factor options (and, for some, better displays/PWM characteristics).

Comparisons to /e/OS, LineageOS, Linux Phones & Community Conflict

  • GrapheneOS is repeatedly contrasted with /e/OS, iodéOS and LineageOS. Pro‑GrapheneOS voices claim:
    • It preserves and extends AOSP’s privacy and security model, ships far more exploit mitigations, and patches faster and more completely.
    • Competitors lag on Android, kernel, firmware, and WebView updates, mis‑set patch levels, and sometimes weaken security (e.g., unlocked bootloaders, test keys, privileged Google components).
  • Supporters of other ROMs prioritize de‑Googling, open cloud services and user “freedom” (root, XPrivacy‑style hooks, desktop‑like hackability) over maximum hardening.
  • There is clear long‑standing drama: accusations of “toxic” behavior, misleading marketing, harassment and even swatting against the GrapheneOS team from other communities; GrapheneOS replies with detailed technical and ethical criticisms of those projects.

Security Model, Threats & Baseband Limitations

  • GrapheneOS adds hardened_malloc, extensive exploit mitigations, memory tagging (on newer Pixels), strict app sandboxing, fine‑grained permissions (Contact/Storage Scopes, Sensors and Network toggles), and fast patch adoption.
  • Commenters generally agree this significantly raises the bar for commercial spyware and casual attackers; GrapheneOS cites evidence that it withstands commodity forensic tools better than stock systems.
  • Skeptics note persistent risk from proprietary baseband and firmware blobs; even with IOMMU isolation, a well‑funded actor might still compromise the device via cellular or radio layers. GrapheneOS acknowledges it cannot fully solve this, and urges realistic threat modelling (journalists, activists vs typical users).

Usability, Daily Driving & FOSS App Ecosystem

  • Many long‑term users report using GrapheneOS as a full daily driver for years with minimal friction once initial setup is done.
  • Android Auto, Quick Share, Pixel Camera (via Play, plus shims for photo previews), NFC YubiKey, RCS (with some carrier‑specific tweaks), and most media, transport, and government apps can work.
  • Major feature praised: per‑app network and sensor blocking, and scoped access to contacts and storage; this changes how people install and trust apps.
  • A large FOSS app stack is actively shared (NewPipe, OrganicMaps/CoMaps, KeePassDX, DAVx⁵, GadgetBridge, Termux, etc.). There’s disagreement over F‑Droid: GrapheneOS warns about its lagging updates and insecure build pipeline; others value its convenience and openness.

Philosophical Tensions: Privacy vs Security vs Freedom

  • One recurring debate:
    • GrapheneOS frames itself as a privacy project where privacy depends on strong security; it is explicitly not about user‑root freedom.
    • Some users argue true privacy also requires freedom to inspect, spoof, or block tracking at the app‑code level (root, system hooks, deep browser hardening).
  • Others warn against “enumerating badness” (DNS blocklists, patched tracking SDKs) as fragile and bypassable, preferring GrapheneOS’s model of simply not granting data in the first place.
  • There is concern that hardware attestation and app lock‑outs (banking, government, Wero, etc.) could lead to a future where only locked, vendor‑approved OSes can access essential services; several commenters see this as a regulatory and political problem beyond any one ROM.