The Twenty-Four Hour Lock
Google’s new Android sideloading policy is brilliantly patronizing.
Starting August 2026, if you want to install an app from an unverified developer — meaning someone who hasn’t registered with Google’s Play Integrity system — you’ll need to complete a multi-step process that includes a mandatory 24-hour waiting period.
The actual steps take seconds. Tap a setting. Confirm your identity. Then wait. A full day. Only after 24 hours can you tap “Install anyway” in the package manager.
651 points on Hacker News. 723 comments. The developer community has feelings.
The Logic
The design is borrowed from gun purchase waiting periods: if someone is being socially engineered — a phone scam telling them to install an APK right now — the 24-hour delay breaks the urgency. The attacker can’t maintain pressure for a full day. The victim has time to think, ask someone, realize it’s a scam.
Google frames this as a compromise. The EU’s Digital Markets Act requires that Android allow sideloading. Google can’t block it entirely. But they can add friction. And friction, applied correctly, is a security feature.
The parallel to AI safety is instructive.
Friction as Design
The AI industry is having exactly this debate: how much friction should exist between an AI agent and dangerous actions?
Most AI safety proposals involve some form of the 24-hour lock. Human-in-the-loop approval. Confirmation dialogs. Waiting periods before irreversible operations. The theory is identical: if a model is being jailbroken or a user is being socially engineered into giving an agent destructive permissions, a mandatory pause creates space for reflection.
The problem is also identical: power users hate it. Developers who sideload daily — for testing, for open source apps, for apps that Google doesn’t approve — will go through this ritual once and then leave the setting permanently enabled. The friction becomes meaningless to the people who know what they’re doing and maximum friction for the people being protected.
This is the fundamental paradox of graduated permissions. The users who need the protection are the ones who don’t understand the setting. The users who toggle it on immediately are the ones who don’t need it.
What 723 Comments Tell You
The Hacker News thread split exactly as you’d expect:
Camp 1: “This is reasonable for 99% of users who don’t know what sideloading is and are being scammed into installing malware.”
Camp 2: “This is my device. I should be able to install whatever I want without asking Google for permission.”
Camp 3: “Google is using ‘safety’ as a Trojan horse to maintain Play Store monopoly revenue.”
All three are simultaneously correct. That’s what makes platform policy interesting.
The 24-hour lock is safety theater and genuine protection. It’s user empowerment and platform control. It’s a compromise mandated by regulation and a feature designed to minimize the regulation’s impact.
Google didn’t invent this tension. They just built a timer around it.
The Deeper Pattern
Every platform eventually faces this choice: open and dangerous, or closed and safe. The answer is always “graduated friction” — let people do the dangerous thing, but make them work for it.
Root access requires developer mode. Admin privileges require password entry. Self-hosted AI agents require config files and CLI commands.
The 24-hour lock is the same pattern pushed to its logical extreme. You can sideload. But you have to want it badly enough to wait a full day.
It’s the “are you sure?” dialog, stretched across time. And surprisingly, it works. Most scam victims won’t call back tomorrow. Most impulse decisions don’t survive the night.
Whether that justifies the paternalism is a different question. One that 723 commenters are still arguing about.
Google adds a 24-hour timer to Android sideloading. The logic: if you still want to install it tomorrow, you probably meant it. If you don’t, you were probably being scammed. Patronizing, yes. Effective, probably.