In order to protect user privacy, we should avoid PaymentRequest becoming a way of obtaining the user's geographic location without permission. Currently, if the user has a shipping address on file, we fire the shippingaddresschange event right after the payment sheet opens. Even after the redaction in bug 1435155, this gives relatively precise address information to the Web site. We should require some non-Cancel address-related user interaction on the payment sheet before exposing even the redacted shipping address to the site. I'm not a UI designer, but here's a concrete proposal for the starting point of a design discussion: -- If a shipping address is requested, when the payment sheet opens, disable the "Pay" button and show a pop-up menu of shipping addresses showing a placeholder label such as "Choose Shipping Address" as the initially-chosen item. Do not fire a shippingaddresschange yet. (The "Pay" button should be disabled at this point, because the information isn't yet in a valid state from the perspective of the Web site.) When the user chooses a shipping address, fire the shippingaddresschange event and enable the "Pay" button. -- Analysis: In this case, UI smoothness and user privacy are at odds. This would intentionally reduce UI smoothness compared to the current design to avoid reducing user privacy relative to the state the Web was in before the introduction of Web Payments.

tjr, who should do privacy review on this or otherwise be CCed here from the privacy perspective?

I'll try and figure it out, but a quick question: (In reply to Henri Sivonen (:hsivonen) from comment #0) > We should require some non-Cancel address-related user interaction on the > payment sheet before exposing even the redacted shipping address to the site. > > If a shipping address is requested, when the payment sheet opens, disable > the "Pay" button and show a pop-up menu of shipping addresses showing a > placeholder label such as "Choose Shipping Address" as the initially-chosen > item. Do not fire a shippingaddresschange yet. (The "Pay" button should be > disabled at this point, because the information isn't yet in a valid state > from the perspective of the Web site.) Is the 'payment sheet' new, trusted, browser chrome? Otherwise I'm not sure how we could reliably identify the Pay/Cancel buttons...

(In reply to Tom Ritter [:tjr] from comment #2) > Is the 'payment sheet' new, trusted, browser chrome? Otherwise I'm not sure > how we could reliably identify the Pay/Cancel buttons... Yes, it is.

I agree this is a a significant issue -- resolving this is a blocker for us to ship.

(In reply to Henri Sivonen (:hsivonen) from comment #1) > tjr, who should do privacy review on this or otherwise be CCed here from the > privacy perspective? Paul or someone from his team can do this =)

We've not a had a formal privacy review process for a long while, apart from the data stewards review. My team (which does security reviews) can take an action to do a privacy review. Can you spell out what you are looking for here? (you've already highlighted an issue that there seems to be agreement that needs resolution. Were you looking for someone to look at the UI flows more completely for similar issues? Or something else?) As an aside, I started a security review of web payments last year, but put it on hold waiting for progress on the UI front. Now that its moving again, we should probably get re-involved, I'll reach to the payments team for that. (needinfo'ing myself to ensure I do this)

Discussions that lead to redacting information on the spec side: https://github.com/w3c/payment-request/issues/648

(In reply to Paul Theriault [:pauljt] from comment #6) > Can you spell out what you are looking for > here? (you've already highlighted an issue that there seems to be agreement > that needs resolution. Were you looking for someone to look at the UI flows > more completely for similar issues? Or something else?) We have issue where UI smoothness and privacy are at odds, so it seems appropriate to loop in both someone in charge of UI and someone in charge of privacy, so that when we ship, we have something that isn't an unhappy surprise either to people in charge of UI or to people in charge of privacy. Maybe this ends up being just an LGTM on comment 0 from you and a UI designer. Maybe coming up with a better solution. I don't know who should be looped in from the UI perspective here.

Looping in jsavory, see comment 0

I'm going to write a proposal of a few options that we have. Note that Marcos and I already talked about changing the implementation to not leak the address until Pay was changed so we weren't planning to ship as-is. i.e. don't read too much into the current implementation. This privacy leak was one of the first glaring issues I saw with the spec when I started looking at it and it was documented at https://blog.lukaszolejnik.com/privacy-of-web-request-api/ (s/Web Request/Payment Request/ in that post). It seems like there is agreement within the engineers involved that simply opening of the payment dialog via PaymentRequest.show with user interaction (IsHandlingUserInput) shouldn't leak the user's full address despite Google Chrome and Microsoft Edge already shipping this way. I will share my ideas in a few hours.

Sorry, this took a bit longer than expected as there are many variables to consider and I wanted to keep the discussion focused and not getting into all of the edge cases in the beginning. For now I think we should focus on the case of a user's first purchase on a site (since this is the time when privacy is most important) where the user already has their desired shipping address saved in the browser (so we don't get distracted by the first-time-use flow). My comparison of options is at https://docs.google.com/document/d/1GTI2hGlvs_4I4umQmMme2Vh9kZ5L8eHvKWzdrZmfjvQ/edit From the privacy perspective I propose that we choose Option D from Table 1 (what Marcos and I discussed in YVR) combined with Option D from Table 2 with the potential enhancement to change the "Pay" button to be re-labelled as "Recalculate Total" (or similar) if the user changes the shipping address from the default. These choices provide the best privacy protection since no part of the address is leaked until the user clicks the primary ("pay"/"recalculate") button. Pros: A) Best privacy protection. The user's address is only leaked once they click "Pay"/"Recalculate". B) Allows for a one-click checkout experience if the user's default address is accepted by the merchant. C) No redaction logic to standardize or implement across regions. Cons: i) User doesn't get live shipping cost calculations upon choosing another shipping address, they would have to click recalculate in-between each address selection. This aligns with how shipping estimations work with sites like eBay though. ii) We need to make it clear that users understand their name and phone number are sent to the merchant when the "recalculate" button is pressed, not just their address information. iii) Users won't get address validation until they click Pay/Recalculate. == If people think the cons outweigh the benefits of (A) and (C) then we could choose Option C in Table 2 instead. Jacqueline, what are your thoughts on this approach to reduce address leaks to merchants?

