Introduction to GrapheneOS

Original Article ↗ Hacker News Discussion ↗

Root Access vs Security Model

  • Large subthread debates why GrapheneOS (GOS) refuses app‑level root.
  • Pro‑root side: wants a “Qubes‑like” escape hatch, argues Android’s permission UI plus re‑authentication should be enough, and that users should be trusted to grant root wisely.
  • GOS side: UI‑grantable root effectively gives root to the whole UI stack (system UI, keyboard, accessibility services), making choicejacking/tapjacking enough for persistent, undetectable compromise and breaking verified boot’s threat model.
  • Consensus from GOS proponents: root via ADB/userdebug builds is already a security regression; app‑accessible root is much worse and undermines Android’s least‑privilege design.

GrapheneOS vs Other OSes (Qubes, Lineage, /e/, Librem)

  • QubesOS is praised for VM‑level compartmentalization but described as focusing on containing already‑compromised guests, not hardening them; GOS aims to prevent exploitation within each “guest” (app/OS) in the first place.
  • Some accuse GOS of dismissing alternative threat models (e.g., Librem 5); GOS responses emphasize missing firmware updates, insecure components, and closed firmware as deal‑breakers.
  • LineageOS and /e/ are criticized for lagging months/years on security patches and integrating Google‑related or other telemetry with elevated privileges; defenders counter they’re more usable and “good enough” for many users.
  • Waydroid and Linux‑phone options are mentioned but seen as far from offering comparable security models.

Pixel Hardware and Google Dependency

  • Concern that GOS only supports Pixels, requiring buying Google hardware to “de‑Google.”
  • GOS argues Pixels are currently the only phones meeting strict hardware/firmware and long‑support requirements; they report ongoing talks with a major OEM to add non‑Pixel devices.
  • No irreversible “Knox‑style” fuse exists on Pixels; users can relock bootloaders and return to stock, though attestation keys and eFuses for rollback exist.

Profiles, Work Profiles, and Usability

  • Mixed experiences: some find user profiles and Private Space extremely useful for isolating TikTok, Meta apps, work, or Google‑dependent apps, combined with per‑profile VPNs and notification forwarding.
  • Others find secondary profiles clunky (separate setup, difficult file‑sharing, context switches), nearly equivalent to carrying two phones.
  • GOS emphasizes these are standard Android features they lightly enhance, not central to their model; most GOS benefits do not require multiple profiles.

Sandboxed Google Play and “Why Use Google on GOS?”

  • Several comments ask why one would install Google services on a privacy OS.
  • Explanation: on GOS, Play Services/Store are ordinary sandboxed apps with no special privileges; permissions (including Location, Contacts) can be withheld or scoped.
  • Many apps won’t run without Play APIs; GOS provides a compatibility layer that reroutes some APIs (e.g., location) to OS implementations and encourages putting Play in a dedicated profile if stronger separation is desired.
  • microG is discussed as an alternative; critics note it still talks to Google for push and accounts and often runs with higher privileges than Play on GOS.

App Compatibility: Banking, RCS, Tap‑to‑Pay, Call Recording

  • Banking: majority of banking apps reportedly work; ~10% block non‑certified OSes via Play Integrity. Some banks have explicitly whitelisted GOS via hardware attestation.
  • Google Pay tap‑to‑pay does not work due to lack of Google certification; regional alternatives (Curve, PayPal, bank apps) work in parts of Europe.
  • RCS: currently unreliable on GOS; official support via Google Messages is in progress; a long‑term goal is an independent RCS client.
  • Automatic call recording is missing; some users see this as a deal‑breaker. GOS insists any implementation must visibly indicate active recording to avoid silent always‑on logging.

Community, Governance, and Drama

  • Some commenters perceive the GOS project and parts of its community as dogmatic or hostile toward other ROMs and app stores; others counter that this is overblown and rooted in disagreements over threat models and update hygiene.
  • A separate thread discusses a critical YouTube video about the lead developer and claims of “mental issues”; GOS supporters frame it as harassment based on fabrications and emphasize the project’s foundation structure and multiple directors.
  • GOS insists technical design and patch quality—not personalities—should be the main basis for evaluation.

Practical Experiences and Tips

  • Multiple users report easy web‑based installation, good battery life, and a “just unbloated Android” feel.
  • Suggested usage patterns:
    • Minimal‑apps approach using only FOSS via F‑Droid/other stores, no Play.
    • Single profile with sandboxed Play for convenience.
    • Multi‑profile setup: one for Play‑dependent/“toxic” apps, another for personal or sensitive use, each with its own VPN.
  • Some concern about future Android changes to sideloading; GOS notes those apply only to certified OSes, which GOS is not.