F-Droid and Google’s developer registration decree

Original Article ↗ Hacker News Discussion ↗

Impact on F‑Droid and Android Ecosystem

  • The new Google developer registration and app‑ID control is widely seen as an existential threat to F‑Droid and similar third‑party stores.
  • F‑Droid refuses to “take over” package IDs for other people’s apps (would effectively seize distribution rights), but Google’s model assumes a DNS‑like central authority for IDs and intents.
  • Centralizing registration under Google is viewed as giving it a kill‑switch over all apps on “certified” devices, even those installed from other stores.
  • Some argue the “least‑bad” path for F‑Droid might be renaming app IDs or owning keys, but this conflicts with FOSS norms and worsens centralization.

Security, Abuse, and Google’s Stated Rationale

  • Supporters frame the change as anti‑malware and anti‑scam: less tricking non‑technical users into sideloading malicious APKs; developer traceability raises the bar for criminals.
  • Critics counter that Play Store itself is full of scams, abusive subscriptions, and shady apps, while F‑Droid’s curated, source‑built model has a much better track record.
  • There’s pushback on the idea that anonymous distribution is “unnecessary”; others say hobbyist freedom is being sacrificed to “safety theater.”

Regulation, Age Verification, and Attestation

  • Several comments tie this to broader regulatory trends: EU digital identity, age verification, Australia’s online safety codes, and device attestation (SafetyNet/Play Integrity).
  • Fear that governments will increasingly require “certified” devices and OSes for banking, IDs, transit, and age‑gated content, effectively banning user‑administered systems from daily life.
  • Some see Google and Apple lobbying to turn such rules into de‑facto platform lock‑in (regulatory capture).

Licensing and Signing‑Key Complications

  • GPLv3’s “installation information” clause is debated: does a Google‑controlled key system break the requirement that users be able to install modified versions?
  • Reproducible builds and developer‑held keys are suggested as a partial escape hatch, but many apps don’t have reproducible builds yet.
  • Concerns about Google requiring app signing keys or proofs of key ownership even for out‑of‑store distribution.

Alternatives: Custom ROMs and Linux Phones

  • Many mention LineageOS, GrapheneOS, /e/OS, Ubuntu Touch, postmarketOS, Librem 5, Fairphone, PinePhone, Shift, Volla, etc. as escape routes.
  • However, banking/government apps and attestation often block these systems, forcing dual‑phone setups or web‑only banking.
  • Linux phones are praised for freedom but criticized for price, hardware limitations, app gaps, and reliability (e.g., emergency calling).

User Strategies and Tradeoffs

  • Some already live Play‑free using F‑Droid, microG, Aurora Store, and manual APK downloads; others plan to move to GrapheneOS or even iOS as “the nicer walled garden.”
  • A recurring tactic: keep a locked, “official” phone for banking/ID and a second, open device for everything else.
  • Non‑technical family members are seen as effectively locked into Apple/Google because alternative setups are too complex.

Broader Fears: War on General‑Purpose Computing

  • Many frame this as part of a “war on general computing”: secure boot, remote attestation, locked bootloaders, app notarization, and mandatory IDs converging into “digital techno‑feudalism.”
  • Phones are increasingly treated as ad‑driven appliances rather than personal computers; some choose to minimize phone use or revert to dumbphones.
  • Others stress that general‑purpose computing still survives on PCs and servers, but worry the same mechanisms will be applied there next.