811866 - Host a JavaScript shim for navigator.mozPay()

Status: RESOLVED WONTFIX

(Marketplace Graveyard :: Payments/Refunds, defect, P3)

Description

[Kumar McMillan [:kumar]]

To support payments on Android (and other HTML5 platforms), let's provide a hosted JS shim

- The shim will define a compatible navigator.mozPay() API *unless* it already exists natively
- Developers will need to include this in their apps

We can re-use the shim that we already built/deployed in bug 760701 or do something similar. That code is here - https://github.com/mozilla/zamboni/blob/master/mkt/site/templates/site/mozmarket.js - and deployed here https://marketplace.cdn.mozilla.net/mozmarket.js The API needs updating though.

The navigator.mozPay() API is at https://wiki.mozilla.org/WebAPI/WebPayment

Comment 2

[Jason Smith [:jsmith]]

Clearing whiteboard - use the tracking bug to track this (bug 799669).

Comment 3

[Kumar McMillan [:kumar]]

See bug 811866 for the native payments frontend on Android

Comment 4

[Jason Smith [:jsmith]]

(In reply to Kumar McMillan [:kumar] from comment #3)
> See bug 811866 for the native payments frontend on Android

FYI - We won't be blocking on having a native front-end implementation for Android, as worst case, we could have a hosted shim for this release that developers would include.

Comment 5

[[:fabrice] Fabrice Desré]

The mozApps API history has shown how painful it was to try to maintain both a shim and a native implementation, especially for something as security sensitive as this one.

I'm strongly in favor of using the native implementation also on android. It was designed to be pluggable so only a relatively small part needs to be added to the common base.

Comment 6

[Kumar McMillan [:kumar]]

I'm fine with pursuing a native implementation on Android as long as our security reviewers (Ray Forbes, Lucas Adamski) are driving that decision. With the last decision to go native, the security reviewers were not driving the decision and thus we were "solving" non-existent security problems. 

Specifically, I'd like to see the threat models and solutions before we invest in supporting a native Android payment solution because it is always harder to ship/maintain client code than hosted code.

Comment 7

[Erin Lancaster [:elan]]

Ray, Lucas, can you comment as to whether you would advocate for a native Android payment solution due to specific security concerns (based upon Kumar's comments above)? From a time-to-market and engineering resource perspective the team would still prefer to pursue the hosted shim but please do weigh in so we can make the right decision Thank you.

Comment 8

[Lucas Adamski [:ladamski]]

As Kumar alluded to, I think "native or not" is probably not the best framing.  We should define the threats we want to mitigate then figure out the right balance.  Native has some benefits, such as reducing the attack surface (for compromised servers or MITM) and potentially improving reliability (fewer services / page requests required).  This week I'm at the B2G ww, but we can discuss this next week.

Comment 9

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

I believe rforbes has been working on this from our side, I'm pinging him for input.

Comment 10

[David Bialer [:dbialer]]

Adding User Stories specific to a trusted payment process for Android:

PayAndID-150		As a user, I would like to be informed when I am in a payments or identity experience so that I can be assured that my identity will be protected and payments are secure with a "trusted payment container" (not to be taken as implementation specific like B2G TrustedUI).

PayAndID-151		As a user I should be able to initiate a trusted payment experience inside an app so that I can be assured that my identity will be protected and payments are secure with a "trusted payment container".

PayAndID-152		As a user I should be able to cancel a trusted payment experience (and any/all the processes started inside it) so that I can abort a process and return to what I was doing

PayAndID-153		As a user I should be able to switch from 1 app with trusted payment experience to another using the Android Task Manager. The trusted payment experience should reappear when coming back to the app so I am confident the process is consistent and secure

PayAndID-154		As a user I should be able to reopen an app with an unfinished trusted payment experience process, and the trusted payment experience dialog should reappear so I am confident the process is consistent and secure

PayAndID-155		As a user I should be able to lock-unlock the phone during a trusted payment experience process so I can leave what I am doing and return to it, still confident the process is consistent and secure

PayAndID-156		As a user I should be able to receive a call while executing a trusted payment experience so I am able to switch applications on my phone and "pause" the secure process and return to it

PayAndID-157		As a user I should be able to receive a notification while executing a trusted payment experience so I am able to switch applications on my phone and "pause" the secure process and return to it

Comment 11

[Raymond Forbes[:rforbes]]

i lost track of this bug.  Where are we with this?

Comment 12

[Bill Walker [:bwalker] [@wfwalker]]

(In reply to Raymond Forbes[:rforbes] from comment #11)
> i lost track of this bug.  Where are we with this?

We are currently discussing a mozPay() shim as purely an internal proof-of-concept / debugging aid. Not something we would put into production.

Comment 13

[David Bialer [:dbialer]]

Wondering why proof-of-concept only, and whether we need another bug filed to do the native implementation to implement Android Payment?

Comment 14

[Jason Smith [:jsmith]]

(In reply to David Bialer [:dbialer] from comment #13)
> Wondering why proof-of-concept only, and whether we need another bug filed
> to do the native implementation to implement Android Payment?

The native pieces are tracked in the "Payments frontend for Android" bug. Although that's not required to get this up and running, however.

Comment 15

[Caitlin Galimidi [:c8o]]

Finkle - 

Are we still moving forward with this work or have we found another solution via mozpay.api

Can we close this out as INVALID or WONTFIX?

Comment 16

[Kumar McMillan [:kumar]]

I'm pretty sure we can wontfix this bug in favor of bug 813756

Comment 17

[Jason Smith [:jsmith]]

Based on comment 15 & comment 16, I'm going to go ahead and WONTFIX this bug then.

If Mark disagrees, feel free to reopen.