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.
lima 8 hours ago [-]
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 ;)
nroets 8 hours ago [-]
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)
numpad0 4 hours ago [-]
In the good old days, there were exploits patched years prior by some OEMs that were never upstreamed even to Google. New rooting apps come out and... just doesn't work. I don't know if that still happens, though.
tester89 7 hours ago [-]
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.
bri3d 6 hours ago [-]
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.
dijit 5 hours ago [-]
weird tangential question then: when does GPL stop being infectious?
I would understand in a modular system like an operating system: one can argue that the kernel is a single component.
But if you're buying an appliance, the OS is effectively one single unit: all linked together.
Why does a binary executable and a binary image seem to operate differently in this space - both are inscrutable?
rollcat 5 hours ago [-]
The FSF has always been pretty clear on this: you use a linker (static or dynamic) = it applies; you don't = it doesn't. They even wrote LGPL with this distinction in mind, and introduced exceptions to yacc (bison) to accommodate non-free software.
In case of binary releases, you can request the sources of the relevant subcomponent (e.g. the kernel). The component boundaries are pretty clear wrt Linux: Torvalds has made it quite clear early on, that the kernel's GPL2 does not apply to anything in the user space.
Here also, the important distinction between GPL 2 & 3: with GPL3, it would be a breach of the license to ship code on a device that does not allow the end user to update that code. Which has effectively pushed everyone away from GPL3-licensed software.
IMHO the move to GPL3 has likely caused more harm than good to the FOSS ecosystem; in some alternative universe, GPL3 never happened, most of Android's userspace is GPL2, and we get the source for everything. In both universes we still don't get to deploy changes to devices we own, so IMHO the GPL3 won us nothing.
cyphar 5 hours ago [-]
The FSF considers linking to be a definite example of derived works in general, but I don't believe they consider lack of linking to prove that something isn't a derived work.
The goal of the GPL is to flip draconian copyright maximalism on its head, and copyright laws don't talk about linkers so that can't be the deciding factor. Not to mention that it would be trivial to work around linking by creating a stub and calling the GPL code as a subprogram (in kernel contexts a spiritually similar setup is called the "GPL condom" and my impression is that most lawyers not employed by NVIDIA consider this to not be a get-out-of-jail-free card).
> the OS is effectively one single unit: all linked together
If your appliance runs linux it has separate components just like desktop linux.
You want to do as little as possible in kernel space, and depending on the appliance there isn't even any need for it.
So, like desktop linux, you can have closed source binaries on top of the kernel.
dijit 2 hours ago [-]
I just don’t see the distinction as clearly when it’s a single binary that cannot be decoupled or introspected.
Why is it if I build a static binary with GPL code and distribute it I must open source my changes; but if you do the same as a whole OS it’s not necessary.
Feels like it should all be fine or none of it is fine somehow.
nottorp 2 hours ago [-]
If you go that way, every bash script you've ever written should also be under the GPL.
And R code, at a quick glance.
dijit 2 hours ago [-]
only if someone was to copy the entire script and then put it into their distributed binary; which is what I am saying that the OEMs are doing with Linux.
cyphar 5 hours ago [-]
The short answer is copyright law and jurisprudence. The whole purpose of copyleft is to flip draconian copyright regimes over and make them protect users instead, so the GPL generally has the most maximalist stance allowed by copyright law. If copyright law would say that combining or extending software in a particular way is not fair use then the GPL generally would render the combination GPL.
In practice, GPLv2 would not be viral in the way you describe unless you can show that all of Android is a derived work of Linux (not true). GPLv3 would require users be avle to replace components under said license which has an impact on how such an appliance need to work (though the GPLv2 does also have somewhat related text about "the scripts which control installation") but wouldn't expand the scope of code under the license, just the terms.
Tangentially, I assumed that the GPL must have some built-in exception for running non-GPL userspace programs on top of a GPLed kernel (similar to the System Library exception). However, it seems like it doesn't, since the Linux kernel has its own exception to allow this: https://spdx.org/licenses/Linux-syscall-note.html.
Hizonner 7 hours ago [-]
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.
danieldk 5 hours ago [-]
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.
Hizonner 5 hours ago [-]
> I don't think it is laziness per se
You forgot the "stupid" part.
> 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
> [...]
> 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).
Those are choices. If you want to do that, you need a process that can support it.
I suppose it could be that they just don't care and are deliberately screwing their users, but never attribute to malice that which can be explained by incompetence and all that.
yathaid 4 hours ago [-]
>> Those are choices. If you want to do that, you need a process that can support it.
__need__ is doing a lot of work here. There is no forcing function to get OEMs to do this ASAP: 1) the market doesn't really care that much 2) there are no regulations around this (and even if they were, can you immediately recall a tech exec going to jail for breaking the law ... )
danieldk 5 hours ago [-]
Those are choices. If you want to do that, you need a process that can support it.
I suppose it could be that they just don't care and are deliberately screwing their users, but never attribute to malice that which can be explained by incompetence and all that.
I think for a long time Android users did not really care. Until a few years, Android security support was abysmal with many vendors only doing 1-2 years of updates. Users bought the phones and didn't care, so I guess it was a smart business move to not care.
This changed in recent years due to a mixture of the (then) upcoming EU requirement for supporting devices multiple years with security updates, Apple being able to tout this as an advantage, causing Google and Samsung to enter into a competition to promise the largest number of years of security support, etc.
WorldPeas 5 hours ago [-]
To me this is the ultimate failing of ARM as an ISA, the fact that you even need to consider "targeting" allows a deficient ISA like x86 to still stand head and shoulders above it in terms of OEM support (though perhaps not security)
rollcat 5 hours ago [-]
It has nothing to do with the ISA and everything to do with the system architecture. Look up PC-98.
Also: PC being a "standard" is a lie; ACPI is a horror.
Zigurd 7 hours ago [-]
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.
tracker1 4 hours ago [-]
Pretty much this... and even then, they still suck hard. Apple was right to start off with as much control over their platform as they did. The only reason I never went with iPhone is it started as an AT&T exclusive, and you couldn't pay me enough to be their customer ever again.
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?
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 only responsible disclosure is full disclosure.
t1234s 5 hours ago [-]
I currently use LineageOS on my pixel. Is it worth trying GraphineOS?
Freak_NL 4 hours ago [-]
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.
skeaker 2 hours ago [-]
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
lawn 3 hours ago [-]
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.
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.
baby_souffle 8 hours ago [-]
> 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.
all2 6 hours ago [-]
Trying to do software well at hardware centric companies is hard. Mostly for this reasoning.
pixl97 7 hours ago [-]
>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.
honeybadger1 8 hours ago [-]
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?
oneshtein 3 hours ago [-]
They are giving a chance for government agencies to hack Graphene phones.
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...
qingcharles 5 hours ago [-]
They have an OEM partner right now who funnels them the updates, which is how they get access to them.
acqbu 1 hours ago [-]
Is it Framework?
hollerith 1 hours ago [-]
Why would Framework have access to Android patches?
7 hours ago [-]
Rendered at 22:13:16 GMT+0000 (Coordinated Universal Time) with Vercel.
Fun fact: Google actually owns the most commonly used tool, BinDiff ;)
(I'm not saying it happens. I just theorise how the policy could have been envisaged)
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.
I would understand in a modular system like an operating system: one can argue that the kernel is a single component.
But if you're buying an appliance, the OS is effectively one single unit: all linked together.
Why does a binary executable and a binary image seem to operate differently in this space - both are inscrutable?
In case of binary releases, you can request the sources of the relevant subcomponent (e.g. the kernel). The component boundaries are pretty clear wrt Linux: Torvalds has made it quite clear early on, that the kernel's GPL2 does not apply to anything in the user space.
Here also, the important distinction between GPL 2 & 3: with GPL3, it would be a breach of the license to ship code on a device that does not allow the end user to update that code. Which has effectively pushed everyone away from GPL3-licensed software.
IMHO the move to GPL3 has likely caused more harm than good to the FOSS ecosystem; in some alternative universe, GPL3 never happened, most of Android's userspace is GPL2, and we get the source for everything. In both universes we still don't get to deploy changes to devices we own, so IMHO the GPL3 won us nothing.
The goal of the GPL is to flip draconian copyright maximalism on its head, and copyright laws don't talk about linkers so that can't be the deciding factor. Not to mention that it would be trivial to work around linking by creating a stub and calling the GPL code as a subprogram (in kernel contexts a spiritually similar setup is called the "GPL condom" and my impression is that most lawyers not employed by NVIDIA consider this to not be a get-out-of-jail-free card).
https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
If your appliance runs linux it has separate components just like desktop linux.
You want to do as little as possible in kernel space, and depending on the appliance there isn't even any need for it.
So, like desktop linux, you can have closed source binaries on top of the kernel.
Why is it if I build a static binary with GPL code and distribute it I must open source my changes; but if you do the same as a whole OS it’s not necessary.
Feels like it should all be fine or none of it is fine somehow.
And R code, at a quick glance.
In practice, GPLv2 would not be viral in the way you describe unless you can show that all of Android is a derived work of Linux (not true). GPLv3 would require users be avle to replace components under said license which has an impact on how such an appliance need to work (though the GPLv2 does also have somewhat related text about "the scripts which control installation") but wouldn't expand the scope of code under the license, just the terms.
Tangentially, I assumed that the GPL must have some built-in exception for running non-GPL userspace programs on top of a GPLed kernel (similar to the System Library exception). However, it seems like it doesn't, since the Linux kernel has its own exception to allow this: https://spdx.org/licenses/Linux-syscall-note.html.
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.
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.
You forgot the "stupid" part.
> 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 > [...] > 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).
Those are choices. If you want to do that, you need a process that can support it.
I suppose it could be that they just don't care and are deliberately screwing their users, but never attribute to malice that which can be explained by incompetence and all that.
__need__ is doing a lot of work here. There is no forcing function to get OEMs to do this ASAP: 1) the market doesn't really care that much 2) there are no regulations around this (and even if they were, can you immediately recall a tech exec going to jail for breaking the law ... )
I suppose it could be that they just don't care and are deliberately screwing their users, but never attribute to malice that which can be explained by incompetence and all that.
I think for a long time Android users did not really care. Until a few years, Android security support was abysmal with many vendors only doing 1-2 years of updates. Users bought the phones and didn't care, so I guess it was a smart business move to not care.
This changed in recent years due to a mixture of the (then) upcoming EU requirement for supporting devices multiple years with security updates, Apple being able to tout this as an advantage, causing Google and Samsung to enter into a competition to promise the largest number of years of security support, etc.
Also: PC being a "standard" is a lie; ACPI is a horror.
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.
I bought my Pixel 6 specifically to run GrapheneOS, and I really hope I can repeat that for my next device.
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
That sounds like it costs money and doesn’t net the mfg new sales.
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.
To my recollection, they always maintained that being open-source doesn't matter for security, after all
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 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...