TBH I would actually expect GrapheneOS not to disable these checks. GrapheneOS devs pride themselves to have the best implementation of the official Android security model, and enforcing signature checks is likely part of that…
They might add additional certificates I guess, to allow their own apps, and maybe a selected few others.
Well… The Android security model, as it is implemented in stock android and GOS, is about top down control, the full trust is given to the system vendors, not the end users. No rooting for instance. From this perspective not allowing installation of apps that cannot be blocked by the system vendor, fits well with that model.
TBH, I am not a fan of that security model. And this is my critique of GOS. It doesn’t allow the user full access to their device, so that they can check and control what each application is storing or sending to third-party servers. Instead it is on full security and allows apps to store and transfer information to which the user has no access to.
But the system vendor/developers would have that access, because they control the whole base system.
The focus of the Android security model and in turn of GOS is on security, at the cost of privacy or freedom.
This is incorrect. The sideloading checks are implemented in Play Protect, which needs elevated privileges to function. On GrapheneOS, Google Play services run with normal privileges, just like any other user-installed app. This means, there are no Play Protect checks in GrapheneOS, and there will never be. It would only be possible on ROMs, such as LineageOS with Gapps, where Play services are installed as system apps, running with higher privileges than all other apps.
I was thinking more about the way of Android security models, and that it would make sense for GOS to restrict available storefronts to stay consistent with their way to implement them. But good to know that it will not automatically happen just by updating the google services.
And I would also think that people would likely complain if they where to implement it in a different way.
Sandboxed Google Play is one of the key features of GrapheneOS. So far no other OS has allowed users to enjoy the full functionality of Android Auto, the Pixel LPA for managing eSIMs, and the Google Mobile Services suite (not talking about the other Pixel OS stuff) with the only exception being GPay, without full sandboxing, and without granting excessive privileges (SGP is unprivileged, the eUICC LPA obviously requires higher privileges for managing eSIMs, but it’s fully sandboxed and can’t communicate with Play services, or access the internet)
TBH I would actually expect GrapheneOS not to disable these checks. GrapheneOS devs pride themselves to have the best implementation of the official Android security model, and enforcing signature checks is likely part of that…
They might add additional certificates I guess, to allow their own apps, and maybe a selected few others.
Except this ‘signing’ is more of a control feature than a security feature. Just because Google markets it as a security feature doesn’t mean it is.
Well… The Android security model, as it is implemented in stock android and GOS, is about top down control, the full trust is given to the system vendors, not the end users. No rooting for instance. From this perspective not allowing installation of apps that cannot be blocked by the system vendor, fits well with that model.
TBH, I am not a fan of that security model. And this is my critique of GOS. It doesn’t allow the user full access to their device, so that they can check and control what each application is storing or sending to third-party servers. Instead it is on full security and allows apps to store and transfer information to which the user has no access to.
But the system vendor/developers would have that access, because they control the whole base system.
The focus of the Android security model and in turn of GOS is on security, at the cost of privacy or freedom.
This is incorrect. The sideloading checks are implemented in Play Protect, which needs elevated privileges to function. On GrapheneOS, Google Play services run with normal privileges, just like any other user-installed app. This means, there are no Play Protect checks in GrapheneOS, and there will never be. It would only be possible on ROMs, such as LineageOS with Gapps, where Play services are installed as system apps, running with higher privileges than all other apps.
Well, good to know.
I was thinking more about the way of Android security models, and that it would make sense for GOS to restrict available storefronts to stay consistent with their way to implement them. But good to know that it will not automatically happen just by updating the google services.
And I would also think that people would likely complain if they where to implement it in a different way.
Sandboxed Google Play is one of the key features of GrapheneOS. So far no other OS has allowed users to enjoy the full functionality of Android Auto, the Pixel LPA for managing eSIMs, and the Google Mobile Services suite (not talking about the other Pixel OS stuff) with the only exception being GPay, without full sandboxing, and without granting excessive privileges (SGP is unprivileged, the eUICC LPA obviously requires higher privileges for managing eSIMs, but it’s fully sandboxed and can’t communicate with Play services, or access the internet)