Your phone is about to stop being yours

Original Article ↗ Hacker News Discussion ↗

Google’s plan to require all Android apps to be tied to verified developers — with ID checks, fees, and a new sideloading flow controlled by Google Play Services — is seen by many as a major step toward locking down what was once marketed as an open platform. Supporters frame the change as necessary to combat rampant banking and phishing malware, including scams that pressure victims to install malicious APKs, while critics argue it will chill FOSS development, weaken alternatives like F-Droid, and centralize even more power over software distribution. Much of the debate centers on whether a one‑time, 24‑hour “advanced” opt‑out and custom ROMs like GrapheneOS are meaningful safeguards, or just temporary escape hatches as phones evolve into tightly controlled “cloud terminals.”

Overview of Google’s New Restrictions

  • New “developer verification” will require most Android app developers to register with Google, pay a fee, provide ID, and list app IDs.
  • Sideloading from settings will require a multi-step “advanced flow” with a mandatory ~24h delay and scary warnings; flow is controlled by Google Play Services, not the OS.
  • ADB installs and alternative ROMs without Google Play Services are expected to keep working, but ecosystem effects are a major concern.

Security Rationale vs Freedom / Ownership

  • Pro-change side:
    • Argues this targets real banking malware and social‑engineering scams (especially in parts of Asia) where victims are pressured to sideload “official” apps that drain bank accounts.
    • Sees 24h cooldown as a way to break urgency‑based scams, and ID verification as needed accountability.
  • Anti-change side:
    • Sees this as centralization and a power grab dressed as security, especially given ongoing malware in Play Store itself.
    • Emphasizes that phones already show strong warnings; prefers education over gatekeeping.
    • Slippery‑slope fear: once Google can silently tighten rules via Play Services, they can later ban disfavored apps or OSes.

Impact on Developers and FOSS Ecosystem

  • Concern that requiring ID and a Google relationship will chill hobby projects, anonymous devs, small FOSS apps, and third‑party stores like F‑Droid.
  • Others say serious developers will just pay and verify; only “political” or fringe devs are affected.
  • Worry that if users don’t bother with the advanced flow, F‑Droid and similar ecosystems will lose reach and contributions.

Workarounds and Practicality

  • “Advanced flow” is described as one‑time per device, not per app, but still seen as enough friction to deter non‑experts.
  • ADB is widely cited as a permanent bypass, but many argue “use ADB” is unrealistic for most users and not equivalent to a normal install.
  • Unclear whether existing unverified apps will be removed or just blocked from updating; docs suggest updates will be blocked.

Comparisons: iOS, PCs, Consoles

  • Many note Android is becoming more like iOS (notarization, developer IDs, cooling‑off flows), though still somewhat more open (unlimited ADB installs, bootloader unlock on some devices).
  • Historical parallels drawn to Windows driver signing, browser extension signing, game consoles, and earlier Microsoft lock‑in attempts.
  • Some argue PCs are the historical exception; most consumer devices have always been closed appliances.

Alternative OSes and Hardware Lockdown

  • GrapheneOS, LineageOS, /e/OS, postmarketOS, Librem 5, PinePhone, Jolla, etc. are discussed as escape hatches, but:
    • Hardware support is narrow (e.g., GrapheneOS mainly on Pixels now, maybe some Motorolas later).
    • Many phones have non‑unlockable bootloaders; even unlockable ones often depend on proprietary blobs.
  • Some say the “real fight” is:
    • Legally mandating unlockable/relockable bootloaders and custom keys.
    • Banning app‑level discrimination against non‑vendor OSes (Play Integrity, etc.).

Banking, Government Services, and Everyday Dependence

  • In many countries (especially parts of Europe and elsewhere), banking, government login, payments, transit, and online shopping increasingly require official apps and sometimes high Play Integrity scores.
  • Custom ROM and Linux‑phone users already face broken banking apps; people fear this change plus attestation will eventually lock out alternatives entirely.
  • Some accept carrying a second, stock device for banking; others see that as unsustainable or a de facto coercion.

Regulation & Antitrust Views

  • Several argue this conflicts with the EU Digital Markets Act or should trigger antitrust action (abuse of gatekeeper status, self‑preferencing Play Store).
  • Others think current DMA loopholes and regulators’ focus on business, not end‑user freedom, mean it will likely stand unless laws are revised.

Overall Sentiment

  • Thread is sharply split:
    • One camp sees a necessary, imperfect security measure that still leaves enough room for power users.
    • Another sees a key step in the long‑running erosion of general‑purpose computing and user control, with serious long‑term ecosystem risks.