Spec is silent on its role in facilitating arbitrary communication between top level contexts

[Sauski]

Based on my reading of the spec, a site is able to populate PaymentMethodData.data with arbitrary data, which is then passed to the Payment Handler. A web application based payment handler may receive this, and can respond with arbitrary data in PaymentResponse.details. Based on the Payment Handler draft spec, a new top level context is accessible to the payment handler.

This appears to be a “vertical slice” of postMessage capabilities, specifically arbitrary data sharing between a parent and cross-origin child window. postMessage is of course an exceptionally powerful device with significant privacy implications.

Assuming my understanding of the spec above is correct (and it’s completely possible I’ve misunderstood something that totally nullifies this issue!), this seems to result in some tangible issues with the privacy considerations section of the spec:

• No reference to the specs role in supporting this capability (Sections 18.6 and 18.7 somewhat skirt the capability, but fall short of declaring that arbitrary data can be communicated).

• No justification for why this capability is required. e.g. Why is limiting the raw number of bits transferable in either direction not appropriate? (Likely because the merchant needs at least an individually identifiable amount of information back to complete the transaction, but this should be called out)

• No reference to mitigations that support this capabilities inclusion. E.g. reference to the proposed payment handler specification that details:

  • URL based payment handlers are delivered by service workers, implying the user must have at least loaded the handler site previously.
  • “User agents should not share payment request information with any payment handler until the user has selected that payment handler.” Implying at least some in context user approval to the data sharing.
  • Additional restrictions considered in Payment Handler Issue #351

To be clear, I don’t think these are issues with the fundamental design of this spec. Facilitating payments is inherently a high trust, high information activity, and there are likely valid answers to the above, but they should be detailed in the privacy considerations of the spec.

Reiterating mitigations relied upon by the spec and the purpose they serve, even if documented elsewhere, seems like a generally good idea. I’ve been exploring Chrome’s current implementation (using this site), and it has a fairly lenient interpretation of the migitations in the draft payment handler spec (seems like a URL based payment request could be fairly quickly made and completed without user interaction aside from an initial click in the web contents area). Understanding the implications of weakening these mitigations (i.e. arbitrary data sharing becomes a bit easier) shouldn’t require piecing together parts of different specs or issue threads.

[ianbjacobs]

Hi @Sauski,

Thank you for submitting this issue. Would a statement like the following be helpful in section 18.7?

"Payment Request API intends to support a wide array of payment methods and corresponding data models. As a result, arbitrary data may be provided by the calling origin via PaymentMethodData.data to the origin of the payment app selected by the user. Similarly, data used to complete the transaction is returned from the selected payment app origin to the calling origin via PaymentResponse.details. Browsers features (e.g., as part of implementation of the Payment Handler API or other APIs) offer privacy protections, such as requiring user gestures before data crosses origins."

[danyao]

Reiterating mitigations relied upon by the spec and the purpose they serve, even if documented elsewhere, seems like a generally good idea. I’ve been exploring Chrome’s current implementation (using this site), and it has a fairly lenient interpretation of the migitations in the draft payment handler spec (seems like a URL based payment request could be fairly quickly made and completed without user interaction aside from an initial click in the web contents area). Understanding the implications of weakening these mitigations (i.e. arbitrary data sharing becomes a bit easier) shouldn’t require piecing together parts of different specs or issue threads.

I agree with this assessment. We enumerated some of these weaknesses in the privacy threat model analysis [1] last year, and identified some mitigations, such as not allowing a payment handler to complete a transaction without user interaction. The next step will be to incorporate those mitigations into the spec.

[1] https://w3c.github.io/webpayments/proposals/privacy-threat-model.html

[samuelweiler]

Hi @Sauski,

Thank you for submitting this issue. Would a statement like the following be helpful in section 18.7?

"Payment Request API intends to support a wide array of payment methods and corresponding data models. As a result, arbitrary data may be provided by the calling origin via PaymentMethodData.data to the origin of the payment app selected by the user. Similarly, data used to complete the transaction is returned from the selected payment app origin to the calling origin via PaymentResponse.details. Browsers features (e.g., as part of implementation of the Payment Handler API or other APIs) offer privacy protections, such as requiring user gestures before data crosses origins."

The first part, which identifies the problem, is helpful.

The second part, re: mitigations, needs to point to where those "browser features" are documented. The mitigations need to specified in detail. Ideally, I'd like those mitigations to be in this spec. If you can make a case for them being different per payment handler, I'm fine with you pushing this out to them, but then this spec needs to require the payment handlers to define those mitigations.

[ianbjacobs]

@samuelweiler,

How about something like this:

"Payment Request API intends to support a wide array of payment methods and corresponding data models. As a result, arbitrary data may be provided by the calling origin via PaymentMethodData.data to the origin of the payment app selected by the user. Similarly, data used to complete the transaction is returned from the selected payment app origin to the calling origin via PaymentResponse.details. Browsers features (e.g., as part of implementation of the Payment Handler API or other APIs) offer privacy protections, such as requiring user gestures before data crosses origins. Although mitigation strategies may vary depending on context, it is the responsibility of any specification that enables a payment app ecosystem to address these issues. For more information about mitigation strategies for payment apps, see the Payment Handler Privacy Threat Model."

[samuelweiler]

As the outsider, I'm not sure what is meant by "any specification that enables a payment app ecosystem".

Let's boil it down to concrete cases: where are the current protections, such a requiring gestures, documented? Which specs mandate that?

