10 ms·

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 add

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 1y 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 1y 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 1y 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.
  - groggler 1y ago
    Not really.. numerous changes are still not a total redesign of whichever subsystem was affected so it's pretty obvious where some small security relevant changes are. A stupid embargo was always enough to ruin security by code analysis for white hats but never enough to stop attacks by code analysis for black hats.
    - lima 1y ago
      Yep, people have been reversing huge Windows patches for decades and it never stopped anyone from figuring out what the fixes were.
Hizonner 1y 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.
- Zigurd 1y 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 1y 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.
- microtonal 1y 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.
tester89 1y 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 1y 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 1y 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 1y 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.
egorfine 1y ago
> 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.

lima 1y 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 1y 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 1y 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.
- groggler 1y ago
  Not really.. numerous changes are still not a total redesign of whichever subsystem was affected so it's pretty obvious where some small security relevant changes are. A stupid embargo was always enough to ruin security by code analysis for white hats but never enough to stop attacks by code analysis for black hats.
  - lima 1y ago
    Yep, people have been reversing huge Windows patches for decades and it never stopped anyone from figuring out what the fixes were.

Hizonner 1y 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.

Zigurd 1y 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 1y 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.
microtonal 1y 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.

tester89 1y 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 1y 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 1y 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 1y 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.

egorfine 1y ago

> 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.