Google details new 24-hour process to sideload unverified Android apps

Original Article ↗ Hacker News Discussion ↗

Google’s new Android policy will require users to enable developer mode, click through warnings, and wait 24 hours once before they can install “unverified” apps outside the Play Store, while also rolling out mandatory identity verification for most developers who want broad distribution. Supporters see this as a reasonable way to slow down scams that rely on coaching victims through sideloading, but many argue there’s little real-world evidence of such attacks and view the move as security theater aimed at locking in Google’s app-store monopoly and enforcing sanctions. The change is widely expected to hurt open-source and alternative app store ecosystems like F-Droid, push more technical users toward de-Googled Android variants such as GrapheneOS, and further erode the idea that users fully control the software on their own devices.

Overview of the new process

  • To install apps whose signatures aren’t registered with Google, users must:
    • Enable Developer Options.
    • Go through an “advanced flow” with warnings, a device restart, and biometric/PIN auth.
    • Wait a one‑time 24‑hour “protective” delay before enabling installs.
    • Then choose to allow such installs for 7 days or indefinitely.
  • ADB installs are exempt from the 24‑hour delay.
  • Clarifications in-thread:
    • The advanced flow appears to be one‑time per device, not per app.
    • Developer Options can be turned off after enabling the flow.
    • A Google account is not required; device authentication is via PIN/biometrics.

Security rationale and scam debate

  • Google frames this as protection against “coached” or coerced sideloading, especially for banking/identity theft scams.
  • Some commenters see this as a reasonable compromise that may disrupt urgency‑based scams by forcing a cooling‑off period.
  • Many are skeptical:
    • Scammers already spend days or weeks grooming victims and can just “call back tomorrow”.
    • Most reported scams in multiple countries rely on social engineering, official apps, web phishing, or remote control tools, not sideloaded malware.
    • Google Play itself is described as full of scammy or intrusive apps, weakening the “safety” justification.

Impact on F-Droid, independent devs, and open source

  • Strong concern that extra friction will:
    • Reduce adoption of apps from F-Droid and similar stores.
    • Shrink user bases for projects like NewPipe, Obtainium, and other non‑Play apps.
  • Separate but related: mandatory developer verification and government‑ID requirements for broader distribution are seen as:
    • Hostile to anonymous or pseudonymous FOSS developers.
    • Giving Google leverage to de‑platform apps that hurt its business (e.g., ad‑blocking YouTube front‑ends).
  • Hobbyist “limited distribution” accounts (up to 20 devices, no ID) are viewed as inadequate for large FOSS ecosystems.

User autonomy, ownership, and “walled gardens”

  • Very strong theme: this is viewed as another step toward an iOS‑style locked platform and “tech feudalism”.
  • Many argue that on a device they own, they should install whatever they want without delays or identity checks.
  • Others counter that most users are non‑technical; prioritizing their safety over power‑user convenience is acceptable.

ADB, developer mode, and banking apps

  • ADB is repeatedly mentioned as a workaround, but:
    • Many see “connect to a PC and use a CLI” as unrealistic for normal users.
  • Requiring Developer Mode to enable the flow is problematic because:
    • Some banking, payment, and government apps in multiple countries refuse to run if Developer Mode is on.
  • It’s clarified that Developer Mode need not remain enabled after enabling the advanced flow, but some worry apps may detect the advanced-flow state itself in the future (unclear).

Regulatory and competition concerns

  • Many call the change anti‑competitive:
    • It imposes extra friction specifically on competing app stores and independently distributed apps.
    • F-Droid and similar projects must either submit to Google’s verification (including ID) or accept being second‑class.
  • Several commenters hope EU and other regulators will intervene; others are pessimistic, arguing regulators also benefit from centralized control.

Alternatives and migration

  • Repeated suggestions to:
    • Move to GrapheneOS or other AOSP‑based ROMs, which are not bound by Google Play rules (though banking/Play Integrity issues remain).
    • Consider SailfishOS, Linux‑based phones, or even “dumbphone + separate small computer” setups.
  • Some say if Android becomes a de facto walled garden, they might as well switch to iOS; others insist that’s just trading one cage for another.

Language and framing

  • Several object to the term “sideloading” itself:
    • Argue it pathologizes “installing software” and normalizes corporate gatekeeping.
    • See it as part of a broader “newspeak” that paints user control as inherently suspect.