6 ms·
Delayed Security Patches for AOSP (Android Open Source Project)
- delecti 1y agoXCancel link which will show the thread context if you aren't logged in to Twitter: https://xcancel.com/grapheneos/status/1964561043906048183 https://xcancel.com/grapheneos/status/1964561043906048183
- strcat 1y agoNote the post title is incorrect. See https://news.ycombinator.com/item?id=45160975 https://news.ycombinator.com/item?id=45160975. Android patches are being delayed in general, not only for AOSP.
- flotzam 1y ago"No tags were pushed to AOSP for the July 2025 monthly release of Android. We asked about this on the android-building group but each of our posts was rejected. We emailed people at Google we've previously contacted about mistakes pushing tags but received no response this time." https://xcancel.com/GrapheneOS/status/1952413110947430786 https://xcancel.com/GrapheneOS/status/1952413110947430786 "July monthly release was not pushed to AOSP and then neither was the August monthly release. September quarterly release hasn't been pushed yet." https://xcancel.com/GrapheneOS/status/1963812920673861981 https://xcancel.com/GrapheneOS/status/1963812920673861981
- strcat 1y agoThat's about the monthly and quarterly releases of Android, not the Android security patches. The post title is misinterpreting what's wrong. There is a lot wrong but that's not it. The baseline Android security patches are being delayed for Android as a whole, not AOSP specifically. Not having the very tiny monthly updates pushed to AOSP is an annoyance which will delay a subset of non-security bug fixes until the quarterly releases. It's a bad change, although we know have a good idea why it happened and need the reason it happened to be reversed for them to push those again. We've been told by multiple people at Google that the quarterly releases would still be pushed and that monthly releases are largely being phased out. However, the quarterly update was not pushed as expected on September 3rd. If it's pushed on Monday, it will be 6 days late. There hasn't been a similar delay for quarterly and yearly releases in the past. GrapheneOS can still provide security updates but not having the quarterly release is a major problem and it's not clear why it wasn't pushed when they said it was going to be pushed. There's a separate issue not specifically tied to AOSP impacting security patches which is what the initial part of our reply was about. See https://x.com/GrapheneOS/status/1964754118653952027 https://x.com/GrapheneOS/status/1964754118653952027 for an explanation.
- rs186 1y agoSerious question: do we know as a matter of fact that iOS and family are safer than Android, including Pixel, especially when it comes to 0-day exploits?
- strcat 1y agoNo, but Google has significantly downgraded security from it used to be and Apple isn't sharing security patches very broadly outside their company 4 months ahead of fixing them. They don't have partners to share it with. That's not to say there aren't people in the company leaking them but they likely don't take that long to fix most patches. We considered the Pixel stock OS largely competitive with iOS on security but recent changes including but not limited to this are changing our mind. Both the Linux kernel and Google with Android are doing a horrific job with security. Apple has their own issues but it's not this embarrassingly bad and getting consistently better. Google could easily provide strong security for Pixels and AOSP but is downgrading them to appease OEMs failing to keep up with the previous already bare minimum patch system they were expected to follow. An issue reported to Google 3 months ago and fixed today would likely get disclosed to partners around November 2025 or December 2025 and then officially fixed in March 2025. It's not just 1 month of early access for OEM partners now but rather around 4 months. Patches are artificially delayed beyond the time to fix them by 4 months. This is completely ridiculous. Google also doesn't control the patch releases for many projects such as the Linux kernel and many other external projects they use. This means they're always going to be at least around 4 months behind on including a small number of patches for those projects as mandatory to fix for Android OEMs. The bar for Android OEMs was already ridiculously low and they've made it far lower. It's dragging down the Pixel stock OS with it to a significant extent. Google realizes this system is horrible and has therefore added a binary-only exception to the embargo which is a complete joke since they know it's easy to reverse the patches. However, it's not really being used in practice. It's just an option to ship binary-only patches without the long delay now. We have this option for GrapheneOS since we do have access to the partner bulletins via an OEM partner. We could also ask our OEM partner not to share them with us and instead obtain them another way with no NDA to publish them right away. We haven't asked for the December patches yet since we haven't decided how to handle it. The current embargo would allow us to publish a special delayed source release variant of GrapheneOS this month with December 2025 patches, but we want to provide source code for all our releases and do not want to have a special variant of the OS needed for the latest Android patches. With how broadly they've distributed the December 2025 patches, they can't seriously be considered private and it should be permitted to simply ship them now. Android's partner licensing people are destroying the security work. Play Integrity API is similar pretend security actually just enforcing Google's partner licensing model while actually disallowing using much more secure devices. That's highly anti-competitive and so is what they're doing with security patches. Both should result in substantial regulatory action against them, and perhaps it will, but it will probably come a very long time from now when the damage is done.
- dvrj101 1y ago̶D̶o̶n̶'̶t̶ ̶b̶e̶ ̶e̶v̶i̶l̶
- ACCount37 1y agoAnd so, Google's war on open Android continues. Fucking hell. Can Google stop being evil for like 5 minutes? It's like they can't go a week without coming up with some new fucked up thing to do to their already tormented mobile ecosystem.
- chasil 1y ago"Why should people believe what you say about /^.*$/?" That regex derived from the tweet seems apt.
- strcat 1y agoNote the post title is incorrect. See https://news.ycombinator.com/item?id=45160975 https://news.ycombinator.com/item?id=45160975. Android patches are being delayed in general, not only for AOSP.
- scottbez1 1y agoThis is entirely unsurprising. It's been clear that Google has been into their Android duopoly-abusive stage for a while now, with more and more of their Android changes moving into GMS or non-AOSP Google apps (like camera, messages, location services, etc) over the last decade. Graphene has been doomed to this fate for a long time, and anyone who thought otherwise was naively optimistic. The same is clearly coming for Chromium forks, which is why I've always thought the privacy and ad-blocking forks are a joke - if they ever gain enough marketshare, or if google just tires of the public open source charade, they have no chance of maintaining a modern browser on their own. This is all the more likely now that Google has been emboldened by not having to sell off Chrome for anticompetitive reasons.
- ACCount37 1y agoJust a year prior, I would have been against a decision to force Google to part with either Android or Chrome. Now, I'm of the opinion that they should have been forced to sell off both, and maybe Chromebooks too, for the good measure. No company with a direction as vile and openly user-hostile as what Google currently demonstrates should have anywhere near this level of control over the ecosystem.
- wmf 1y agoI wonder if Android and Chrome would support open source even less as independent companies though.
- SpaghettiCthulu 1y agoWhy not spin them each off into an independent non-profit?
- wmf 1y agoBecause people don't just throw away money.
- 1y ago
- mdasen 1y agoGoogle sold Android to nerds as open source. We thought that mobile operating systems would be won by the "Linux of mobile OSs." But Google has made sure that didn't happen and we're left with devices more locked down than the proprietary Windows ecosystem we were hoping to leave in the past - and with a company in charge looking to exert even more power over us than Microsoft did.
- arcane23 1y agoThe trick is adding a ton of features which expose extra attack surface that needs them to maintain and fix, under the pretense that it will make everyone's life easier. Make it complicated enough so that the community cannot maintain it, enabling the corporation to throw its weight around.
- cosmic_cheese 1y agoIt’s the perfected form of what MS was trying to achieve with IE back in the 90s. All the power of a closed source monopoly, further enhanced by friends and foes alike incorporating your tech as a load-bearing pillar of their strategies, with a cloak of plausible deniability in the form of an open source repo protecting you from antitrust enforcement. A true have your cake and eat it situation.
- yupyupyups 1y agoThis is what happened with the Qt app dev framework. The Qt Company delayed releases of LTS updates to non-paying users by 1 year, while not properly dealing with the steady stream of regressions that were affecting normal releases. I quit Qt development partially because I felt that I was dealing with forever-beta software. But actually, with Qt you do have KDE devs who push their own patches which does help deal with the flaws in the upstream project. In the Android world, they need more devs doing the same and supporting projects like GrapheneOS with security testing/hardening.
- strcat 1y agoNote the post title is incorrect. See https://news.ycombinator.com/item?id=45160975 https://news.ycombinator.com/item?id=45160975. Android patches are being delayed in general, not only for AOSP.
- gessha 1y ago> We want to make sure that if you download an app from a developer, regardless of where you get it, it's actually from them. That's it. In what scenario is this a serious threat because I can't think of any.
- charcircuit 1y agoIt sounds like EV certificates, and it turned out that in practice no one cared about id verification.
- gessha 1y agoThis feels like an airplane bullet hole example.
- wmf 1y agoPeople are installing banking apps that are actually from criminals. Basically app phishing.
- OutOfHere 1y agoLet's not call them banking apps. They're not. They're scam apps. The problem represented in the tweet is deeper. It is about not receiving patches which means the device is basically unsafe to use altogether.
- dvrj101 1y ago> People are installing banking apps that are actually from criminals. and this identification does nothing about that, this is not to protect users. such phishing are always found on play-store alone.
- const_cast 1y agoThe reason this happens is that greedy companies like Google have made apps the de facto way to get anything done. There's 0 reason you should need an app to fucking pay for parking. Why do you then? Because running mostly unsandboxed native code on customers devices is a fantastic way to steal data and build profiles. Browsers just don't cut it - they're too safe, too secure, too abstracted. Let's be honest here - what is a banking app? Web forms, some more web forms, and then to top it off, some web forms. I mean, hell, half these apps are just web views with spywa - I mean analytics - slapped on top.
- OutOfHere 1y agoI hope that this action, along with Google's refusal to correctly safeguard and segregate apps, costs Google all of Android in the long term. Neither deserves to exist. Any thoughts on Linux phones?
- add-sub-mul-div 1y agoUnchecked Apple without real competition would be worse than the status quo.
- OutOfHere 1y agoThat is a misrepresentation because Samsung, Huawei, and various Linux vendors each will have their own answer, their own alterative. In no universe will Apple be without competition. Apple is not even a consideration since it doesn't allow unapproved app installation anyway.
- odo1242 1y agoAndroid only ever had a chance because it is one ecosystem. Developers aren't going to develop for five slightly-different ecosystems in a trench coat.
- OutOfHere 1y ago> Developers aren't going to develop for five slightly-different ecosystems The point, perhaps, is for one to emerge as the prominent choice, the correct one. Diversity however has its own value.
- palata 1y agoI wish Android manufacturers contributed to AOSP, so that it would still be one ecosystem, but with shared ownership. But I guess it's more profitable for all of them to let Google do it on their own. And it sucks for the user, because we have to live with Google's decisions.
- arcane23 1y agoSeems like there needs to be a split of both hardware and software. Mobile phones morphed into something else lately. Not all of us need all the features of a smart phone, but still need a comms device. We need a simpler OS with simpler hardware that focuses on comms and less features. Simpler OS, lower attack surface, simpler to maintain without the help of a gigantic corporation. I don't need a supercomputer in my pocket.
- gruez 1y ago>Not all of us need all the features of a smart phone, but still need a comms device. [...] I don't need a supercomputer in my pocket. What's stopping you from using a feature phone?
- arcane23 1y agoSecurity/privacy?
- gruez 1y agoSo you want a $100 feature phone that has serious security features like monthly security patches and dedicated security coprocessors? It's tough to make the economics of that work out. All the serious security features costs money to implement, either in the form of development costs or added costs to the BOM. Those costs can be absorbed if you're selling a $600 phone, but not a $100 phone. If you try to add those features to a $100 phone, it'll end up making the phone more expensive, which means nobody but security freaks would buy your phone, and you lose economies of scale that's needed to make a phone at all. Back to your point, there's already a "split of hardware and software" in the PC market, and we know how it works out. Security there is a joke. Windows might be getting monthly security patches, but the same can't be said of the panoply of third party drivers/firmware. Whenever microsoft tries to push for better security they get shouted down by people claiming it's some sort of conspiracy to implement DRM.
- arcane23 1y ago
- charcircuit 1y agoSecurity of the Android ecosystem should not be compromised just to make the lives of Googlers easier in handling the public, internal, and pixel branches of AOSP. Edit: The HN title is false and security patches were released. But this is more about Google trying to appease OEMs who aren't capable with keeping up with a monthly OS release schedule.
- palata 1y agoThe only reason that would make me fear from an antitrust judgement splitting Android from Google is that it may lose the Google contributions to AOSP. Google is more and more showing that they really don't want to contribute to AOSP. So for me, Android should be split out of Google. Maybe the other Android manufacturers will start contributing to AOSP, and maybe Android will die. But let me be honest: if Google keeps going this way, I will move to an iPhone (and I've been using and developing for Android forever). We may as well try the split, and if it fails I'll end up with an iPhone anyway.
- strcat 1y agoNote the post title is incorrect. See https://news.ycombinator.com/item?id=45160975 https://news.ycombinator.com/item?id=45160975. Android patches are being delayed in general, not only for AOSP.
- neilv 1y agoLooks like PostmarketOS (mainline Linux for phones, with choice of frontend, such as Plasma Mobile or Phosh) has demoted all their previous "Main"-tier devices to "Community" or lower tier: https://wiki.postmarketos.org/wiki/Devices#Main https://wiki.postmarketos.org/wiki/Devices#Main Anyone know whether this is a sign of a push for being daily driver quality? Or a sign that volunteers previously doing promising work have drifted away, and they're acknowledging that?
- fabrice_d 1y agoMain is described as "The most supported devices, with all the features and stability you'd expect from a regular OS." Unfortunately there was/is no device supported by postmarketOS that fits that description. You'll need at least good telephony support including 4G features like VoLTE, proper camera support (not potato polaroid from the 80s quality), Wifi, Bluetooth, geolocation, working GPU acceleration, media hardware decoders, decent battery life. And I'm probably forgetting a few things. Let's hope that initiatives like https://liberux.net/ https://liberux.net/ will help make a fully working, long lasting device available!
- palata 1y agoUnfortunately, and as much as I like Linux for phones, I think it's very, very far from AOSP. It completely misses the AOSP security model and the apps (no, I don't believe that running waydroid on Linux is entirely viable, otherwise instead of Linux for phone we would have Waydroid as an alternative to Android). I think the only realistic alternative would be to build upon AOSP properly, with Google being just a contributor instead of the owner. But it cannot come from a community fork by someone in their garage, it has to come from Android manufacturers. I was hoping that Huawei would start something like that, instead they went with their own HarmonyOS.
- deleted 1y ago[deleted]
- deleted 1y ago[deleted]
- Arnavion 1y ago
- deleted 1y ago[deleted]
- bhouston 1y agoFYI the poster this story links to says that this title is incorrect: https://x.com/grapheneos/status/1964757878910136346?s=46 https://x.com/grapheneos/status/1964757878910136346?s=46 They say this: Our reply here was linked on Hacker News with an inaccurate title ("Delayed Security Patches for AOSP"). Security patch backports were pushed to AOSP on September 2nd for Android 13, 14 and 15 as expected. More information is available at x.com/GrapheneOS/sta… explaining the situation with security patches. It would be better to have a thread linking to that instead. We have early access to the security patches, but we can't break the embargo. We can only release the sources once source release is allowed. We could make a security preview branch but the system simply doesn't make sense. Android 16 QPR1 is a new major release, not a security patch release. Our reply is talking about 2 different issues. Android 16 QPR1 is what was delayed for AOSP and we don't currently know why. It's possible it was a mistake and it will be pushed on Monday.
- strcat 1y agoX cut off the link you copied within our reply. Here's that link along with 2 alternatives other than X: https://x.com/GrapheneOS/status/1964754118653952027 https://x.com/GrapheneOS/status/1964754118653952027 https://bsky.app/profile/grapheneos.org/post/3lyb6rx46tc2r https://bsky.app/profile/grapheneos.org/post/3lyb6rx46tc2r https://grapheneos.social/@GrapheneOS/115164133992525834 https://grapheneos.social/@GrapheneOS/115164133992525834
- transpute 1y agoThanks for the clarification. 90 day embargo of patches for all Android is worse than delaying for AOSP, https://news.ycombinator.com/item?id=45158523#45161240 https://news.ycombinator.com/item?id=45158523#45161240 They're giving OEMs 3-4 months of early access which we know for a fact is being widely leaked including to attackers.
- strcat 1y agoThis is an official response from GrapheneOS: The title of this post linking our reply is inaccurate and is not what we said ("Delayed Security Patches for AOSP"). It should really be changed from "for AOSP" to "for Android". Security patch backports were pushed to AOSP on September 2nd for Android 13, 14 and 15 as expected. The issue isn't the security patches being delayed for AOSP. We didn't say patches are being delayed for AOSP. Security patches for Android are being delayed as a whole. The delays aren't specific to AOSP. They're moving to quarterly security updates with 4 months of early OEM access instead of monthly security updates with 1 month of early OEM access. They realize that the patches distributed to OEMs are hardly secret once they're so broadly distributed. Therefore, they've relaxed the rules of the embargo and permitted releases of patches under certain rules without being allowed to providing a description or the sources for the patch. This is ridiculous because it's easy to reverse the patches from binary-only releases. Google trying to cover for OEMs not keeping up with patches by making it seem as if the patches are now quarterly and largely being delivered on time while actually broadly disclosing them 4 months early and permitting quietly fixing them early. We posted a much more detailed explanation at https://x.com/GrapheneOS/status/1964754118653952027 https://x.com/GrapheneOS/status/1964754118653952027. It would be better to link to our more detailed post.
- brayann 1y ago[flagged]
- brayann 1y ago[flagged]