got-your-back uses Gmail's API instead of IMAP with an insecure app password, which is a discouraged way of accessing Gmail and will eventually be phased out in favor of OAuth access tokens over IMAP (in fact, I thought it already had been).
As for other services beyond Gmail, there's not a great ecosystem for exporting.
For one-off exports, Google Takeout is decent enough, although there's a lacking ecosystem to import the big .mbox files back to an email provider.
> insecure app password [...] and will eventually be phased out in favor of OAuth access tokens over IMAP
What's so "insecure" about "per-app passwords"?
I ask, because I've lost the past 5 years of my life to building and running an internet-facing OAuth2+OIDC IAM system and I'm (still) an active contributor back to the open-source OIDC framework it's built-on. I grok the grants and flows and I've got the blood-pressure to show for it (and developed a healthy opposition to SAML); but despite all of that, I appreciate simple solutions to problems where there's a very real risk of over-engineering - and especially when a simpler system (like per-app passwords) can make a system overall more secure because there will be less mistakes being made, even if some clinicaly-dry technical assessment mathematically proves the complex solution is more "secure" by some measure.
///
> although there's a lacking ecosystem to import the big .mbox files back to an email provider.
Everyone I know (okay, just a handful of ("normal") people) who has done this ended-up converting the .mbox to a PST for Outlook and copied it over to any other machines they have; it's an archive mailbox after-all, so just put it in read-only mode and don't worry about data-synchronization issues.
Kinda ironic that Gmail's credibility was/is built on ex-Outlook users looking for something better, only for Outlook to be the refuge (and last resting place?) for hundred-gigabyte-sized e-mail archives.
I need to supply a correction: apparently Outlook does not support opening PST files[1] that are protected as read-only by the filesystem (which is both disappointing and alarming...).
> a simpler system (like per-app passwords) can make a system overall more secure because there will be less mistakes being made
But a mistake WILL be made, because humans are fallible, and mistakes with a long lived bearer token can be extremely damaging, and can remain latent for a long period of time (e.g., password accidentally saved on disk and "deleted").
With proper OAuth, a lot of mistakes can be practically harmless (e.g., access token accidentally saved somewhere).
I didn’t know about that. However, I explicitly wanted to avoid having users to create an OAuth project because it’s a hassle. Also these tokens can expire if they’re not refreshed after a while.
There is also vdirsyncer for contacts and calendar, also allows you to keep it in sync between services - it's great if you want to store a copy locally on a caldav / carddav server.
The issue isn't 2fa it's Google authenticator. When I log in from a new device lets me log in using my phone as 2fa but that is not an option for takeout -- only authenticator. I can find no way to remove it.
Google authenticator is a type of 2FA. They are saying that if you can figure out a way to remove 2FA from your account, then you can re-add it with the current authenticator app you have, which will allow you to use Takeout.
Back in 2018 I was able to recover a long-lost account by answering questions about when i created it and confirming an old phone number attached to it.
Nice but... Backup is nothing without restore and actually "restore" for third party services on a closed proprietary infra it's not possible...
My way for mails is simply having local maildirs using mails via notmuch and serving the maildir if needed via local dovecot/with an eventual MailPile/Rainloop etc webmails, for contacts Davis (like Radicale or Baikal) with DavX⁵ on Android etc, IOW the sole way I fond is being able to use someone else service if I need it (for instance not to end up in spam on all web giants mails) but still owning my infra. Just having data I can't really use it's not enough unfortunately...
It's preferring something that doesn't come from a diseased and unhinged ecosystem that not only involves a consistent tragedy of the commons, but also has tooling that is quite honestly just horrific.
As for other services beyond Gmail, there's not a great ecosystem for exporting.
For one-off exports, Google Takeout is decent enough, although there's a lacking ecosystem to import the big .mbox files back to an email provider.