The default bug view has changed. See this FAQ.

Skip pay provider selector in navigator.mozPay() when only 1 JWT

RESOLVED WONTFIX

Status

()

Core
DOM: Device Interfaces
RESOLVED WONTFIX
5 years ago
5 years ago

People

(Reporter: kumar, Assigned: ferjm)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

navigator.mozPay() (bug 767818) shows an initial selection screen to handle cases where merchants send multiple JWTs for each supported payment provider. In the case where there is only one provider (JWT array length of 1), skip that screen.

This change has been approved by Jonas over email. There are privacy implications here because navigator.mozPay() may not have been triggered by a user action. After this change, triggering that API will result in a GET request to the payment provider.

The privacy team should be aware of it but after discussion we felt the risks were mitigated by these facts:

1) The whitelist of payment provider URLs is controlled by Mozilla and thus we can restrict who might receive the GET request

2) The GET request only includes the JWT (an encoded JSON object with product details) provided by the merchant, it does not include personally identifiable information.

3) Mozilla has the chance to not only review but enforce privacy policies of any whitelisted payment provider. The recommendations are here: https://wiki.mozilla.org/WebAPI/WebPaymentProvider#Privacy

4) For our initial launch there will only be one supported payment provider and it will be hosted by a Mozilla server. We can enforce the privacy policy for collected data.

5) Triggering navigator.mozPay() without user interaction and having it result in a GET request is not much different than triggering window.location = 'http://...'
Tom, let me know if you want me to follow up with any details here.
Assignee: nobody → ferjmoreno
(Assignee)

Updated

5 years ago
Blocks: 767818
(Assignee)

Comment 2

5 years ago
Should this be a P1 blocker?
blocking-basecamp: --- → ?
(Assignee)

Comment 3

5 years ago
Created attachment 664402 [details] [diff] [review]
v1

This patch skips the old payment provider confirmation (now selection) screen unless the payment request contains more than one JWT (with different 'typ' values). In that case, the platform allows the user to choose the payment provider that she prefers.

The only significant change is in dom/payment/Payment.jsm, where the condition has been added. The other changes are for renaming 'confirmation' to 'selection'.

Once this lands, the Gaia side will also require some modifications.
Attachment #664402 - Flags: review?(fabrice)
(In reply to Fernando Jiménez Moreno [:ferjm] from comment #2)
> Should this be a P1 blocker?

I say yes because it is required by UX for launching payments for basecamp. Maria S (mushi) can provide details about the UX requirement.
So, I'm not a big fan of having this skipping functionality in the back-end. Is there anything that prevents the content side (eg Gaia) to return the only choice available if there's only one?
(Assignee)

Comment 6

5 years ago
(In reply to Fabrice Desré [:fabrice] from comment #5)
> So, I'm not a big fan of having this skipping functionality in the back-end.
> Is there anything that prevents the content side (eg Gaia) to return the
> only choice available if there's only one?

Yes, we could do that on the content side, but I would like to understand your reasons to prefer this option before :)

IMHO it would be better to avoid any mozChromeEvent <-> mozContentEvent dance if possible.

If your concern is about doing this in the common part (dom/payment/Payment.jsm) we can still do it in the B2G glue, so the check is only done in B2G (just in case we finally implement mozPay for other platforms).

Thanks Fabrice!
My main reason is that this is a UX decision, so I'd rather have the code as close to UI as possible. This is what we do for web activities, and for install/updates API we also had to let the UI drive the process because of complex UX requirements. In general, keep the backend dumb and secure, and let the front-end drive it.

I'm not sure moving that in the b2g glue is good enough either. mozChromeEvents are not *that* bad anyway...
(Assignee)

Updated

5 years ago
Attachment #664402 - Flags: review?(fabrice)
(Assignee)

Comment 8

5 years ago
(In reply to Fabrice Desré [:fabrice] from comment #7)
> My main reason is that this is a UX decision, so I'd rather have the code as
> close to UI as possible. This is what we do for web activities, and for
> install/updates API we also had to let the UI drive the process because of
> complex UX requirements. In general, keep the backend dumb and secure, and
> let the front-end drive it.
> 
> I'm not sure moving that in the b2g glue is good enough either.
> mozChromeEvents are not *that* bad anyway...

Ok. I still think that saving any extra event flow is worth the platform modification :). Anyway, I've just sent this PR https://github.com/mozilla-b2g/gaia/pull/5235 with the required modification.

Should I close this as WONTFIX?
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
blocking-basecamp: ? → ---
(Assignee)

Comment 9

5 years ago
Fabrice, could you take a look at the Gaia PR, please :)? I am not sure if you notice the github notifications.
(Assignee)

Comment 10

5 years ago
Created attachment 667396 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/5235

Pointer to Github pull-request
(Assignee)

Updated

5 years ago
Attachment #667396 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.