Re: [w3c/payment-handler] Basic-credit security issue (#379)

Hi @ianbjacobs ,

> _Chrome uses the safe browsing [1] database to help the user avoid installing potentially harmful Web-based payment apps._
It is a good that Chrome uses the safe browsing. But even taking in consideration this point we can't proceed with **basic-credit** implementation, since the user still can install such evil Payment App even without even knowing about it (the topic of the website can be different).

For now the most important that it is not possible to have Google Pay, Samsung Pay and Apple Pay in the same time in Payment Request. You first need to pay with each of these methods using JIT approach, but it is not a user-friendly approach.

The security issue may happen only in case of build in payment (like basic-card). Since in a response from Payment Request we have just methodName which is equal **basic-card**. It will be equal **basic-card**without any info about payment domain...

My main questions are:
1. How we can use Google Pay, Samsung Pay and Apple Pay in the same time in Payment Request? If it is not possible, could you please add this functionality? It will be really useful. Note: it isn't possible if we try to pay in new clean Google Chrome (without any transaction in google pay\samsung pay\etc.).
2. How we can avoid an issue with **basic-card** ? The main goal here is to keep basic-card default functionality in Payment Request and do not have insecurity case which was described above.
3. If we can't cover the second question, is it possible somehow to retrieve user saved Credit Cards? We will need it, in order to create a custom Payment Web App for **basic-card**.

Thank you for your answers,
Roman.

-- 
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/payment-handler/issues/379#issuecomment-740763344