In a nutshell, it will be possible for relying parties (i.e. websites) to detect multi-device/backup capable authenticators if required, but disabling multi-device functionality would require a very explicit opt-out, not an opt-in, on the relying party's side.
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.)
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.
And for service that actually want it to be used as major key. I think they can just make the one authenticated able to authenticate another(and even decide whether this new device can auth yet another or not). (Like the way google use: popup on user phone, and ask if user would like to let the computer login.)
I think the one we actually need is a common protocol to authenticate new fido device from existing one. Although you can do it currently, every website have different flow to do it. And there is not currently a common way here. A common and machine understandable way to auth new device from existing one may ease the pain.