6 ms·

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

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.

DaiPlusPlus 2y ago
> 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.
- DaiPlusPlus 2y ago
  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/read-only-access-for-pst-file/e65ff8d5-360e-4d04-b374-aa9a6e8efa73 https://answers.microsoft.com/en-us/outlook_com/forum/all/re...
- Ferret7446 2y ago
  > 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).
weejewel 2y ago
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.
dotancohen 2y ago
Can Thunderbird not import the big .mbox files?

DaiPlusPlus 2y ago

> 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.

DaiPlusPlus 2y ago
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/read-only-access-for-pst-file/e65ff8d5-360e-4d04-b374-aa9a6e8efa73 https://answers.microsoft.com/en-us/outlook_com/forum/all/re...
Ferret7446 2y ago
> 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).

weejewel 2y ago

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.

dotancohen 2y ago

Can Thunderbird not import the big .mbox files?