But if google goes on with locking out the app store with the developer verification bs, how would would this play into that? If Aurora won’t install the app or the app won’t run, then we’ve accomplished little in that area. I’m really hoping I’m missing something.
Nothing needs to be disabled, since it isn’t present in GrapheneOS in the first place. 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.
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)
But the app might refuse to run without those checks being done. Or a new format, apkx2 I don’t know, might only be able to be decrypted with the proper key and only once verification. It’s not a new tactic. I’m very, very glad to see this type of development finally happening (though, admittedly, a couple decades later than of hoped), but it’s now a new ballgame, and google owns the stadium, the seating pricing, and concessions, the parking lot, and ticketing counter. I’m concerned we’ve waited too long. What’s GOS’s plans for this? They’re, essentially, going to have to create a new ecosystem, with most of the growing pains of new ecosystems.
But if google goes on with locking out the app store with the developer verification bs, how would would this play into that? If Aurora won’t install the app or the app won’t run, then we’ve accomplished little in that area. I’m really hoping I’m missing something.
Custom ROMs should be able to disable the checks. My bigger concern is what it does to the open app ecosystem as a whole.
Nothing needs to be disabled, since it isn’t present in GrapheneOS in the first place. 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.
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)
But the app might refuse to run without those checks being done. Or a new format, apkx2 I don’t know, might only be able to be decrypted with the proper key and only once verification. It’s not a new tactic. I’m very, very glad to see this type of development finally happening (though, admittedly, a couple decades later than of hoped), but it’s now a new ballgame, and google owns the stadium, the seating pricing, and concessions, the parking lot, and ticketing counter. I’m concerned we’ve waited too long. What’s GOS’s plans for this? They’re, essentially, going to have to create a new ecosystem, with most of the growing pains of new ecosystems.