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)

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

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.

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.

(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.

(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."

(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.

(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.