So basically to summarize, Google embargoes security patches for four months so OEMs can push out updates more slowly. And if those patches were immediately added to an open source project like GrapheneOS, attackers would gain info on the vulnerabilities before OEMs provide updates (the GrapheneOS project can see the patches, but they can't ship them). But a lot of patches end up being leaked anyway, so the delay ends up being pointless.
The stupidest part is that, according to the thread, OEMs are allowed to provide binary only patches before the embargo ends, making the whole thing nonsensical since it's trivial to figure out the vulnerabilities from the binaries.
Fun fact: Google actually owns the most commonly used tool, BinDiff ;)
How does this work legally? If Android AOSP is open-source, once one OEM updates, surely the owner gets the legal right to request sources. IIRC the maximum delay is 30 days.
Almost all of AOSP is under the Apache or BSD licenses, not the GPL. Very few GPL components remain (the kernel being the large and obvious one).
So, yes, making a GPL request will work for the very few components still under GPL, if a vendor releases a binary patch. But for most things outside of the kernel, patch diffing comes back into play, just like on every closed-source OS.
Have you ever tried requesting the source code for your phone?
They'll either ignore you, or give you something that is obviously not the source code (e.g. huge missing sections; often they'll only produce kernel code and not even a way to compile it). Law be damned. They don't follow it and nobody is forcing them to
I don't think it is laziness per se. It's a combination of having far too many models (just look at Samsung's line-up, more than ten models per year if we don't count all the F and W variants), using many different SoCs from different vendors (just taking Samsung again as an example, using Qualcomm Snapdragon, Samsung Exynos, Mediatek Helio, Mediatek Dimensity, sometimes even a different chipset for the same phone model per region), each model supported for multiple years now on a monthly or quarterly update schedule (Samsung: recent A5x, Sxx, Sxx FE, Z Flip x, Z Flip 7 FE, Z fold x, Xcover x, etc. are on a monthly schedule). This across a multitude of kernel versions, AOSP versions (for older phones), OneUI versions (for phones that haven't been updated yet to the latest OneUI).
The must have literally over tens of different models to roll out security updates for, with many different SoCs and software versions to target.
And compared to other Android vendors, Samsung is actually pretty fast with updates.
It's true that other manufacturers have smaller line-ups, but they also tend to be smaller companies.
Compare that with Apple: every yearly phone uses the same SoC, only with variations in simpler things like CPU/GPU core counts.
Welcome to Android. It started out a bit undercooked and Google relied on OEMs to make finished polished products. Then the reality that OEMs suck at software hit them in the face. They spent years acquiring more control of their platform while trying not to piss off Samsung.
Have you considered the possibility that this may not be motivated by security at all, given the recent spate of similarly illogical and somewhat hostile decisions?
> Android security patches are almost entirely quarterly instead of monthly to make it easier for OEMs. They're giving OEMs 3-4 months of early access which we know for a fact is being widely leaked including to attackers.
Android is is over 15 years old and Google still hasn't fixed the update mess. Google should be in charge and ship security updates, not OEMs. You don't see Dell responsible for Windows security updates.
1. Release binary-only updates (opt-in).
2. Let the community (a) make GPL source requests for any GPLed components and (b) let the community reverse engineer the vulnerabilities from the binary updates.
3. Publish the source once everything is public anyways.
Which just shows how utterly ridiculous all this is.
One thing that seems positive is that it is now possible to release binary patches earlier than before, isn't it? My understanding is that before, OEMs had to wait for 1 month, and now they can release the binary patches right away.
I see a lot of people saying how the whole thing is completely ridiculous, but this part seems like a win.
I wish we had more choices beyond Android and iPhone.
I think this thread makes it quite clear that Android is not a secure OS, period. Like, maybe it’s safer on a Pixel with Google’s own distribution, but even still, Graphene is claiming that Google’s team is stretched thin and isn’t fixing issues from 2024.
i don't understand googles rationale here, what is the point in giving wind to the hackers sails while also driving home the narrative that android is a less secure system, especially after the recent changes related to the security of the latest iphone?
This is ridiculous. Makes one wonder about the state of OEM development. It's not hard to build a CI pipeline for android. There is no good reason OEMs can't be running test builds of ROMs with security patches within hours, and have QA done in a day or two, or a week max.
>Makes one wonder about the state of OEM development.
Why wonder at all, it sucks and it's security is generally in shambles. Security is rarely very high on their priorities as features/prettiness is what sells their phones.
On a Pixel from 6 upwards? Absolutely. GrapheneOS is what Android should be in terms of privacy and security. Its major drawback is only being available on Pixels, but if that is what you have…
I bought my Pixel 6 specifically to run GrapheneOS, and I really hope I can repeat that for my next device.
It's a crying shame that there isn't a Graphene compatible phone that also has a micro SD slot and headphone jack. The perfect phone just doesn't exist in our timeline
My rule is: if you can run GrapheneOS, you should run GrapheneOS.
My second rule is: if you are buying a new phone and can afford one that supports GrapheneOS (at the moment it means a Pixel), then you should go for that.
I haven't used LineageOS for a long time, but I remember it being really good. And I used cyanogenmod which IIRC was it's predecessor.
GraapheneOS is a different ball game IMO, especially if you need to use Google play services etc, banking apps etc. I'm not sure what the current state of microg is or Google services on lineage.
I bought a second hand pixel 6, just for Graphene and when that died I bought another pixel.
They just can't make an official release with it, because they can't publish the patch sources (embargoed) and their releases being open-source must match what they published...
Related discussion earlier this week, https://news.ycombinator.com/item?id=45158523
So basically to summarize, Google embargoes security patches for four months so OEMs can push out updates more slowly. And if those patches were immediately added to an open source project like GrapheneOS, attackers would gain info on the vulnerabilities before OEMs provide updates (the GrapheneOS project can see the patches, but they can't ship them). But a lot of patches end up being leaked anyway, so the delay ends up being pointless.
The stupidest part is that, according to the thread, OEMs are allowed to provide binary only patches before the embargo ends, making the whole thing nonsensical since it's trivial to figure out the vulnerabilities from the binaries.
Fun fact: Google actually owns the most commonly used tool, BinDiff ;)
Unless the OEMs bundle numerous changes with the security patch(es).
(I'm not saying it happens. I just theorise how the policy could have been envisaged)
3 replies →
How does this work legally? If Android AOSP is open-source, once one OEM updates, surely the owner gets the legal right to request sources. IIRC the maximum delay is 30 days.
Almost all of AOSP is under the Apache or BSD licenses, not the GPL. Very few GPL components remain (the kernel being the large and obvious one).
So, yes, making a GPL request will work for the very few components still under GPL, if a vendor releases a binary patch. But for most things outside of the kernel, patch diffing comes back into play, just like on every closed-source OS.
23 replies →
Have you ever tried requesting the source code for your phone?
They'll either ignore you, or give you something that is obviously not the source code (e.g. huge missing sections; often they'll only produce kernel code and not even a way to compile it). Law be damned. They don't follow it and nobody is forcing them to
Fuck, and I cannot emphasize this enough, the OEMs.
I am so sick of security being compromised so stupid, lazy people don't have to do their jobs efficiently. Not like this is even unusual.
I don't think it is laziness per se. It's a combination of having far too many models (just look at Samsung's line-up, more than ten models per year if we don't count all the F and W variants), using many different SoCs from different vendors (just taking Samsung again as an example, using Qualcomm Snapdragon, Samsung Exynos, Mediatek Helio, Mediatek Dimensity, sometimes even a different chipset for the same phone model per region), each model supported for multiple years now on a monthly or quarterly update schedule (Samsung: recent A5x, Sxx, Sxx FE, Z Flip x, Z Flip 7 FE, Z fold x, Xcover x, etc. are on a monthly schedule). This across a multitude of kernel versions, AOSP versions (for older phones), OneUI versions (for phones that haven't been updated yet to the latest OneUI).
The must have literally over tens of different models to roll out security updates for, with many different SoCs and software versions to target.
And compared to other Android vendors, Samsung is actually pretty fast with updates.
It's true that other manufacturers have smaller line-ups, but they also tend to be smaller companies.
Compare that with Apple: every yearly phone uses the same SoC, only with variations in simpler things like CPU/GPU core counts.
8 replies →
Welcome to Android. It started out a bit undercooked and Google relied on OEMs to make finished polished products. Then the reality that OEMs suck at software hit them in the face. They spent years acquiring more control of their platform while trying not to piss off Samsung.
1 reply →
> the delay ends up being pointless
Why though? It is pointless from the engineering and security standpoints, but for Google this may serve their goals very well.
The bigger headline is that Google is effectively giving attackers 3-4 months of advanced access to security patches: https://grapheneos.social/@GrapheneOS/115164183840111564.
Have you considered the possibility that this may not be motivated by security at all, given the recent spate of similarly illogical and somewhat hostile decisions?
[dead]
CIA wins!
> Android security patches are almost entirely quarterly instead of monthly to make it easier for OEMs. They're giving OEMs 3-4 months of early access which we know for a fact is being widely leaked including to attackers.
Android is is over 15 years old and Google still hasn't fixed the update mess. Google should be in charge and ship security updates, not OEMs. You don't see Dell responsible for Windows security updates.
You see when using laptops, with their custom installations, and hence why not using OEM drivers might turn into lost weekends.
The solution (heavily) alluded to by GrapheneOS in https://grapheneos.social/@GrapheneOS/115164212472627210 and https://grapheneos.social/@GrapheneOS/115165250870239451 is:
1. Release binary-only updates (opt-in). 2. Let the community (a) make GPL source requests for any GPLed components and (b) let the community reverse engineer the vulnerabilities from the binary updates. 3. Publish the source once everything is public anyways.
Which just shows how utterly ridiculous all this is.
The CRA should help here hopefully. See cyber resilience act Article 14 – Reporting obligations of manufacturers https://www.cyberresilienceact.eu/the-cyber-resilience-act/#
One thing that seems positive is that it is now possible to release binary patches earlier than before, isn't it? My understanding is that before, OEMs had to wait for 1 month, and now they can release the binary patches right away.
I see a lot of people saying how the whole thing is completely ridiculous, but this part seems like a win.
I wish we had more choices beyond Android and iPhone.
I think this thread makes it quite clear that Android is not a secure OS, period. Like, maybe it’s safer on a Pixel with Google’s own distribution, but even still, Graphene is claiming that Google’s team is stretched thin and isn’t fixing issues from 2024.
Meanwhile, Apple is allegedly building the most secure devices you can connect to the Internet: https://techcrunch.com/2025/09/11/apples-latest-iphone-secur...
I was happy on Symbian land, then on Windows Phone land, but alas that isn't how things turned out.
i don't understand googles rationale here, what is the point in giving wind to the hackers sails while also driving home the narrative that android is a less secure system, especially after the recent changes related to the security of the latest iphone?
They are giving a chance for government agencies to hack Graphene phones.
You mean the changes Pixels phones had since late 2021 ? /s https://grapheneos.social/@GrapheneOS/115176133102237994
we're talking about OEM devices aren't we?
This is ridiculous. Makes one wonder about the state of OEM development. It's not hard to build a CI pipeline for android. There is no good reason OEMs can't be running test builds of ROMs with security patches within hours, and have QA done in a day or two, or a week max.
> There is no good reason OEMs can't be running test builds of ROMs with security patches within hours
That sounds like it costs money and doesn’t net the mfg new sales.
Trying to do software well at hardware centric companies is hard. Mostly for this reasoning.
>Makes one wonder about the state of OEM development.
Why wonder at all, it sucks and it's security is generally in shambles. Security is rarely very high on their priorities as features/prettiness is what sells their phones.
The only responsible disclosure is full disclosure.
I currently use LineageOS on my pixel. Is it worth trying GraphineOS?
On a Pixel from 6 upwards? Absolutely. GrapheneOS is what Android should be in terms of privacy and security. Its major drawback is only being available on Pixels, but if that is what you have…
I bought my Pixel 6 specifically to run GrapheneOS, and I really hope I can repeat that for my next device.
It's a crying shame that there isn't a Graphene compatible phone that also has a micro SD slot and headphone jack. The perfect phone just doesn't exist in our timeline
GrapheneOS is by far the better OS security and privacy wise.
It should be the default choice for everyone IMO, as long as they have a phone that supports it.
See this comparison: https://eylenburg.github.io/android_comparison.htm
My rule is: if you can run GrapheneOS, you should run GrapheneOS.
My second rule is: if you are buying a new phone and can afford one that supports GrapheneOS (at the moment it means a Pixel), then you should go for that.
I haven't used LineageOS for a long time, but I remember it being really good. And I used cyanogenmod which IIRC was it's predecessor.
GraapheneOS is a different ball game IMO, especially if you need to use Google play services etc, banking apps etc. I'm not sure what the current state of microg is or Google services on lineage.
I bought a second hand pixel 6, just for Graphene and when that died I bought another pixel.
If the smart plan of having others reverse-engineer the fixes won't work, I imagine they'll turn into a delayed-source product.
To my recollection, they always maintained that being open-source doesn't matter for security, after all
(I strongly disagree)
> Companies like NSO can easily obtain access. It's not a safe system.
If NSO group develops exploits, why would they have early access?
[dead]
llyou_m1233
Don't trust these guys.
That's not helpful without context and substance.
"They can easily get it from OEMs or even make an OEM."[0]
I agree with their points in the thread, but could Graphene "become" an OEM to get access to the security patches sooner? Just curious.
[0] https://grapheneos.social/@GrapheneOS/115164297480036952
They have access to the patches.
They just can't make an official release with it, because they can't publish the patch sources (embargoed) and their releases being open-source must match what they published...
What if that OEM stops giving them patches?
Also, if they're asking an OEM to release the patches, why can't they become an OEM to do that?
They have an OEM partner right now who funnels them the updates, which is how they get access to them.
Is it Framework?
3 replies →