For now, when companies let me have multiple passkeys, that's sufficient for me. I put one on my Apple Keychain and one in 1Password.
190 karma · joined May 31, 2008
Cheers.
For now, when companies let me have multiple passkeys, that's sufficient for me. I put one on my Apple Keychain and one in 1Password.
I’ll figure out the bug eventually either way, but having the compiler give me the clearer warning earlier in the development process (sometimes even from pure static analysis) is a significantly more pleasurable development experience and a potential time saver
And 50X that, especially the time saved, if I’m integrating with code you didn’t author.
- Utilities that are only useful to employees of those companies (cafeteria menus, shuttle schedules, resources for salespeople on the go, etc.).
- Pre-release/testing (aka dogfood) versions of the apps they distribute to the public, for employees to use and find bugs on before they make it out to normal users.
Neither of those are pools that Apple wants to play in.
...and I guess there's a third category:
- Apps used gain "competitive intelligence" and spy on users.
I think most/all of the companies in the program would say it's about controlling the distribution of their apps, since putting them on the App Store would expose them to the public, and less about hiding from Apple...
Do you have an Apple ID? You need an Apple ID to download apps from the App Store, and when you create the Apple ID, you accept their ToS. So, yeah, I think you did.
Though that ToS has absolutely nothing to do with anything we're discussing -- the ToS that matters here is the one between Apple and Google/Facebook.
> ...and that must constrain me to honor the terms of the app that I downloaded...
I don't think Apple's ToS with you constrains you to honors the terms of the app you downloaded. That seems strangely indirect. I think the app may or may not have their own ToS that they make you agree to at some point before permitting you to use their services.
Sure they do. You want a gun? That comes with certain restrictions on what you can do with it. You want a car? There are certain restrictions on what you can do with it. Jet? Restrictions. Schedule 1 drugs? Restrictions. Knives? Restrictions. Fireworks? Restrictions. Cameras? Restrictions. Hell, even when it comes to a 2x4, there are rules about what you can and can't do with it -- you can't hit someone with it, or you'll suffer consequences.
There will always be the possibility that some company will ask users to their absolute freedom ability to give them absolute freedom. Which is basically exactly what happened in this case. The only difference is, in this case, Apple built in a mechanism where they can stop individual actors.
And, to protect their users, they used it.
1. It depends if you don't trust them in the long term or the short term. In the long-term, after you finish the migration, there's no need for Fastmail to still have access to your account, and Google does let you revoke/cycle app passwords, so I would just do that and that would cut off Fastmail's access, even if they did retain your password (which, based on what I know about them, I doubt they'd do, but I don't know them personally).
2. For the actual transferring, if you don't want to use Fastmail's tool, I'm a big fan of imapsync, and my second best choice would be offlineimap. I like the former for my needs, where I do a lot of one-shot migrations/backups/restores, but the latter does have the benefit in your case that it can be run as a daemon, and then it'll slowly steadily upload your mail in the background over the course of however many days it'll take.
3. It should not take 7 days to move 15GB. I've done it in under 48 hours. Part of the bottleneck might be that your local machine/network/etc. I would try to fire up a VM with a cloud provider, preferably one of the fast-network variants, and run imapsync from there.