Exclusive: Google wants to make Android phones safer by switching to ‘risk-based’ security updates

Discussion in 'mobile device security' started by ronjor, Sep 15, 2025.

  1. ronjor

    ronjor Global Moderator

    Joined:
    Jul 21, 2003
    Posts:
    185,144
    Location:
    Texas
  2. reasonablePrivacy

    reasonablePrivacy Registered Member

    Joined:
    Oct 7, 2017
    Posts:
    2,329
    Location:
    Member state of European Union
    Critical CVE won't be print in public ASB monthly, because they aren't currently explited in the wild? It doesn't seem like an security improvement.
     
  3. BoerenkoolMetWorst

    BoerenkoolMetWorst Registered Member

    Joined:
    Dec 22, 2009
    Posts:
    4,983
    Location:
    Outer space
    Yes, there is no improvement at all, only a way to make OEMs look better by giving them less updates per year, so they have more time to implement it. Google should have kept Android updates central from the beginning instead of depending on OEM manufacturers to roll them out.
    Note that the monthly ASBs already were backports to begin with. They're only High and Critical severity fixes for the last few yearly releases. To get the Low and Medium severity fixes, you need to update to the actual quarterly and monthly Android/AOSP releases. However, I don't think there is any 3rd party OEM who released those updates, except Google (and GrapheneOS and maybe some other 3rd party OS/ROM.)
    Apparently even just releasing the monthly backports seems like a challenge for OEMs, even though they get them one month in advance. If you release tons of different phone models, you still need to support them, so they shot themselves in their own feet. Even so, when a tiny player like GrapheneOS can release an update based on the monthly ASB just in a few days after public release, it seems that million/billion dollar 3rd party OEM's with 1 month advance access still not able to publish monthly ASB need to get their priorities straight.
    The problem now is bunching most security fixes together, delaying release to the end users. (Except those uses that did not receive monthly ASBs from their OEMs anyway.)
    OEMs get them 3-4 months in advance, which means tons of bad actors can easily get access to them and develop exploits.
    A strange decision is that because the embargo period is now 3-4 months, they changed the embargo to be on source code only. Binary releases are still allowed. Apparently it's really easy to reverse the Java/Kotlin binary releases back to source code. Which means anyone can get access and defeats the whole embargo in the first place.
    GrapheneOS is lucky enough to have access to the source code through an agreement with an OEM. But they cannot publish the updates early because they are open source and are not allowed to publish the source. Now they need to make separate update channels with binary only updates for those wishing to get monthly security updates again, and they can publish the source only after embargo has ended. (Unless someone leaks the source.)
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.