Re: [w3c/payment-request] Changes resulting from 28 February PING privacy review (#843)

@ianbjacobs 

Thanks again for the reply.  Sure enough, i was looking at the wrong text.  Thanks for the clarification!

One other item related to mitigations, and one more reason you may want to include mitigation standardization in v1 (even if it slows things down): how does the user agent signal to the website "I am interested in using the Payment API, but I don't want to allow the fingerprinting risk implied by canMakePayment."?

Say the user agent is operating in this privacy-protecting state and takes some of the mitigation steps mentioned in the text, and turns `canMakePayment` off (e.g. "allowing the user to configure the user agent to turn off").  Is there some way the UA can say "ask me explicitly what I support, by sending me a form, or similar, but no passive techniques"?  I dont see anyway to express this in the API as described.

Throwing `SecurityError` seems semantically wrong (there is no security related issue in this scenario).  The `NotAllowedError` is only specified for the rate limit case.  And in either case, the website might reasonably interpret the response to be "UA never allows using Web Payment API" or "i've been rate limited", instead of "UA doesn't allow the website to ask what payment methods are supported, passively."  In which case, the `canMakePayment` functionality, as currently imagined might _increase_ friction (since the site could assume Web Payments is disabled).

I suggest adding an additional exception type, or return value to the `canMakePayment` promise indicating "user is still interested in Web Payments, but no background / passive checking, to maximize use of Web Payments API.  Thoughts?

-- 
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-request/pull/843#issuecomment-469537884