Graphene isn’t the best choice for everything. It doesn’t have good backup solutions nor device to device backup or anything solid for complete snapshots and when restoring your so called backups you’ll realize what all it truly lacks.
It’s hardened and has a lot of security and privacy features but none of that matters if your opsec is bad, or it’s feature set doesn’t match your threat model. I am not knocking it at all. It just isn’t the white knight for every case.
Seedvault works, I’ve restored from backups multiple times.
However there are still many parts of overall data that aren’t fully backed up.
Certain app data doesn’t get saved.
Settings are but not in entirety requiring manual rechecks of all settings and reconfiguration if needed. Which saves no time because then you cannot trust it fully for what was and was not altered meaning you then must asses everything which took away the total value, and adds a layer of distrust.
Profiles must be backed up individually which creates a giant hassle to restore/maintain consistent backups, which also requires different drives for each profile to be recognized correctly.
App lists are impartial requiring a wrote down list or some form of rememberance that’s not reliant on the backup list of installed apps.
I can go on with more its late in my time zone and I have to sleep so. It’s a good project and has merit. It is just not where it should be to really be useful at scale. I am aware of the experimental setting to create a more comprehensive backup. Even with it checked on the backups are not complete. Thus the use of Graphene while a great project has definite major flaws. If they implement device to device backups it would be a game changer. Not high up on their list of to dos though.
Thanks for the info. I have not really tested Seedvault myself so this is all good to know.
Ironically, one of the main reasons I switched to GrapheneOS was because Google’s backups were so frustrating and I was hoping Seedvault would be more comprehensive.
It is and its not. You just have to know the limitations, some of which I mentioned. Try it for yourself and to a restore then report back you’ll understand it’s very cumbersome in some ways.
Don’t expect to be able to wipe a phone and restore from backup like you never left it’ll get you closeish. So you need to ask yourself is that good enough for you with your opsec and threat model? To only have part of your data back…
In its current form its just a hassle right now to create backups on seperate drives (not even partitions on one drive I tried, as seedvault and the OS only identifies the drive you don’t get to choose) for each profile plugging them into your phone individually, backing up each one, and keeping them up to date often, it’s a lot! I have swapped several pixels and profiles I hate doing it everytime it really is a subpar process. I AM ALL EARS FOR A BETTER SOLUTION. Having to piece your data back together for it to be complete again doesn’t sit right with me to be considered backed up correctly. It leaves you vulnerable and some of us don’t like being locked into any specific device or situation like having your life on a device and being at the mercy of it for any reason you might encounter. I’m actually moving away from graphene due to these issues. It’s just not there yet.
Its one thing to read the documentation and another to have experience in using the software first hand which is why I got downvotes, over time, daily those are the ones who have experienced what I mean. I just wanted people to be aware that it’s not the saving grace yet.
Imagine the real world use case of backups and maintenance which should be done as often as possible as to lose as little data as possible. Phone gets broken, stolen, confiscated, what have you. Having reliable backups is the difference between starting over and continuing with what could be your entire life in this digital age.
I’m being bugged by Seedvault caring for apps that have a ‘don’t backup app data’ flag.
I could live with that being a default setting, which can be manually overwritten in the Seedvault settings for these apps.
Apps not allowing (in case of Seedvault: encrypted) full backups while offering no or bad built-in backups is just cumbersome when trying to have current backups.
I believe you’re right, but that doesn’t solve the problem of making routine full backups, which would come in handy if the device gets lost or breaks.
One can hope future versions of Seedvault care less about what apps want.
The project has sort of silo’d itself into security which is only one part of the equation. Rather than overall completeness, functionality, maintainability. It’s lacking major fundamental feature sets. Thus its more of a tails meets whonix/Qubes right now not a all in one bow wrapped package to save the day for its consumer base. Many many other issues/bugs I didnt list. Perhaps I’ll add more tomorrow. If everyone wants.
And that’s exactly what it should be IMO. I prefer a project with narrow goals to one that does everything, but poorly.
If I want backups, I can use something like Syncthing. When moving to a new device, I prefer to install everything from scratch because I generally don’t use most of the apps I have anyway. I don’t put anything critical on it, so why would I need to restore from a snapshot?
If you want those features, it’s not the ROM for you.
I just want a simple device with a long support cycle and no spyware, and GrapheneOS delivers. I have Google Play Services on a seperate profile, and my main profile is completely free of that crap. I want a Linux phone, but every phone has serious limitations, like missing audio, sketchy calls, or completely broken camera. GrapheneOS is the closest experience I have to that.
If I want backups, I can use something like Syncthing.
syncthing cant backup your device. that is a file transfer app. for backing up the device you need either appmanager and root, or good old dd and root (and a half shutdown system)
I don’t put anything critical on it, so why would I need to restore from a snapshot?
because not everyone uses the device the same way as you
snapshots are always complete. file based backups are not because of metadata changes. seedvault even less because it picks apps except this and that, and an unknown subset of the settings, and shared storage for the files that you have enabled
If you want those features, it’s not the ROM for you.
currently there’s no ROM on which you could execute a real backup, thanks to encrypted storage with keys stored in TPM. TPM sees a change, and now your backup is a useless blob of practically random data
I just want a simple device with a long support cycle and no spyware, and GrapheneOS delivers.
as does calyx os
I have Google Play Services on a sperate profile, and my main profile is completely free of that crap. I want a Linux phone, but every phone has serious limitations, like missing audio, sketchy calls, or completely broken camera.
with microg, this can be done on calyx too. there’s even a few options on how much you want google to know.
and if your point is that not all apps work with microg, then you would never actually move to a linux phone because that will never have google play services (hopefully, else something has gone way wrong), probably not even microg or apps that would depend on it
syncthing cant backup your device. that is a file transfer app.
That’s exactly what backup software is, it’s keeping copies of important data in multiple places so if one dies/gets stolen, you have backup copies.
I can tell syncthing to copy all my important data to another device.
I don’t need all the installed apps or a disk image, that’s way overkill. I could do that, but it’ll get way more than I need.
as does calyx os
You’re right, Calyx OS is also a good choice.
I went with GrapheneOS for two reasons:
sandboxed Google Play vs microG - no option AFAIK to disable it
faster security updates
My goal is a baby step toward Linux phones, not compatibility with Android. I only have Google Play Services on a separate profile, and I spend 95% of my time on the profile without it. The less I rely on Google Play Services, the easier it’ll be for me to transition to Linux alternatives.
Better app compatibility is a nice side effect. I have a handful of apps that rely on Google Play Services, and there’s a decent chance they wouldn’t work on microG. But I rarely use them and I’m willing to go without if it means I can have a Linux phone.
sandboxed Google Play vs microG - no option AFAIK to disable it
you mean disabling microg?
if so you can refuse installation at profile setup. if you make a new profile, you can choose to install it there. then in microg settings there are some toggles for functionality
Google Watch - only use for payments, app is needed to refresh payment tokens
Sensi - smart thermostat - I had trouble adding to Home Assistant, will probably try again at some point
a few random apps I can live without
If I had a viable Linux phone, I’d keep my old Android device around for the above, assuming they don’t work with the emulator (Google Watch probably won’t).
And that’s cool that microG can be disabled. I could maybe live with slower updates, so it sounds viable, assuming the above work.
I agree. Seedvault works but if you really use the project and its features as intended you’ll see problems I listed above which is not complete I’m just tired there are plenty more.
You’ll start to see the problems and the lack of value add from graphene. I’d feel much safer on a Linux machine and correct backups, under most threat models and opsecs, even without all the advanced security features than stuck locked into graphene as a half baked project. Which is saying something, and why I said it depends on your opsec and threat model I wasn’t bashing the project it just is not the end all be all right now.
The year of Linux is upon us. Soonish*
Its had more dev time across the board which is why I would choose it first and foremost. What it lacks in certain features its fundamentally more complete. Regardless of distro mostly.
Graphene isn’t the best choice for everything. It doesn’t have good backup solutions nor device to device backup or anything solid for complete snapshots and when restoring your so called backups you’ll realize what all it truly lacks.
It’s hardened and has a lot of security and privacy features but none of that matters if your opsec is bad, or it’s feature set doesn’t match your threat model. I am not knocking it at all. It just isn’t the white knight for every case.
What’s wrong with Seedvault?
Seedvault works, I’ve restored from backups multiple times.
However there are still many parts of overall data that aren’t fully backed up.
Certain app data doesn’t get saved.
Settings are but not in entirety requiring manual rechecks of all settings and reconfiguration if needed. Which saves no time because then you cannot trust it fully for what was and was not altered meaning you then must asses everything which took away the total value, and adds a layer of distrust.
Profiles must be backed up individually which creates a giant hassle to restore/maintain consistent backups, which also requires different drives for each profile to be recognized correctly.
App lists are impartial requiring a wrote down list or some form of rememberance that’s not reliant on the backup list of installed apps.
I can go on with more its late in my time zone and I have to sleep so. It’s a good project and has merit. It is just not where it should be to really be useful at scale. I am aware of the experimental setting to create a more comprehensive backup. Even with it checked on the backups are not complete. Thus the use of Graphene while a great project has definite major flaws. If they implement device to device backups it would be a game changer. Not high up on their list of to dos though.
Thanks for the info. I have not really tested Seedvault myself so this is all good to know.
Ironically, one of the main reasons I switched to GrapheneOS was because Google’s backups were so frustrating and I was hoping Seedvault would be more comprehensive.
It is and its not. You just have to know the limitations, some of which I mentioned. Try it for yourself and to a restore then report back you’ll understand it’s very cumbersome in some ways.
Don’t expect to be able to wipe a phone and restore from backup like you never left it’ll get you closeish. So you need to ask yourself is that good enough for you with your opsec and threat model? To only have part of your data back…
In its current form its just a hassle right now to create backups on seperate drives (not even partitions on one drive I tried, as seedvault and the OS only identifies the drive you don’t get to choose) for each profile plugging them into your phone individually, backing up each one, and keeping them up to date often, it’s a lot! I have swapped several pixels and profiles I hate doing it everytime it really is a subpar process. I AM ALL EARS FOR A BETTER SOLUTION. Having to piece your data back together for it to be complete again doesn’t sit right with me to be considered backed up correctly. It leaves you vulnerable and some of us don’t like being locked into any specific device or situation like having your life on a device and being at the mercy of it for any reason you might encounter. I’m actually moving away from graphene due to these issues. It’s just not there yet.
Its one thing to read the documentation and another to have experience in using the software first hand which is why I got downvotes, over time, daily those are the ones who have experienced what I mean. I just wanted people to be aware that it’s not the saving grace yet.
Imagine the real world use case of backups and maintenance which should be done as often as possible as to lose as little data as possible. Phone gets broken, stolen, confiscated, what have you. Having reliable backups is the difference between starting over and continuing with what could be your entire life in this digital age.
I’m being bugged by Seedvault caring for apps that have a ‘don’t backup app data’ flag.
I could live with that being a default setting, which can be manually overwritten in the Seedvault settings for these apps.
Apps not allowing (in case of Seedvault: encrypted) full backups while offering no or bad built-in backups is just cumbersome when trying to have current backups.
afaik their device-to-device mode should be able to workaround that. it can still be saved to storage
I believe you’re right, but that doesn’t solve the problem of making routine full backups, which would come in handy if the device gets lost or breaks.
One can hope future versions of Seedvault care less about what apps want.
Agreed.
That said, it would be awesome to have an alternative to Pixel devices if you do want GrapheneOS.
The project has sort of silo’d itself into security which is only one part of the equation. Rather than overall completeness, functionality, maintainability. It’s lacking major fundamental feature sets. Thus its more of a tails meets whonix/Qubes right now not a all in one bow wrapped package to save the day for its consumer base. Many many other issues/bugs I didnt list. Perhaps I’ll add more tomorrow. If everyone wants.
And that’s exactly what it should be IMO. I prefer a project with narrow goals to one that does everything, but poorly.
If I want backups, I can use something like Syncthing. When moving to a new device, I prefer to install everything from scratch because I generally don’t use most of the apps I have anyway. I don’t put anything critical on it, so why would I need to restore from a snapshot?
If you want those features, it’s not the ROM for you.
I just want a simple device with a long support cycle and no spyware, and GrapheneOS delivers. I have Google Play Services on a seperate profile, and my main profile is completely free of that crap. I want a Linux phone, but every phone has serious limitations, like missing audio, sketchy calls, or completely broken camera. GrapheneOS is the closest experience I have to that.
syncthing cant backup your device. that is a file transfer app. for backing up the device you need either appmanager and root, or good old dd and root (and a half shutdown system)
currently there’s no ROM on which you could execute a real backup, thanks to encrypted storage with keys stored in TPM. TPM sees a change, and now your backup is a useless blob of practically random data
as does calyx os
with microg, this can be done on calyx too. there’s even a few options on how much you want google to know.
and if your point is that not all apps work with microg, then you would never actually move to a linux phone because that will never have google play services (hopefully, else something has gone way wrong), probably not even microg or apps that would depend on it
That’s exactly what backup software is, it’s keeping copies of important data in multiple places so if one dies/gets stolen, you have backup copies.
I can tell syncthing to copy all my important data to another device.
I don’t need all the installed apps or a disk image, that’s way overkill. I could do that, but it’ll get way more than I need.
You’re right, Calyx OS is also a good choice.
I went with GrapheneOS for two reasons:
My goal is a baby step toward Linux phones, not compatibility with Android. I only have Google Play Services on a separate profile, and I spend 95% of my time on the profile without it. The less I rely on Google Play Services, the easier it’ll be for me to transition to Linux alternatives.
Better app compatibility is a nice side effect. I have a handful of apps that rely on Google Play Services, and there’s a decent chance they wouldn’t work on microG. But I rarely use them and I’m willing to go without if it means I can have a Linux phone.
you mean disabling microg?
if so you can refuse installation at profile setup. if you make a new profile, you can choose to install it there. then in microg settings there are some toggles for functionality
btw, which of your apps nead google services?
If I had a viable Linux phone, I’d keep my old Android device around for the above, assuming they don’t work with the emulator (Google Watch probably won’t).
And that’s cool that microG can be disabled. I could maybe live with slower updates, so it sounds viable, assuming the above work.
Seedvault worked fine for me when I moved phones last year.
I agree. Seedvault works but if you really use the project and its features as intended you’ll see problems I listed above which is not complete I’m just tired there are plenty more.
You’ll start to see the problems and the lack of value add from graphene. I’d feel much safer on a Linux machine and correct backups, under most threat models and opsecs, even without all the advanced security features than stuck locked into graphene as a half baked project. Which is saying something, and why I said it depends on your opsec and threat model I wasn’t bashing the project it just is not the end all be all right now.
The year of Linux is upon us. Soonish*
Its had more dev time across the board which is why I would choose it first and foremost. What it lacks in certain features its fundamentally more complete. Regardless of distro mostly.