I'm not even really sure what you mean by "manufacturer updates".
The more I hear about this project, the less is sounds like an alternative OS and more it sounds like a thin skin around whatever shit Google throws out, to be honest.
I have trouble understanding why this is different on mobile devices. People keep speaking of blobs but that doesn't seem to be a thing in laptop/desktop hardware, unless they mean something like the firmware running on your wifi card and uefi chip? But those can be interfaced with from any kernel version, afaik, so I don't get it
That's a dependency: if you want your system to be secure, you depend on the software running on your system to be patched when a security flaw is published.
The attack vectors against this firmware are virtually always physical right? As in, hardware access in one way or another (including radio waves reaching the device), not something that can be routed over a (cell) network
If you have an EOL Pixel and a new major version of Android is released, Google will not port this new version of Android (and therefore AOSP) to it. So GrapheneOS would have to do it. GrapheneOS just say they don't have the resources to do that, so they follow the Google releases. Could you keep an EOL Pixel without receiving updates? Sure. But then it's not supported anymore, it's just outdated, insecure software.
> I'm not even really sure what you mean by "manufacturer updates".
There are the AOSP updates (which bring new features, but importantly in our case bring security fixes) that come from Google, but your phone is more than that. There is a bunch of hardware running in your phone and a bunch of firmwares exposing it. Say your camera, or your wifi module, etc. If there is a security issue in the firmware of the camera, then it won't be fixed in the AOSP codebase. You need the camera manufacturer to fix it and release a firmware, pass it to the phone manufacturer who will then deploy it on your phone.
Google split both of those concepts years ago in order to deploy Android updates faster and make everybody more secure, because manufacturers had a tendency to lag a lot. Some still do but the situation generally improved, I think. Anyway, you need to receive those security updates from your manufacturer because they are independent from Google.
> the less is sounds like an alternative OS and more it sounds like a thin skin around whatever shit Google throws out, to be honest.
If you think that AOSP is shit, then sure. I mean, if you think that the Linux kernel is shit, maybe you don't want to run a Linux distribution.
I personally think that AOSP is pretty great, and vastly superior to Linux on mobile (among other because it has a much better security model). I am not a big fan of Google being root on my phone (with Android and system apps like Play Services), which is something that GrapheneOS fixes (by making Play Services run like any other, unprivileged app). GrapheneOS is also adding privacy features, be it by proxying your location requests (so that they go through the GrapheneOS servers instead of directly to Google) or by adding features like "scopes", where you can choose exactly which contact you share with an app, for instance, or refuse Internet access to an app without breaking it (GrapheneOS will just make the app believe that it has the permission to access the internet but there is just no connection right now). And of course GrapheneOS hardens the system in terms of security (e.g. with a hardened malloc or memory tagging stuff that Apple recently introduced as well).
So yeah, it is relatively thin, because AOSP is a huge codebase. But it doesn't mean that it's worthless: this skin makes it more secure, more private, and for me more enjoyable than Android.
I think breaking away from open source Google code is not really meaningful. It's kinda like saying "I don't want to run Linux because it contains code from IBM/Google/Meta". AOSP is a great and useful project. If the day that Google stops releasing AOSP ever comes, a consortium of interested organizations can fork it. But it does not make a whole lot of sense to start a new mobile ecosystem completely from scratch, if one that is great and open source already exists and buys you compatibility with millions of apps.