2 ms·
>The "Complete monthly Android Security Bulletin patches without any regular delays longer than a week for device support code (firmware, drivers and HALs)" par
by gruez 1y ago
>The "Complete monthly Android Security Bulletin patches without any regular delays longer than a week for device support code (firmware, drivers and HALs)" part isn't even true for Pixels.
Doesn't the ASB get published at the same time as pixel updates? So by definition it's up to date.
- jeroenhd 1y agoYes, but vulnerabilities don't always get backported to older (supported) devices immediately. I distinctly recall one case where an Android CVE was patched months later on one Pixel model compared to the others that were in support. However, because search engines have all become terrible in the age of AI, I can only find vague references. I did, for instance, find a case where Google Project Zero published a blog post on a vulnerability while their Pixel 6 was still four days away from the first updates: https://9to5google.com/2023/03/20/pixel-6-march-2023-update/ https://9to5google.com/2023/03/20/pixel-6-march-2023-update/ I myself regularly find my Pixel only noticing updates half a month later unless I manually check while my Samsung tablet notifies me immediately once my quarterly update is available. It's quite annoying to have to check for updates manually every week, but I suppose updates are technically available.
- strcat 1y ago> Doesn't the ASB get published at the same time as pixel updates? So by definition it's up to date. Android Security Bulletin are standalone backports of High and Critical severity security patches to older initial yearly releases. Those older releases are currently Android 13, 14, 15 and 16. They're not the full security patches. Many backports included in the ASB were often included in the stable OS updates a month or two earlier. There are 2 officially supported paths for updates: 1) The path taken by Pixels of shipping each monthly, quarterly and yearly OS release in the month they come out, which they always do unless something goes very wrong and an update is pulled without them having a replacement ready. It's extremely rare for them not end up rolling out the latest OS release to users. 2) The path taken by most non-Pixel OEMs where they stick with an initial yearly release and apply Android Security Bulletin backports, eventually moving to a new initial yearly release. Pixels have never really used this, with the exception of the Pixel 8a and Pixel 9a launching on a branch of the previous quarterly release and then moving to the regular OS releases with the next quarterly/yearly release. That's a special case at launch from them saving resources. GrapheneOS follows the Pixel path and would need to make that work on hardware not doing it if we supported it. That would mean dealing with issues created by relying on the forward compatibility system (Treble) and not having improvements to the device support code tied to newer Android releases. Our hardware requirements require that this would work and that they would be providing the OS updates for the lower level code without a huge delay. Using older code below the OS layer would also mean not building it with the OS but rather separately, and would imply that it's probably a lot more closed source than Pixels were.