Graphene Lock/Unlock in Fastboot - everything deleted now?

Giraffa4

hello,

I had a problem with an app which detected that the phone is not on a stock rom.

So I looked up, that problem in the inet. On every start there was the message bootloader is unlocked. So I thought thats the problem. Next thing: I tried to to lock it.

I went with power and Vol - in fastboot mode and typed into console in Linux: fastboot flashing lock

I restarted the phone, everything is gone. So I went back to fastboot: fastboot flashing unlock. It boots still into the start window of grapheneos in which you decide language etc. So it looks like everything is deleted. Am I right?

I made my first backup last week with seedvault. Does it make a backup of all of my 3 profiles? or just the profile I am currently in? Is there any chance to get back without backup?

Thanks, farin

strcat

Giraffa4 You're meant to lock as part of installing GrapheneOS. Your installation wasn't fully completed.

https://grapheneos.org/install/web#locking-the-bootloader
https://grapheneos.org/install/cli#locking-the-bootloader

The installation guides explain that this really needs to be done before using the OS at all because it enables important security features and will wipe data when you do it.

Giraffa4

Yes, thats right. I did not complete the installation process. Can somebody tell me why I cant backup/restore certain apps with seedvault?

intelligence

Giraffa4 The manifest of each application provides instructions to the OS about whether or not it is allowed to perform a backup. Seedvault respects this instruction.

GrapheneOS

intelligence Android 12 changed the meaning of allowBackup="false" for apps targeting API 31 to mean disabling cloud backups rather than all backups. API 31 or above is required for all app updates and new apps on the Play Store since November 2022, so actively developed apps are almost all on API 31 or above and don't have disabled backups. The legacy file exclusion system was similarly changed to only apply to cloud backups. The new file exclusion system differentiates between cloud vs. device-to-device backups, and Seedvault is considered a device-to-device backup. For cloud backups, the new exclusive system differentiates between end-to-end encrypted (E2EE) and non-E2EE.

Only apps which explicitly choose to use the new API 31+ backup file exclusion system and explicitly exclude files from device-to-device backups will have their data omitted from the backups. The reason this is supported is because app data is often specific to the installation or device. Apps can define a backup service which converts data to and from a portable format and can exclude the non-portable format. It's also common to exclude login tokens from backups since logins are meant to be per-device for correctness and proper user control over login sessions rather than devices sharing sessions.

It does not work the way it used to work. It is true that the app ecosystem outside the Play Store tends to have very outdated target API levels which has a negative impact on privacy, security and usability. This is mainly an issue because other app stores aren't enforcing any target API level standard. It's unfortunate they aren't at least enforcing the same standard as the Play Store.

GrapheneOS

@intelligence Please read https://grapheneos.org/install/web#verifying-installation and educate yourself about what verified boot provides before making claims about it. The primary purpose of verified boot is defending against remote attackers by preventing modifying the OS after a successful compromise through exploitation. This means users can very reliably purge a remote attacker's presence from the device by wiping data from recovery. It also makes it much more difficult for them to keep privileged control over the device and hide their presence to stop the user from suspecting a compromise and wiping it. GrapheneOS users also benefit from the ability to verify their GrapheneOS installation without trusting the computer they used to install it. Verified boot and hardware-based attestation are very useful security features and GrapheneOS users heavily benefit from them. Verified boot supports a key chosen by the user for the OS which is used by GrapheneOS.

GrapheneOS provides substantial enhancements to verified boot compared to standard Android 13. Our improvements are partially covered at https://grapheneos.org/features#anti-persistence. We also provide our Auditor app taking advantage of hardware-based attestation to give users powerful tooling for detecting compromises. This will be able to do a lot more in the future compared to the limited set of features it currently provides. Auditor is much more useful to GrapheneOS users than on the stock OS due to the verified boot improvements we provide.

intelligence

GrapheneOS This means users can very reliably purge a remote attacker's presence from the device by wiping data from recovery

Requires PHYSICAL access. If physical security can be guaranteed, then everything else about it is moot.

intelligence

GrapheneOS Only apps which explicitly choose to use the new API 31+ backup file exclusion system and explicitly exclude files from device-to-device backups will have their data omitted from the backups.

To me that reads as any application can still say "no backups", just that they've rejigged it a bit.

GrapheneOS

@intelligence Please read the linked information from our install guide and the response that was given to you here. Verified boot primarily defends against remote attackers, not attackers with physical access. Verified boot prevents an attacker that has remotely compromised the OS via exploitation from modifying the OS. This limits what they can do and makes it harder for them to preserve their control over the device without being detected. It means that wiping data in recovery purges their presence, since they cannot modify the firmware or OS, so recovery still functions as intended, and the persistent state they can modify to include malicious apps and change permissions gets wiped by that factory reset functionality.

Hijacking this thread really isn't appropriate.

GrapheneOS

intelligence The issue of many apps disabling backups because they didn't want cloud backups via Google Play is fully resolved for apps that are actively developed and published through the Play Store as at least one place where they publish their app, since they had to move to targeting API 31 or later. It's possible for apps to very explicitly exclude all of their files from device-to-device backups and very few apps are going to do that. The reason many apps were disabling backups before was a mix of privacy concerns with cloud backups and wanting to limit bandwidth / storage usage. Many apps can end up storing far too much data for automatically doing cloud backups for all of it to be reasonable. There is only still any significant issue for apps published only outside the Play Store which are sticking with ancient target API levels, which is a privacy and security issue since older API levels provide weaker privacy and security. There's going to be an enforced minimum API level in Android 14 (likely API 23 initially, i.e. targeting Android 6 or above) instead of only a warning.

GrapheneOS

Signal encrypts their database with the hardware keystore so without the file exclusion system, backing it up would simply waste space and the data wouldn't be usable after restore. It would cause errors until wiping the app data. App data is often not portable across architectures, phone models, OS variants, OS installations, etc. for one reason or another. For example, a camera app will have a bunch of things specific to what the device supports and would need to explicitly handle backup/restore by either splitting up settings into portable and non-portable to exclude the non-portable ones or by detecting that settings are now set to unsupported values for the current device. This can be quite problematic for a lot of apps.

This is really not what the topic of the thread was about. The person who created the thread can back up the vast majority of their data with Seedvault, can make a separate manual backup of their home directory and can do manual backups for apps like Signal with their own encrypted backup/restore system. Signal could support device-to-device backups despite the hardware keystore encryption via their own backup service but they choose not to do it because they don't like trusting OS backup services. Most apps do not do what Signal does and get backed up and restored properly. Signal has their own encrypted backup/restore so users just need to know that needs to be used too.