Reduce risk of tracking related to payment handlers without UI

[ianbjacobs]

(Below I quote previous text from the Chrome team, moving it from this pull request [1] to an issue)
[1] w3c/webpayments#261

The Payment Handler specification currently does not require the Payment
Handler to show any visible UI to the user. Since the Payment Handler service worker runs in a 1p context, this allows for invisible tracking of the user:

1. A colluding website (https://site.example) gets a user click (e.g., on a next button on the website UX).
2. It constructs a Payment Request for the tracker (https://tracker.example) and calls show().
3. The tracker 'payment app' is JIT-installed (or was installed earlier viaPaymentInstrument.set()), and receives a
   PaymentRequestEvent.
   • This event can contain arbitrary information from the colluding website, and the app is running in a 1p context.
4. The tracker 'payment app' does not call openWindow(). Instead, it reads its 1p state and sends the user information to its server (possibly along with shared information from the colluding website) and calls respondWith() to silently finish the Payment Request.

This attack is similar to opening and closing a pop-up window (or doing a bounce redirect).

Potential Mitigation

Mitigating this attack is likely to be up to the user agent. We intend to force UI to be shown when show() is called. That makes sure that the user is aware of what is happening, even if the app does not call openWindow(). Other potential mitigations here might be to delay allowing respondWith() to be called immediately or to require a user interaction with the payment app before allowing it to close (to avoid a 'flash of content' attack).