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.