That seems to make fido just a non human readable/rememberable account/password. A somewhat downgrade from original hardware enforced implementation. But also make it more usable to majority of people, because keep something without losing it is just a pain to many people(where is my fxxking key goes again?). And it is still 1000x better than people using same password on every website.

It's much more than a non-rememberable password: One of the most important attributes of WebAuthN/FIDO is that it's fundamentally impossible to fall victim to phishing.

Assuming your browser isn't itself compromised, it is impossible to authenticate using a key for service.com on evil.com. Passwords can't do that. (PAKEs or other challenge/response protocols theoretically could, if implemented in the browser and not on websites, but that's a different story.)

However it will be weaker to malware compares to the original one. Because if you can export or sync the key, then malware probably also can if your device is compromised.

The guarantee that key is never cloned unknowingly even machine fully compromised isn't in this new model.

> The guarantee that key is never cloned unknowingly even machine fully compromised isn't in this new model.

True, that was my concern with the new specification as well. But I believe the main problem will be account takeovers, not malware.

> Because if you can export or sync the key, then malware probably also can if your device is compromised.

Not necessarily. There are ways to still keep these keys only in secure hardware while allowing synchronization if the secure hardware supports service-provider mediated attestation.

HSMs usually support a similar process, where keys can be copied to a different HSM by the same vendor, preserving all of their usage and authentication restrictions (i.e. only the same set of authenticated and authorized users are able to use them).

This conceptually works by e.g. a new and old device, or a service-provider side HSM-secured backup and a new device, establishing a secured channel, attesting their state to each other and then copying the credentials over that secured channel.

By necessity, this includes the service provider (or at least their HSM code) as a trusted party: They are the one that ultimately gets to decide which new devices get added to the synchronization set, and under what circumstances (running a recent hardware and software version, multifactor authentication, providing a high or low entropy shared secret).

Of course, all of this also vastly increases the trusted computing base, and this might well not be appropriate for high security organizational environments.