On Thursday, 16 May 2013 00:22:47 UTC-4, Jonas Sicking wrote: > 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. > > > > > > > > > > > >
Operators are well established to whitelist the short codes that are used. Charging customers for the silent SMS is really not a concern. binary SMS sounds like the best method. wilfred _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