Btw. I talked with Jacqueline the other day and she was going to talk to Sharon about User Research/Testing options.

I chatted briefly with Sharon about the problem here and went through the possible solutions. Based on the options, I don't think there is a clear best solution, each option has a fairly significant downside. Sharon agreed that this is certainly something we can look into more and I will keep working with her to find the best way to test for this.

(In reply to Henri Sivonen (:hsivonen) from comment #0) > In order to protect user privacy, we should avoid PaymentRequest becoming a > way of obtaining the user's geographic location without permission. One question about the threat model: is this a concern about leaking the user's current location (e.g., for stalking purposes) or the user's identity (because if you know the user's address you might know who the person is) or both?

Both.

Our UI will not pre-select a default shipping address so it's not blocking Nightly. The team will explore other options to balance ease of use/ privacy before Release.

Comment on attachment 8976410 [details] Bug 1443735 - Use better selectors to find payment request add/edit links. https://reviewboard.mozilla.org/r/244562/#review250802 Looks good, thanks for doing this.

Comment on attachment 8976411 [details] Bug 1443735 - Don't select a PaymentRequest shipping address by default. https://reviewboard.mozilla.org/r/244564/#review250854 ::: browser/components/payments/content/paymentDialogWrapper.js:478 (Diff revision 3) > paymentSrv.respondPayment(showResponse); > this.sendMessageToContent("responseSent"); > }, > > async onChangeShippingAddress({shippingAddressGUID}) { > + if (shippingAddressGUID) { Just so I understand: the decision being implemented here is that when the selected address is deleted, we don't inform the merchant, instead waiting until they make a selection? ::: browser/components/payments/res/containers/payment-dialog.js:160 (Diff revision 3) > shippingAddress.guid == oldShippingAddress.guid && > shippingAddress.timeLastModified != oldShippingAddress.timeLastModified) { > delete this._cachedState.selectedShippingAddress; > } > - } else { > + } else if (selectedShippingAddress !== null) { > // assign selectedShippingAddress as value if it is undefined, Nit: I'm not sure this comment ever made sense. But it especially doesnt now. Maybe "Assign null as the selectedShippingAddress if it is undefined, or if the address it pointed to was removed from storage?"

Comment on attachment 8976411 [details] Bug 1443735 - Don't select a PaymentRequest shipping address by default. https://reviewboard.mozilla.org/r/244564/#review250854 > Just so I understand: the decision being implemented here is that when the selected address is deleted, we don't inform the merchant, instead waiting until they make a selection? Yeah, for two reasons: a) It's not clear if we are supposed to send a null address in this case… I can't test in other browsers since they don't seem to ever get in this state. I'm worried that sending a null address will be a webcompat issue for that reason. I also don't see a benefit to sending null to the merchant as they will do the right thing when the next address is selected. b) The browser currently crashes if we were to call `changeShippingAddress` will a null address > Nit: I'm not sure this comment ever made sense. But it especially doesnt now. Maybe "Assign null as the selectedShippingAddress if it is undefined, or if the address it pointed to was removed from storage?" Oh, you're right, I think the issue was s/as/a/ but I agree it needs to be updated now.

Pushed by mozilla@noorenberghe.ca: https://hg.mozilla.org/integration/autoland/rev/8febbefe035f Use better selectors to find payment request add/edit links. r=sfoster https://hg.mozilla.org/integration/autoland/rev/051c9e944fa1 Don't select a PaymentRequest shipping address by default. r=sfoster

https://hg.mozilla.org/mozilla-central/rev/8febbefe035f https://hg.mozilla.org/mozilla-central/rev/051c9e944fa1