897773 - USSD App Development

Status: RESOLVED DUPLICATE of bug 1199141

(Firefox OS Graveyard :: General, defect)

Description

[arky [:arky]]

Allow developers to write apps using MMI/USSD window.navigator.mozMobileConnection. Currently these API are available for certified Apps only. 

USSD is used extensively in Africa to provide innovative services such a m-pesa (http://en.wikipedia.org/wiki/M-Pesa)

Comment 1

[arky [:arky]]

Another alternative use case is Vumi http://vumi.org/ The platform allows developers to create high social impact project based on USSD.

Comment 2

[Gabriele Svelto [:gsvelto] (PTO)]

Would this functionality need access only to mozMobileConnection.sendMMI() (i.e. solicited MMI/USSD messages) or is support for unsolicited messages also required? I'm not sure if we already have a bug regarding access to mozMobileConncetion (and the Telephony API in general) from privileged applications but I wonder if it would be possible to open up just a minimal subset of the functionality needed to implement some of those services.

To elaborate a little bit on this I wonder if it would be possible to whitelist a set of custom MMI codes we know wold be harmless on general networks and enable privileged applications to use those with a specific permission. Would this be enough for implementing the services you pointed out or would those need unrestricted access? I think that the main security issue regarding MMI codes is that some of those enable you to interact directly with your carrier - for example enabling services and such - which might cause extra charges, so giving unrestricted access to privileged applications might be risky in general.

Comment 3

[smn]

As a USSD app developer I'm mostly interested in being to initiate USSD requests from an app and intercept the responses and use that as a data layer for when there is no network data coverage. 

Network initiated USSD does exist but it's not widely used yet in the commercial / app space. The places I've seen it used most frequently is by banks (auth tokens) or by carriers (post-call notifications of pay-as-you-go account balances). It is interesting from an application development perspective but current use-cases don't hint at widespread adoption (nor the carriers making it easily available) any time soon.

Comment 4

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to smn from comment #3)
> As a USSD app developer I'm mostly interested in being to initiate USSD
> requests from an app and intercept the responses and use that as a data
> layer for when there is no network data coverage. 

You might be interested in following the work on bug 889737 and bug 1031193. Currently the MMI API is implemented in a way that would make tracking responses to an USSD request almost impossible as there's no kind of coupling between a request and the response. bug 1031193 comment 8 contains a design proposal that introduces the concept of an USSD session which wo making it possible for apps to implement request/response patterns. This could pave the way to opening up the API to privileged apps since we should be able to restrict the responses from a request only to the app that initiated it.

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Gabriele Svelto [:gsvelto] from comment #4)
> (In reply to smn from comment #3)
> > As a USSD app developer I'm mostly interested in being to initiate USSD
> > requests from an app and intercept the responses and use that as a data
> > layer for when there is no network data coverage. 
> 
> You might be interested in following the work on bug 889737 and bug 1031193.
> Currently the MMI API is implemented in a way that would make tracking
> responses to an USSD request almost impossible as there's no kind of
> coupling between a request and the response. bug 1031193 comment 8 contains
> a design proposal that introduces the concept of an USSD session which wo
> making it possible for apps to implement request/response patterns. This
> could pave the way to opening up the API to privileged apps since we should
> be able to restrict the responses from a request only to the app that
> initiated it.

Not sure if I misunderstand the comment here. However, after the new API of bug 889737, I believe it's still impossible to bind a USSD request (not just MMI request but USSD) and its response since the USSD response is still coming from an unsolicited event "ussdreceived."

Comment 6

[Michael Schwartz [:m4]]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #5)
> Not sure if I misunderstand the comment here. However, after the new API of
> bug 889737, I believe it's still impossible to bind a USSD request (not just
> MMI request but USSD) and its response since the USSD response is still
> coming from an unsolicited event "ussdreceived."

"ussdreceived" should only be for network initiated and according to comment #3 the network initiated requests are not used so the current API would work as long as the app has the privileges to use the Telephony.dial() API.

Comment 7

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Michael Schwartz [:m4] from comment #6)
> (In reply to Hsin-Yi Tsai [:hsinyi] from comment #5)
> > Not sure if I misunderstand the comment here. However, after the new API of
> > bug 889737, I believe it's still impossible to bind a USSD request (not just
> > MMI request but USSD) and its response since the USSD response is still
> > coming from an unsolicited event "ussdreceived."
> 
> "ussdreceived" should only be for network initiated and according to comment
> #3 the network initiated requests are not used so the current API would work
> as long as the app has the privileges to use the Telephony.dial() API.

For the use case in comment 3, even it's the case about a user-initiated request, the response is however still coming from UNSOLICITED_ON_USSD, and that response is sent to APP via the system message "ussd-received".  Per ril.h design, there lacks of a determined link b/w the response and a request. So App needs to rely on "ussd-received" notification.