Should probably mention that Guido ended up on the team working on a pretty credible JIT effort. Though Microsoft subsequently threw a wrench in it with layoffs. Not sure the status now.
Currently on the iPhone, if your FaceID or TouchID fail repeatedly, you have the option to type in the passcode, which grants the same access. I'm not sure if the same is true on Android.
I think the more general point is that "able to unlock the phone" is not / should not be the same as "I have verified that this is you" for sensitive applications and information.
I think this is really great news and am glad to see FIDO move forward as I think it greatly increases account security.
One aspect of FIDO that could still be troublesome is account recovery in case of inadvertent loss of passkey. OOB recovery with SMS or email is considered too weak and the main recommended alternatives are to maintain multiple authenticators (i.e. multiple copies of your passkeys), re-run onboarding processes for new users or just abandon the account.
It's going to be interesting to see how those alternatives play out in real world situations.
Reading this announcement, the idea seems to be that FIDO keys will be synchronised across devices. That means you can lose your phone and still get access to your accounts from your desktop.
You might even be able to get access by simply logging in to your Microsoft/Apple/Google account on a new device if they implement this system stupidly enough.
Yes, these will be stored in cloud storage like iCloud Keychain. But I can go into my iCloud Keychain and delete individual passkeys - or I may have only one Apple device and then lose it. Or some malware clears out all of my iCloud Keychain.
I haven't look deeply into passkey enough yet, but aren't we replacing "what if I lose by device" by "what if company XYZ decides to nuke my access to my synchronized passkey"?
I agree that it's kind of a mess, but it's getting better with simpler APIs (like asyncio.to_thread()), and in practice you can just use the primitives you want and ignore the rest.
I haven't read the post in detail though, thanks for the link! Seems interesting.
Ditto. I started out on Twisted back in the day and stayed with it for 6 years all they way up until they introduced deferreds combined with yield/generators (the same technique which is the heart of today's asyncio).
It was great at the time but ultimately tiresome. It introduced framework specific incantations all over the place and any framework using I/O had to be Twisted-aware in order to use it straight-forwardly. The exact same complaints I have today of asycnio.
I went to gevent 10 years ago and have never regretted it. If you have some reasonable knowledge of threading and synchronization then it is a really nice developer experience.
I find Qt/QML for cross-platform mobile applications to be a great solution. It uses the same basic architecture as Flutter – they both do not use native widgets and instead draw the entire UI on a blank graphics canvas. I think that approach preserves the most code between platforms and reduces the kinds of presentation hitches that HTML web view and hybrid native widget approaches can run into.
In relation to the particular problems of technical debt related to third party modules mentioned in this article, QML rides on top of Qt which is a 26 year old C++ cross-platform toolkit with a lot of mature technology in it. I.e. there is a lot more "batteries included".
There are still plenty of times you have to "go native" to integrate something Qt doesn't cover but it apparently isn't as often as with Flutter.
Can you give me an example of a good mobile app built with Qt/QML? I feel like only big corps can justify such apps where users have no choice but to use it because their boss forced them to.
You are jumping to mistaken conclusions based on one review, the motivations of which you don't know.
I think cross-platform apps are commonly misapplied and really only make economic sense with the appropriate assumptions. Once a company has the necessary resources they should go native and go all in on platform conformity.
But for many folks, that's not a feasible place to start from.
