Delayed Security Patches for AOSP (Android Open Source Project)
Scope and Misinterpretation of the Issue
- Multiple comments note the HN title is wrong: patches are not “delayed for AOSP” specifically.
- Security backports for Android 13/14/15 were pushed to AOSP on Sept 2 as usual.
- What is delayed are:
- Monthly/QPR Android releases (e.g. Android 16 QPR1 not tagged in AOSP on time).
- The overall public disclosure timeline for Android security fixes, affecting Pixels and OEM builds as well as AOSP.
New Security Update / Embargo Model
- Google is shifting from mostly monthly to mostly quarterly security updates.
- OEMs now reportedly get 3–4 months of early access to patches instead of ~1 month.
- Commenters claim these partner bulletins are widely leaked, including to attackers, making the long embargo harmful rather than protective.
- Google added an exception allowing binary‑only security fixes before source is released, but:
- Critics argue this is pointless because patches are easily reverse‑engineered.
- It creates an incentive to ship opaque fixes and further erodes transparency.
- GrapheneOS (via an OEM partner) already has early access, but is constrained by embargo rules and rejects the idea of a special binary‑only “preview” branch.
Security Posture: Android vs iOS and Linux
- Some argue Pixel/Android used to be roughly competitive with iOS on security, but Google’s new policies and partner‑driven compromises are eroding that.
- Criticism extends to the Linux kernel and Android security process as “understaffed” and mismanaged despite Google doing a lot of upstream security work.
- Apple is seen as having different problems but not this level of self‑inflicted delay.
Google’s Control, Antitrust, and Open Source Strategy
- Strong sentiment that Google is degrading “open Android”:
- Migrating key components into proprietary Google Mobile Services and apps.
- Using security and Play Integrity as levers to enforce licensing and ecosystem control.
- Several call for antitrust remedies: splitting Android and/or Chrome from Google, or moving them to independent nonprofits.
- Others worry that:
- New owners might be even more exploitative.
- Fragmentation could weaken security and leave Apple with de facto monopoly power.
Browsers as a Parallel Case
- Discussion connects Android’s trajectory to Chromium:
- Fear that privacy/ad‑blocking forks are ultimately at Google’s mercy.
- Suggestion that Firefox/Gecko should be the basis for forks, with more community‑aligned governance.
- Concern that Firefox’s dependence on Google search revenue is unstable; some think better governance or a new steward may be needed.
Alternatives and Fragmentation
- Linux phones (postmarketOS, PinePhone, etc.) are viewed as promising but far from Android’s app ecosystem and security model.
- Some suggest a consortium of Android OEMs collaboratively steering AOSP, but:
- Today most vendors focus on their own skins, stores, and partial forks (Huawei, Samsung, etc.).
- There is skepticism that multiple slightly incompatible ecosystems are viable for app developers.
Desire for Simpler, More Secure Devices
- A thread explores “simple, secure phones” with minimal features:
- One side argues lower complexity would ease community maintenance and reduce attack surface.
- The other points to economics: serious security (patch cadence, secure hardware) is expensive and hard to sustain for niche devices.
- Examples like Raspberry Pi, Flipper Zero, and OpenWrt are cited as counterpoints showing niche hardware can work with strong community backing.
Apps, Phishing, and Platform Responsibility
- Tangential debate about Google’s narrative of “verifying developers wherever you get the app”:
- Some see it as similar to EV certificates—nominal identity checks that don’t stop real‑world fraud.
- Others note real problems with fake “banking” apps, but argue deeper issues stem from app‑centric design and data‑hungry business models, not lack of developer identity checks.