Does provider get unique ID of FIDO2 device?

gk7ncklxlts99w1
https://support.mozilla.org/en-US/kb/privacy-web-authentication

That text doesn't ascribe any credibility to the claim it makes. It has several glaring issues:

• It makes a very serious claim about privacy harms – a claim that, notably, directly contradicts the explanation provided by the actual creators of the FIDO standards – without providing any evidence at all

• It makes a reference to an unfamiliar concept without defining it: what exactly is "extended information"? How is it relevant to FIDO? If I am to "deny" access to this "extended information", how does the "prompt" for it look like? I have never seen such a prompt in my usage of FIDO across dozens of web services, nor have I heard others refer to such a prompt.

The fact that the text is hosted on the site of an organisation that advertises user privacy in their software does not lend any confidence to the text as long as it does not refer to any evidence or detail what it's trying to say.

If one wants to examine whether or not the FIDO standards live up to their privacy promises, I think it's more interesting to look at scientific research that cites references and provides independent analyses. In the following I paraphrase and quote from the following research paper:

Barbosa, M., Boldyreva, A., Chen, S., Cheng, K., & Esquível, L. (2025). Revisiting the Security and Privacy of FIDO2. Cryptology ePrint Archive. URL: https://ia.cr/2025/459

First, let's note a central pillar in the authors' concept of FIDO2 "user privacy":

The goal of privacy is to ensure that multiple registrations involving the same token cannot be linked together, in order to avoid tracking.

In chapter 1, the authors reference previous academic work that analyzed and supported Webauthn's user privacy protections. The paper then argues that there is currently a lack of academic analysis into the privacy promises of CTAP specifically – hence why the article exists. (The FIDO standards are comprised of both Webauthn and CTAP taken together).

Before quoting the authors' privacy analysis of CTAP, I'll note that the paper's main purpose is to describe a theoretical attack against the privacy guarantees of CTAP 2.1; hence why the quotes below are sprinkled with summaries of this attack scenario. The authors devised this attack scenario themselves, and the paper doesn't claim that it's been exploited in practice. Moreover, they don't think it comprises a "significant" privacy risk.

From p. 5 (my emphasis):

We prove that, with minor protocol changes that prevent the above Diffie-Hellman (DH)
share reuse and by enforcing no leakage of the above meta-information, the cryptographic
design of FIDO2 indeed guarantees strong privacy properties for the user, even considering
local network attackers. We also show that the current FIDO2 guarantees privacy, as
long as the attacker does not observe CTAP traces where a token reuses the same DH
share when interacting with clients to register multiple accounts. The take-away message
from these results is that the cryptographic traces produced by CTAP do not undermine
privacy as long as DH shares are not repeated between usages. We do not argue that the
concrete attack scenarios where DH share reuse could be exploited to break privacy are a
significant reason for concern. Our claim here is that our results establish the first leakage
upper bound for CTAP (and FIDO2 as a whole): if CTAP privacy attacks contribute
to compromise FIDO2 privacy, then it can only be due to DH share reuse.

A slight summary of the attack scenario they argue exists (p. 23, my emphasis):

For the above attack, we do not claim that it has significant practical implications. Nevertheless, our tests show that, when a USB token is used to register or authenticate to multiple accounts without rebooting (by remaining plugged-in and not putting the computer to sleep), the token will reuse its DH share. This can allow a malicious server (that can access the CTAP communication, e.g., via malware with low-privilege access installed on the computer [3]) to link accounts (perhaps for different servers) of the same user, especially when multiple users share the same machine (e.g., a corporate or public computer). As we will show shortly, this potential privacy leak can be easily fixed by enforcing DH shares to be always refreshed on the token.

I want to note that both the Webauthn and CTAP specifications are continuously revised. Since that paper was published, the FIDO Alliance released an updated CTAP specification (version 2.2): https://fidoalliance.org/specs/fido-v2.2-ps-20250228/fido-client-to-authenticator-protocol-v2.2-ps-20250228.html

I can't see that the OP realistically needs to be concerned about potential privacy leaks from their security key. Any web service or app has lots of other more trivial ways to track users across accounts, that are much more cost-effective to conduct compared to trying to break FIDO2's privacy protections.

As a side note: The following is a draft document, but I think it provides interesting insight into the threat model of FIDO, specifically which security attacks the FIDO Alliance considers that FIDO can realistically protect against: https://fidoalliance.org/specs/common-specs/fido-security-ref-v2.1-rd-20210525.html#threat-analysis