search

w3c / secure-payment-confirmation

Secure Payment Confirmation (SPC)
https://w3c.github.io/secure-payment-confirmation/
Other
110 stars 39 forks source link

11.2 define the mitigation #142

Closed samuelweiler closed 2 years ago

samuelweiler commented 2 years ago

The attack in 10.2 is clear, as is the goal ("make sure not to enable malicious callers... to distinguish between these cases").

But the methods of getting there are not defined. Instead of "If the URL is accessed then the caller can conclude that at least one of the passed credentials is available to the user", how about an instruction: "do not load the URL until"? Presumably that instruction should be elsewhere in the doc, to be read contemporaneously with other process test. Are any other mitigations needed to achieve the goal?

stephenmcgruer commented 2 years ago

The example privacy leak in 10.2 is just that, an example. As with WebAuthn, there are many awkward edge cases that a user agent could accidentally leak credential existence, including in ways that are deliberately not specified (e.g. the UAs choice to show or not show a user under certain circumstances). That is why, like WebAuthn, we are describing the general concern and giving an example to user agents to consider.

The mitigation to the example leak in 10.2 is explicitly spec'd in https://w3c.github.io/secure-payment-confirmation/#sctn-steps-to-check-if-a-payment-can-be-made, fyi.

stephenmcgruer commented 2 years ago

(Note: this is now 11.2)

samuelweiler commented 2 years ago

I'm glad to see the explicit instructions in what is now 4.1.4.

1) I'd like 11.2 to point at 4.1.4 (e.g. "here's now to achieve this")

2) Are the instructions in 4.1.4 sufficient to mitigate all leaks? From your text, I'm inferring that is it not. What else is needed?

stephenmcgruer commented 2 years ago

I'd like 11.2 to point at 4.1.4 (e.g. "here's now to achieve this"

Happy to send a PR for this.

Are the instructions in 4.1.4 sufficient to mitigate all leaks? From your text, I'm inferring that is it not. What else is needed?

This space is quite complex, and to be clear I'm following WebAuthn's lead here. My goal is that implementors know to be careful here, because seemingly innocent decisions can breach the privacy model by accident. I would like to confidently say that we've covered all the ways this can happen, but cannot be sure.

I think ultimately there's a bit of a meta question of what a S&P section should contain. We copied WebAuthn's style, but perhaps that was the wrong choice.

stephenmcgruer commented 2 years ago

As per the May 4th WPWG remote meeting discussion with PING, the remaining steps for this issue are to have 11.2 point at 4.1.4, and then we should be clear to close it out. PING recommends keeping section 11.2, to serve the purpose of explaining a risk and how the spec mitigates it.

ianbjacobs commented 2 years ago

Thank you, @samuelweiler, for the recommendation to tighten up the normative language, now integrated. We hope this resolves the current issue.