Hi Guys, Spent the last few days digging my way out of email and got to this one.
The main problem here sounds like the fact that the user may incur charges for either the incoming, the outgoing or both SMSs. To make matters worse we have no idea how big charges. And to make matters yet worse, I assume that once BlueVia knows the phone number, it might realize that it doesn't have the appropriate business relationships in place to actually charge that number? So what can we do to lessen these problems? One thing we could do is to check the SIM card to see if we can get the phone number from that, and if we can avoid sending the MO message (we'd still need the MT message). This obviously won't always help, but seems like it often could. Though maybe not in our currently targeted markets? Second issue is that we should make sure to avoid international charges if we can. Can the number that we are sending messages to/from be made local? We should be able to detect even scenarios like the user currently roaming to determine if international charges will apply or not. Basically what I'm suggesting is to surface the following information to the payment provider: * User's current phone number (if available from SIM) * User's current MCC/MNC (could be multiple for multi-sim devices) * User's home MCC/MNC (could be multiple for multi-sim devices) * Ability for payment provider to send a MO message to an arbitrary number (including which sim for a multi-sim device) * Ability for payment provider to be notified when there's an incoming message from a particular number. This notification would include the message body. This way the payment provider can display UI which lets the user know how many messages will be sent, and if they will be international/roaming messages or not. Or is this overly complex? Should we skip the MCC/MNC stuff and let the payment provider simply show UI saying "you may be charged for one or two SMS messages which may be international. This is a one-time cost"? / Jonas On Fri, Mar 22, 2013 at 4:33 PM, Kumar McMillan <[email protected]> wrote: > > On Mar 22, 2013, at 6:16 AM, "Jimenez Ernesto (UK)" > <[email protected]> wrote: > > On 21 Mar 2013, at 22:54, Kumar McMillan <[email protected]> wrote: > > Hi Fernando. > I am a bit uneasy of adding this feature to the mozPay API because it feels > like a hack :) but it totally makes sense to do so in our case. Some > responses inline: > > On Mar 19, 2013, at 11:30 AM, Fernando Jiménez <[email protected]> wrote: > > [...] > At a high level overview, the silent SMS flow would consist in the following > steps: > > a. The payment provider requests the send of an SMS to a short number > defined by the carrier. The short number could be stored as a preference in > the device and might be tied to the payment provider's origin. > b. An SMS containing a randomly generated ID is sent to that short number. > The ID would be used later to identify the corresponding reply. > c. Once the carrier receives the SMS, it generates a token an replies back > to the origin number with a new SMS containing the ID and the generated > token. > d. The device receives the SMS and gets back to the payment provider flow > (via DOMRequest callback) with the generated token. > e. The payment provider can use the received token to check with the carrier > the user's identity to continue with the payment process. > > > I don't see why we would need to have both MO (mobile originated) and MT > (mobile terminated). If mozPay() generates a random ID on the device, sends > it to the short code (the MO flow) then why not just follow up with a web > request like this: > > GET https://payment-provider/did-you-receive-my-sms/randomID > > If the answer from the server is yes, then the payment can continue because > the operator got the MSISDN from the first silent SMS and can link them by > randomID. Do we have access to a good enough /dev/urandom on the phone? If > so, then we can probably generate an ID that cannot be guessed. Thus I > wouldn't see any reason for the device to *receive* a confirmation SMS. It > seems redundant. > > > It depends on whether the SMS reception is safe from SMS spoofing or not. > > Some SMS-based phone authentication protocols sends and receives an SMS to > have proper authentication even in the cases when you cannot trust the > source of an SMS. > > In other cases where you can be certain you cannot trust the SMS source, > receiving the SMS in the terminal is not needed. > > > > Ah, okay. Based on this and what Antonio explained, it sounds like we would > need to wait for an incoming SMS to make sure an attacker wasn't sending a > made-up phone number and to cover all cases. > > > > > Sending an SMS to a short code, as I understand incurs no charge to the > user. However, *receiving* an SMS back from the mobile operator will incur a > charge. > > > Both Sending and Receiving SMSs may incur in charges. That depends on your > agreements agreements and varies per operators and per country. > > You will need the agreements with operators to zero-rate the SMSs and the > market will need to be careful about not sending SMSs when they are not > zero-rated or letting the user know they might be charged to avoid surprise > charges. e.g: https://discussions.apple.com/thread/2558450 > > > Ouch! That iOS situation is not good. > > > > The first challenge here is how to achieve step (a) so we let the payment > provider request the send of an SMS knowing that the payment provider flow > is web content that has not the possibility of requesting WebSMS API > permissions. > > As some of you already know, the navigator.mozPay API triggers the creation > of a trusted UI that embeds the content of the payment provider flow. The > API implementation injects [6] two functions in the corresponding payment > flow to allow the payment provider to complete or cancel the payment process > and to return the control to the caller application. Basically, the idea for > the silent SMS flow is to inject an additional function in the payment flow > to allow the payment provider to request a silent SMS flow to get the user's > authentication. So the payment provider facing API would have a new function > like: > > DOMRequest doSilentSMS(); > > > This sounds like the best solution. I also like putting the short code on > the phone as a pref. We don't want to give web content any way to send > arbitrary SMS's. > > > Take into account the market might need to manage different short-codes > depending on the country/operator. > > > Hmm, so a device preference may not be the best way to get short codes. > > > > > This function might probably need a new explicit permission, so we let the > user choose if she wants to allow or not the payment provider to send SMSs > on her behalf. Jonas, any thought about this? You already expressed some > concerns about privacy regarding navigator.mozPay before [7]. > > > From a UX perspective I think we need to be careful about adding yet another > prompt. As you saw from the first-time flow up above, it is already > complicated. Also, if the device only sends a silent SMS after the user > clicks "charge my phone bill" then the user would be implicitly granting the > mobile operator permission to know about her MSISDN :) > > > +1 to not have the prompt on sending SMSs on your behalf. > > The market might need to prompt the user with a "You might be charged" when > you are not certain whether SMSs are zero-rated. > > > > I still think receiving an SMS that the user may be charged for could be > problematic. > > > As I commented, you would need to be careful sending the SMSs too. > > > > _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
