No automatic app updates, needing to prompt users to install or remove apps, needing to ask for a battery optimization exception, needing to run a foreground service, etc. Of course, every service provider has all these restrictions unless an OEM bundles their stuff in the OS.
Conversation
This Tweet was deleted by the Tweet author. Learn more
Neither of those things requires / involves root access when done properly. Backup services need to be built into the OS for important security reasons. However, it's entirely possible to have a generic encrypted backup service supporting any sync service via SAF, etc.
1
This Tweet was deleted by the Tweet author. Learn more
GrapheneOS still maintains the OS security model including the application security model. It has nothing to do with what you claim.
Don't need to be have it explained why you think things are designed the way they are as someone deeply involved in implementing these things.
1
This Tweet was deleted by the Tweet author. Learn more
If you strongly disagree with it then it's hard to see how you can respect my work when nearly all of it is built around that OS and application security model. There's not much point in it if that's not there as the baseline holding it all together.
1
This Tweet was deleted by the Tweet author. Learn more
I'm not making any personal attacks. You're here making ignorant claims, disparaging my work and misrepresenting things. GrapheneOS doesn't have misguided incentives behind enforcing the extremely valuable application security model and sandbox in the production (user) builds.
1
All of the hardware we currently officially support has full support for installing another OS, your own builds of the OS or someone else's builds. If you don't want our secure releases, don't use those. We're entirely willing to release a phone with an immutable root of trust.
1
If you don't want that, don't buy it. In all likelihood, we'd give users the choice between an immutable root of trust and support for unlocking + flashing a custom verified boot key + locking. That's the ideal: you choose the compromise you want, and you're responsible for that.
Since doing that does not actually require producing different hardware but rather flashing an eFuse with a different bit read by the late stage bootloader and used to decide if it should support using a custom key. It's an option we'd definitely want to support if possible.