Privacy concerns with blacklist/whitelist

[hillbrad]

Do the blacklist/whitelist features allow re-identification of the user without informed consent?

If I call makeCredential() with a blacklist, is it clear to the user that the blacklist may reveal other identities they have registered with the site previously?

If I call getAssertion() with a whitelist, can't the timing of an immediate return if no credentials in that whitelist are present vs. a delay for user approval, also effectively re-identify a user without consent?

[equalsJeffH]

see also issue #204

[equalsJeffH]

see also issue #140

[kpaulh]

Regarding getAssertion() with a whitelist, the Chrome implementation circumvents this by not returning immediately but by continuing to request user consent until timeout. In either case of user consent or timeout, Chrome will return a NotAllowedError.

[emlun]

@kpaulh So essentially Chrome ignores this part of §5.1.3.19 and §5.1.4.1.17?

If any authenticator returns a status indicating that the user cancelled the operation,

1. Remove authenticator from issuedRequests.
2. For each remaining authenticator in issuedRequests invoke the authenticatorCancel operation on authenticator and remove it from issuedRequests.

That should indeed make it impossible for the caller to see a difference between (1) timeout and (2) the credential is available, but the user denied consent to use it. It doesn't seem like this instruction would add much to the user experience either. So should we just delete it from the spec?

[kpaulh]

Oh, those steps are still useful. We perform them if the user denies consent. The distinction I meant is that Chrome will not immediately return if there are no credentials in the whitelist present.

[emlun]

Ah, I see. I also realized that those steps indeed won't have to go as long as the timeout isn't terminated early. What do you think of the additions proposed in #687?

[kpaulh]

Yeah, that sums it up pretty well!

[equalsJeffH]

see also #743

[emlun]

I believe this can be closed now that #687 is merged.

[nadalin]

@emlun please close

[emlun]

Decided on 2018-01-17 call to close this. With #655 and #687 merged, and #613 in progress, this should no longer be an issue.

Previously the operations would check at one instant what authenticators are available, ask the user for consent if any are applicable, or otherwise immediately return failure. Currently, the operations start a timer and do not return failure before the timeout expires.

With this, the side channel of timing information allowing identification without consent should be eliminated.

[equalsJeffH]

Actually, in reviewing this and issue #204 and the the PRs #655, #687, #613 (mentioned by @emlun above), I agree that the "If I call getAssertion() with a whitelist..." portion of @hillbrad's original post (OP) is addressed (yay!).

However, it seems that in closing this issue, we overlooked that we have not addressed the other portion of the OP:

If I call makeCredential() with a blacklist, is it clear to the user that the blacklist may reveal other identities they have registered with the site previously?

Though, issue #204 is specifically in regards to the latter, and remains open at this time, so I'm thinking we can leave this particular issue closed, and rectify this oversight by addressing #204.

See also PR #687 (comment)

[emlun]

See my response in #687 (comment)