kngspook

My understand is the people behind passkeys are working on an import/export solution. Who knows when it'll happen though.

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.

Yeah, I hate these. It's also a very not-ergonomic was to sign in. I wish those companies would redirect those efforts to passkeys.

Does the hash end in ...e63f2 perchance, or is it a different dump?

I feel like someone should spin up a separate GCP account, make a pile of projects, and then spam-add every google engineer they can find. Curious to see what happens next…

Google Takeout is actually reasonably robust. I create/download one of those fairly regularly.

For me, a big part of the value of typehints isn’t just the legibility, it’s also helping the interpreter to help me. I can have the interpreter tell me that a string got passed into a function instead of the list of strings that I was expecting, or I can have have my code output a single letter instead of a whole word from the array access call in my code.

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.

Gmail I believe is technically encrypted at rest, just they also happen to have the keys.

I mean, it was Bing not too long ago...

Google blocks domains from Chrome all the time, for the same reason as Apple blocked Google: it was deemed malicious.

https://safebrowsing.google.com/

Google (or any company) wouldn't have a single point of failure for alerts like that. :P Those alerts would hit email, phone, etc. all at the same time.

No, Facebook/Google internal apps fall into two categories:

- 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 don't think it's about remind them who's boss. Apple will revoke the certs for as long as is necessary to protect their users, but I don't think they'll stay revoked for punitive purposes. I expect it'll be a period measured in double-digit hours, not weeks.

> The whole point of enterprise certificates was to allow creation of internal apps that even Apple shouldn't know about.

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

Sure, and Facebook solely controls the messaging ability and photo storage for a significant percentage of their 2B+ users.

No, that's not necessarily for loading an app on to your device. It's only necessary for broader distribution.

From what I understand, it actually is a public app:

https://www.tripshot.com/

https://itunes.apple.com/us/app/tripshot/id1007192056?mt=8

>Ah, but you say: I must have signed a contract to use the app store... Except, no, I didn't do that either.

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.

You can. Just give people the code, and they can load it on their device.

> Things don't have "terms".

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.

Not really. Give me your code, and I can upload it on to any iPhone I want, without paying a cent to Apple.

I believe Apple will do everything they can to keep them from abusing the ToS, but I also believe Facebook will try to work around any and every restriction applied to them.

I don't think you even need a developer license. IIRC, I think if you just plug your iPhone into Xcode, you can load whatever code you want on to it.

Yes. Because it is technically almost impossible, if not completely impossible, to build a system that gives your code absolute freedom while not giving other code running on the system absolute freedom as well.

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.

FWIW, it'd also be great to have mirroring with Gitlab (especially since I think Google Cloud has a deal for users with them?).

In priority order, I would suggest: 1. Swift 2. Obj-C 3. Bash 4. SQL 5. Ruby 6. C#

Well, you need to have a fairly large codebase with a fair amount of in-house infrastructure and interdependencies before you have both the need to find code that you're not working on and have a dense enough source tree where search makes more sense than just learning the organization and navigating to where you need to go.

And the original (pre-translation) version is, I believe, "plata o plomo".

Well, a couple points:

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.