On 2013-09-18 12:37 PM, Kumar McMillan wrote:
On Sep 18, 2013, at 11:22 AM, Ehsan Akhgari <[email protected]> wrote:
On 2013-09-05 12:21 PM, Kumar McMillan wrote:
On Sep 4, 2013, at 6:04 PM, Ehsan Akhgari <[email protected]> wrote:
On 2013-09-04 5:03 PM, Kumar McMillan wrote:
Hi all,
After gaining much experience using navigator.mozPay()
(https://wiki.mozilla.org/WebAPI/WebPayment) to implement Firefox OS payments
it feels like the API may not be useful as a generic API for the broader web.
I'd like to propose deprecating navigator.mozPay() and replacing it with
lower-level primitives that payment providers can use directly. Thoughts and
feedback on this?
The problem: mozPay() adds some features for carrier billing but does so by
imposing a rigid end to end transaction flow. Not all payment providers need to
adopt this end to end flow and many providers already have their own end to end
flow. Awkwardly, mozPay also has a whitelist of who can use it which means
Mozilla (or whoever builds B2G) has to grant access to each provider.
mozPay comes in two parts:
* Developers use navigator.mozPay() to conduct a transaction and disperse
digital goods within their app. This is roughly the equivalent of doing
window.open() and using postMessage to communicate with the new window.
* Whitelisted payment providers (such as Firefox Marketplace) host their custom
payment flow in an iframe controlled by the chrome layer of mozPay. That iframe
has a special global called window.mozPaymentProvider which is defined here:
https://wiki.mozilla.org/WebAPI/WebPaymentProvider
I'd like to propose deprecating mozPay and instead figuring out a way to
securely expose mozPaymentProvider since it exposes primitives that websites
can use to implement mobile payments themselves. This would be a big win for
Firefox OS: anyone on the web could process payments just the same as Mozilla
does.
What are the exact primitives we need to expose?
1. To optimize carrier billing authentication mozPaymentProvider provides an
observeSilentSms method. This allows the payment provider to exchange a
challenge/response via SMS to get an unspoofable link to the user's phone bill.
We could expose this to all web content but we couldn't allow arbitrary numbers
if it were publicly accessible. We would have to whitelist the short codes that
can be used in this function (a short code incurs no cost to the user; it is
paid for by the payment authority). We might also need to prevent DOS'ing a
short code? There won't be too many of these to whitelist. Mozilla could also
host a web service for the whitelist which would make it easy to maintain.
This covers the use case we have for Mozilla's carrier billing and it is a
somewhat typical pattern. FaceTime registration works via silent SMS:
http://theiphonewiki.com/wiki/FaceTime#FaceTime_Activation_.2F_Registration
(Note that some operators support HTTP header injection to link to a user's
phone bill. In that case, the web doesn't need a new API; you can use HTTP
redirects.)
Would that not tie us down to the payment providers who use one of the
white-listed numbers?
I suppose it would, yes. However, the current mozPay already ties us down to
white-listed payment providers, only more brutally. If we expose
observeSilentSms to all web content, we need to protect it from abuse somehow.
It could be abused by web content entering a number that charges the user money
repeatedly in the background without anyone knowing it. Maybe someone has
another idea for protecting it?
Fair enough. Perhaps a white-list of this kind is not very bad after all.
2. Payment providers need to know the user's network. Use cases: the provider
may need to enable/disable certain regions (e.g. when in pre-production) and
the provider needs to know which whitelisted short code to use for silent SMS.
This is currently available as MCC/MNC on mozPaymentProvider. What is the
danger of exposing this to all web content? Do we need to prompt the user like
geolocation?
Can't they just use the client's IP address to obtain that information?
I've been told that IP address is not reliable enough to detect region and
network. There seems to be proxying scenarios that create a lot of edge cases.
Anyway, the fact that IP addresses are already exposed on the web makes me
think that exposing MCC/MNC is not such a big deal.
Yeah, in addition to that the IP address is not useful if you're roaming, or
are connected to wifi, etc.
3. Since carrier billing is tied to SIMs the payment provider must know when a
SIM is/isn't present, when a new SIM is inserted, and when a SIM is removed.
Multiple SIMs should be supported too. Mozilla's payment provider persists
carrier billing identity in a cookie (to avoid repeat authentication) so we
need to know when to delete / recreate that cookie. Currently
mozPaymentProvider exposes an array of ICCs that can be used for this so we'd
want to expose this to all web content. A provider doesn't need to know the
*exact* ICCs, it could use obfuscated values. Can we safely expose these
data/events separately to web content?
Wouldn't that raise fingerprinting concerns? I guess that depends on what kind
of obfuscation you had in mind though.
The main use case here is detecting when one SIM is removed and another one
inserted. That's all we need to solve for payments -- there are probably a
couple different ways to do it safely without enabling fingerprinting. I also
thought of window.addEventListener('moz-sim-changed', ...) or something.
Can we just expose this information to content loaded in the trusted UI?
It is currently exposed *only* in the trusted UI. My proposal is to allow other
non-whitelisted parties on the web to access payment features outside of the
trusted UI. I'm not proposing to un-whitelist the trusted UI because that's a
separate issue that is harder to solve IMO. Baby steps + iteration.
I think I was not clear on this. So, AFAIU it is only the silent SMS
API which requires to be notified of SIM changes, and that API would
only be accessible from the pages loaded in the trusted UI. Assuming
that my understanding is correct, we should be able to only expose the
SIM change event to content running in the trusted UI. Is that correct?
Ehsan
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
