On Sep 18, 2013, at 12:39 PM, Ehsan Akhgari <[email protected]> wrote:
> 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? Correction: all web content would need access to SIM changes. The use case applies to payment providers that do carrier billing. This type of payment provider would need to persist user IDs (derived from phone numbers) to enable purchases over wifi. When the user swaps SIMs, the provider needs to un-persist the user ID -- thus, they need a notification event. I'm talking about all web content, not content within a Trusted UI. Imagine that PayPal wants to be better at carrier billing on Firefox OS -- this use case applies to them. In fact, all use cases apply to them. They should be able to use the same web APIs that Mozilla uses for carrier billing. -Kumar > > Ehsan > _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
