Comment by lxgr

7 days ago

Even stronger, they used to support it, but now no longer do, so we know for a fact that Apple knows how to do attestation, has already expended all resources necessary to implement it, but has then actively decided to go into a different direction (i.e. that of cloud synchronization).

I believe Android still has the option to use hardware attestation, but that automatically opts credentials out of cross-device synchronization, but Apple's veto alone is enough to make attestation non-viable.

If this can't make the "WebAuthN implies mandatory attestation!!" critics update, I wonder if anything can, and how useful their criticism still is.

It turns out that most people don't want the need to re-generate each of their credentials when they lose their device.

  • Why would they need to re-generate? Pretty much all websites are using copyable passkeys. The user just needs log in to their password manager on their new device. Which for most people just means logging in to their Apple or Google account. There is virtually no difference to storing generated passwords in a password manager or storing passkeys.

    And the sad truth is: Most people have no password manager at all. They are used to re-generate new passwords every time they want to log in! I'd wager that on some websites the vast majority of people are loggin in by pressing "I forgot my password".

    • AFAIK the whole point of attested passkeys is that they are not copyable, which make it pointless to backup in apple cloud, which must be one of the main reason Apple decided to not go that route.

      1 reply →

Even more strongly, they can just add it back at any time they want.

I don't get why this whole "they used to support it but removed it" is supposed to be an argument for anything.

  • This is a generalized argument to be worried about anything, though. They did it before and then decided against it? Well, they could go back to doing it again! They've never done it? Well, they could decide to start doing it tomorrow!

    More seriously, the fact that Apple previously implemented something and then removed that implementation gives us multiple pieces of information: they are technically capable of implementing it (not a huge surprise), at one point they thought that it was a good idea to implement it, at a later point they thought that it was not a good idea to implement it, they're willing to backtrack on implementation decisions in certain situations, etc... Depending on how you weight these different pieces of information, you can reach different conclusions about how likely reimplementation is in the future.

    • To fill out a bit more of the story, they also stopped supporting consumer attestation after arriving at a "good enough" compromise that they felt was more privacy supporting and better worked with backupable/syncable keys, the uvi and uvm extensions for Webauthn which they championed to standards. Once those standards were in place they especially saw no reason to support consumer attestation.

      (Those extensions are for a Passkey manager to "solemnly swear" to an RP that a key was involved in some sort of MFA dance such as PIN unlock or biometric unlock and maybe a little bit of rough detail of what sort. Much more rough than Attestation details and not attested claims at all so a Passkey manager could lie about them, but that's enough for the sort of regulatory compliance or "due diligence" that many Banks might need from consumers to replace existing MFA logins with Passkeys. It is a relatively strong bulwark against attestation requirements for consumers.)

  • Any company could do something extremely user-hostile at any point, so this isn't really a compelling argument?

    Do you have any argument for why they would add it back?