Command-Line Utility to Backup Google Mail, Calendar and Contacts to Files(github.com)
github.com
Command-Line Utility to Backup Google Mail, Calendar and Contacts to Files
https://github.com/WeeJeWel/node-google-backup
31 comments
> 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.
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...).
[1] https://answers.microsoft.com/en-us/outlook_com/forum/all/re...
[1] https://answers.microsoft.com/en-us/outlook_com/forum/all/re...
> 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).
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.
Can Thunderbird not import the big .mbox files?
Looks handy, although it only grabbed like the first 2 years of gmail for me, out of 20. Re-running the docker image did not help.
I had a similar problem. I've submitted an issue.
https://github.com/WeeJeWel/node-google-backup/issues/1
https://github.com/WeeJeWel/node-google-backup/issues/1
That’s now fixed!
What benefit does this have vs Google Takeout?
My Google takeout doesn't work because it requires a 2FA from Google authenticator which I no longer have.
You could attempt to get that 2fa removed by trying to sign in from a new device and following the steps to recover your account.
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.
Good luck recovering when you're nowhere logged in
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.
[deleted]
We don't know if they're logged in or not, they did not specify
You replied to my comment about logging in just fine.
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...
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...
Does the .eml file preserve Gmail labels?
Does it handle the 'labels apply to messages not threads' problem?
I prefer an executable file to node.js garbage even if I have a Docker. Does anybody have a ready-to-use alternative that is not written on JS?
sounds like you have an itch that needs scratching - go for it!
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.