You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my Masters' thesis, I found a set of issues with the Web Payment APIs (see #903 for further reference). This is one of the mentioned issues.
My assumption is that a merchant is considered to be potentially untrustworthy until the payment intent is expressed through clicking on a "buy" button and the creation of the PaymentRequestEvent.
Currently, the mechanism of PaymentRequestUpdateEvents does leak such information before the payment intent was expressed (although redacted to postal codes).
As the spec mentions in the shipping address changed algorithm:
Unfortunately, even with the redactList, recipient anonymity cannot be assured. This is because in some countries postal codes are so fine-grained that they can uniquely identify a recipient.
This issue could be resolved by approaching the shipping cost calculation the other way round.
On many online platforms (e.g. ebay), a merchant specifies the shipping costs depending on the region/country/etc.).
One could allow the same behaviour in the Payment Request API.
By doing so, no sensitive shipping address information would leak to the merchant before paymentIntent.
A merchant would provide a data structure that comunicates to the user agent the cost depending on the entered address (e.g. Germany: free, EU: 5€, international: 20€).
The user agent could infer the cost automatically thorugh a lookup in said data structure, without providing information to the merchant.
I am aware that this might be a not too easy change to the spec, but I did want to contribute it to the discussion.
The text was updated successfully, but these errors were encountered:
Yeah, I think this would result in too many changes. Additionally, the shipping is might be fulfilled by a different company, so it might not be possible ahead of time what the shipping cost will be (unless all shipping options are known for every region).
We are working towards limiting the amount of information being shared as part of: #873
@crowgames, would you be ok with us closing this on in favour or #873?
In my Masters' thesis, I found a set of issues with the Web Payment APIs (see #903 for further reference). This is one of the mentioned issues.
My assumption is that a merchant is considered to be potentially untrustworthy until the payment intent is expressed through clicking on a "buy" button and the creation of the PaymentRequestEvent.
Currently, the mechanism of PaymentRequestUpdateEvents does leak such information before the payment intent was expressed (although redacted to postal codes).
As the spec mentions in the shipping address changed algorithm:
This issue could be resolved by approaching the shipping cost calculation the other way round.
On many online platforms (e.g. ebay), a merchant specifies the shipping costs depending on the region/country/etc.).
One could allow the same behaviour in the Payment Request API.
By doing so, no sensitive shipping address information would leak to the merchant before paymentIntent.
A merchant would provide a data structure that comunicates to the user agent the cost depending on the entered address (e.g. Germany: free, EU: 5€, international: 20€).
The user agent could infer the cost automatically thorugh a lookup in said data structure, without providing information to the merchant.
I am aware that this might be a not too easy change to the spec, but I did want to contribute it to the discussion.
The text was updated successfully, but these errors were encountered: