Re: [w3c/webpayments-payment-apps-api] Payment app identifier to manifest filename mapping (#48)

@tommythorsen 

>> The page would be able to detect "no matching payment methods" and show links to supported methods.
> Do you suggest that the browser should know about every payment method in the world and suggest an appropriate payment app?

Of course not 😄. I said "The page" not "The browser".

> Having the merchant (who needs to care about the individual payment methods anyway) provide links to payment apps makes much more sense to me.

That's what I'm saying. Why are we using privileged browser UI to show links when pages can already do it in a less security-sensitive way?

> Security issues like this one can be easily addressed by minor tweaks, such as making the the payment dialog full screen in this case.

Right, but at that point we're no better than `<a href="…" target="_blank">`, so why?

> Do you think, @jakearchibald, that there is a way for us to provide this "no payment apps available" information without exposing 1) information that can be used for fingerprinting

https://w3c.github.io/browser-payment-api/#show-method already rejects with a particular error if no supported payment apps are available. A site could use this as a trigger to display a list of recommendations. If this is a fingerprinting issue, I guess we need to take it up with that spec.

FWIW, fingerprinting is kinda possible with your proposal too. If `evil.com` supports the payments methods "paypal" and "evil.com/my-payment-app", it can detect the icon for "evil.com/my-payment-app" loading to know that "paypal" wasn't available.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments-payment-apps-api/issues/48#issuecomment-276407875