[ianbjacobs]

" where are the current protections, such a requiring gestures, documented? Which specs mandate that?"

I believe that mitigations that relate to Payment Request are currently in Payment Request. MItigations related to payment apps would be addressed in other specs.

[samuelweiler]

Again, let's get concrete. Could we have this section point to those mitigations elsewhere, by specific reference?

[ianbjacobs]

Hi @samuelweiler,

The first sentence of 18.7 is: "The user agent MUST NOT share information about the user with a developer (e.g., the shipping address) without user consent."

Here's a proposed paragraph to follow that one:

"In particular, the PaymentMethodData.data and PaymentResponse.details fields allow for the arbitrary exchange of
data. In light of the wide range of data models used by existing payment methods, prescribing data specifics in this API
would limit its usefulness. PaymentResponse.details carries data from the payment handler, whether Web-based (as defined
by Payment Handler API) or proprietary. User agents MUST NOT support payment handlers unless they include adequate
consent mechanisms."

[Sauski]

I'd would echo @samuelweiler's general concerns; we should be referring to concrete mitigations where available.

If I'm understanding correctly, @ianbjacobs, you're suggesting that the Payment Request API set the bar (at "adequate consent") for payment handlers to meet, without referring to concrete mitigations.

Given that the specifications that would be required to meet this bar are earlier in development (and thus may not yet have well-defined mitigations), at a high level I could see this being a valid approach. But nevertheless, if we take this path, I think we should be mores specific about what we mean by "adequate consent".

Consent is a notoriously nebulous idea. The threat model analysis even makes mention of this. Helpfully though, it already offers a deeper explanation of what is important (rather than attempting to define consent), these two points feel particularly pertinent:

• The ability to identify the parties they are interacting with;
• Deliberate expression of intent to interact and consent to share data.

If you'd like to avoid including specific mitigations, and instead opt for stating a more general requirement, what do you think about including these points?

[ianbjacobs]

@Sauski,

I'd be happy to include both of those points as examples. For example:

"In particular, the PaymentMethodData.data and PaymentResponse.details fields allow for the arbitrary exchange of
data. In light of the wide range of data models used by existing payment methods, prescribing data specifics in this API
would limit its usefulness. PaymentResponse.details carries data from the payment handler, whether Web-based (as defined
by Payment Handler API) or proprietary. User agents MUST NOT support payment handlers unless they include adequate
user consent mechanisms (such as awareness of parties to the transaction and mechanisms for demonstrating the intention to share data)."

[samuelweiler]

It seems like we should pointing at this solution which I hope has been documented somewhere in the Payment Handler API.

Maybe I'm missing a level of abstraction - do we expect the payment request API to point at anything other than THE payment handler API? If not, then why not point to the concrete fix?

[ianbjacobs]

Payment Requests today are answered in the following ways:

• Via Chrome directly (for the Basic Card implementation)
• Via Web-based payment handlers (via Payment Handler API)
• Via Android-specific mechanisms (for native Android payment apps)
• Via iOS-specific mechanisms (for Apple Pay)

Today there is no normative dependency from PR API on Payment Handler API. I don't think we should introduce one.

Meanwhile, I don't believe that Chrome has yet implemented the proposal that you mentioned. We've not checked in lately on the progress around this issue; I will check with our Chrome colleagues on the status.

[Sauski]

To round this out, based on the reactions to the comment above I think we've reached alignment.

Introducing a normative dependency from Payment Request API to the Payment Handler API is not the correct approach, and the example additional text proposed sets an appropriate mitigation requirement for any payment handler (beyond just the Payment Handler API, as described above).

[hofman-stripe]

One slight concern I have with the proposed wording is any assumption it makes on a feature (Payment Handler) which is not yet standardized. If we were to find a way to specify Payment Handlers in a way that data could be shared by the page with a handler before the user has expressed consent (e.g. to check for enrolled instrument), but prevent that handler to store or send any data anywhere (especially back to the page) until and unless the user has expressed consent, would that satisfy the text as proposed?

[ianbjacobs]

Hi @hofman-stripe,

If we learn that this wording does not allow for a smart approach we had not considered, then we should adjust the wording. It sounds to me like you intend to satisfy the underlying goal of sharing data only with user consent.

Ian

[danyao]

@hofman-stripe

If we were to find a way to specify Payment Handlers in a way that data could be shared by the page with a handler before the user has expressed consent (e.g. to check for enrolled instrument), but prevent that handler to store or send any data anywhere (especially back to the page) until and unless the user has expressed consent, would that satisfy the text as proposed?

IMHO, if we can ensure that the data shared with the handler never leaves the device, then it would satisfy the text. The challenge will be figuring out how to ensure the isolation, and that should be in scope for any design of payment handler technology, including Payment Handler API.

[Sauski]

I agree with @danyao. If it isn't possible to determine off-device that any action has occurred, then there hasn't been a transfer of data between parties and gathering consent to the transfer of data between parties is probably not required (depending on the specifics, other consents may of course be applicable).

I also agree that this is a concern for particular payment handlers to address. If a payment handler feels it has a use case that is both simultaneously sufficiently privacy preserving, but somehow cannot meet these basic requirements, then that can be a discussion on that specification.

These requirements are pretty fundamental to privacy though, so I cannot currently fathom what such a use case would look like. Given this, encouraging payment handlers to use additional mitigations and smart strategies to meet the bar set here, rather than lowering the bar to accommodate hitherto unknown handler behaviors, is almost certainly the correct approach.