Add initial privacy considerations for fingerprinting and data leakage

[johannhof]

@npdoty this covers parts of #265, not sure if it fully closes it though

I also added a TODO in anticipation of #219

---

Preview | Diff

[npdoty]

There are additional fingerprinting and tracking risks when credentials are affirmatively presented:

• characteristics of credentials (even ones not inherently linkable) can become part of a user fingerprint
• presented credentials may include unique cross-origin identifiers otherwise unrelated to the meaningful contents of the credential (for example, a device key used to sign presentations)

Browsers that wish to detect and protect against fingerprinting would need to know what kind of presentations are being requested in order to inform users or to help them understand the implications of sharing or to help them clear the state mechanisms being used to recognize them. (Wallets are poorly placed to address this issue, since it affects the privacy protections that browsers can provide against tracking users in browsing to multiple sites.)

[npdoty]

Issuance of credentials also implicates fingerprinting in a cookie-like way. Issuing a credential so that it can be requested later is a state mechanism that can be used to track users, even after they clear their local state, even if there's nothing personally identifying in the credential content itself.

[npdoty]

Small edits on the existing wording.

Fingerprinting considerations should also consider the implications of issuing and presenting credentials.

[marcoscaceres]

I disagree that this is a fingerprinting vector. The response to this is just if the User Agent knows the string, and not if any wallet supports it. As such, the mitigation has already been taken care of: it's not linkable to any wallet and can't be used to check if a wallet is actually supported or on the user's system... just that the API might forward the request to the possible wallets, but it knows and says nothing about the available wallets.

[johannhof]

Right, that is the mitigation. I agree with you it's not a fingerprinting vector, but that's because we're smart and hopefully doing it correctly. I think it's fair to call out that there was a fingerprinting vector here that is being mitigated, this helps set context for why the API works that way vs. revealing which protocols are actually supported by wallets.

I can reword the inline issue text to make that more clear :)

[marcoscaceres]

This should be written as statements of fact, that the API doesn't allow these things by design.

[johannhof]

There are additional fingerprinting and tracking risks when credentials are affirmatively presented:

• characteristics of credentials (even ones not inherently linkable) can become part of a user fingerprint

I'm not sure about this one - yes, what you're saying is technically correct, but it does not match the definition of "fingerprinting" we commonly use. The location returned by the Geolocation API, or the pixels returned by the Camera API, could also be turned into a fingerprint if the user accepts these prompts everywhere.

• presented credentials may include unique cross-origin identifiers otherwise unrelated to the meaningful contents of the credential (for example, a device key used to sign presentations)

This seems good to add, thanks!

Browsers that wish to detect and protect against fingerprinting would need to know what kind of presentations are being requested in order to inform users or to help them understand the implications of sharing or to help them clear the state mechanisms being used to recognize them. (Wallets are poorly placed to address this issue, since it affects the privacy protections that browsers can provide against tracking users in browsing to multiple sites.)

Issuance of credentials also implicates fingerprinting in a cookie-like way. Issuing a credential so that it can be requested later is a state mechanism that can be used to track users, even after they clear their local state, even if there's nothing personally identifying in the credential content itself.

I'm not fully understanding this - are you saying that credentials could be requested without a prompt after local state has been cleared?

[npdoty]

There are additional fingerprinting and tracking risks when credentials are affirmatively presented:

• characteristics of credentials (even ones not inherently linkable) can become part of a user fingerprint

I'm not sure about this one - yes, what you're saying is technically correct, but it does not match the definition of "fingerprinting" we commonly use. The location returned by the Geolocation API, or the pixels returned by the Camera API, could also be turned into a fingerprint if the user accepts these prompts everywhere.

I see what you mean, but we don't have a bright line distinction between which characteristics are part of fingerprinting and which are just directly revealed information that can be used to identify someone elsewhere. Our definition of fingerprinting surface explicitly includes environmental characteristics like sensor readings including location information. The relevant part to me seemed to be that you might reveal some small observable characteristic (like your age, or issuer of your age credential) that isn't inherently identifying, but could be used in combination with a mix of other characteristics (IP address, UA string, etc.) to identify or re-identify the user in a way that's opaque and hard to protect against without systematic responses, like browser fingerprinting.

• presented credentials may include unique cross-origin identifiers otherwise unrelated to the meaningful contents of the credential (for example, a device key used to sign presentations)

This seems good to add, thanks!

Browsers that wish to detect and protect against fingerprinting would need to know what kind of presentations are being requested in order to inform users or to help them understand the implications of sharing or to help them clear the state mechanisms being used to recognize them. (Wallets are poorly placed to address this issue, since it affects the privacy protections that browsers can provide against tracking users in browsing to multiple sites.)

Issuance of credentials also implicates fingerprinting in a cookie-like way. Issuing a credential so that it can be requested later is a state mechanism that can be used to track users, even after they clear their local state, even if there's nothing personally identifying in the credential content itself.

I'm not fully understanding this - are you saying that credentials could be requested without a prompt after local state has been cleared?

Credentials that are issued by a site in a way that would typically indicate less risk (not government-issued or high-assurance, not including personally-identifying or sensitive information, maybe even limited to the same origin), could, without the user realizing, include cookie-like identifiers. User permission prompts would be a helpful mitigation, especially if paired with some notice that this could be used to re-identify you if you've previously cleared cookies/state. Users who log back in have a clearer model of re-identification. Users who log out and clear all state and then still show a discount/fan card might not realize they're re-spawning an identifier.