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.
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 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.
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.
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.
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.
Here's an approach I've used before successfully. It's not perfect but it's better than nothing.
1. Create your own root Certificate Authority.
2. Create a script using your favorite language and libraries that will create a new certificate for each device something along the lines of "myiotdevice-AABBCCDD.local". The AABBCCDD needs to be some sort of serialized number that's assigned during manufacturing and won't be repeated between devices.
3. Add to your product support for ZeroConf/mDNS/DNS Service Discovery and advertise an https web server at myiotdevice-AABBCCDD.local.
4. Provide instructions to your users on how to download and install the certificate for your root CA (this only needs to be done once).
5. Print the name "myiotdevice-AABBCCDD.local" on the device and instruct users to type that in to a browser's address bar.
I'm doing this from memory so I may have missed an intricacy here or there (like DNS SD is a weird story on Windows 10) but this approach should basically work well enough.
EDIT - good commentary in replies about the dangers of the CA being compromised. Also, good mention of X.509 Name Constraints and how they can be used to mitigate that danger somewhat. More info here: https://systemoverlord.com/2020/06/14/private-ca-with-x-509-...
I'm curious, when you refer to Qt, do you mean the QWidget application approach or QML? QML is much more like Flutter (but is indeed somewhat arcane to learn how to work with).
My perspective is that Flutter is positioned dead on against Qt's QML. I develop mobile and desktop QML applications and this seems to be trying to be very competitive with it.
Qt also has a WebAssembly build for QML apps on the web but in my experience it has suffered from some of the same issues reported here about the Flutter WebAssembly runtime.
Edit: One key difference is Flutter seems to do everything with procedural code. QML is based on a declarative DSL plus Javascript.
I developed a different take on this issue recently. It's not that technology could destroy us - it's that the amount of complexity we are continually building with technology will eventually outstrip the resources and intellect of the human species to manage it.
Another way to put it: what if the Great Filter (https://en.wikipedia.org/wiki/Great_Filter) is really that biological life doesn't have the resources available or the capability to develop the intellect necessary to manage all the technology required for a species to go intergalactic?