Hello Lucas - A "fun dialer" might be a phone app that simulates a rotary pone. I'm expecting that the phone API is only available to "trusted" apps (okay, maybe someone going through a bunch of hoops to give a non-trusted app the permissions). You can have several "fun phone" apps on your device. But only a "certified" app has undergone rigorous testing to make sure it handles every case, including emergency calls. That is why it is "certified". And if the system is going to invoke a dialer, it should invoke a "certified" dialer. Particularly for emergency calls which really, really need to work. -Jim Straus
On Apr 30, 2012, at 6:14 PM, Lucas Adamski wrote: > So I'm a bit confused as to the purpose of the dialer API with trusted apps. > The stated use case is "fun dialer" but if the user uses the fun dialer as > their default dialer, and the one time they need it it fails to dial an > emergency number (because the developer failed to account for that use case) > then that seems like a big problem. So that exactly is a fun dialer, and how > is that manifestly different from a certified dialer? > Lucas. > > On Apr 30, 2012, at 12:54 PM, Jim Straus wrote: > >> I believe that the user should not be able to replace their built-in >> telephone app except with a certified telephony app (though they can have >> multiple telephony apps installed) so that we know emergency calls can >> always be made. And that whatever mechanism is used to make emergency calls >> (though the lock screen, etc.) would use the certified app (and the built-in >> app if there are more than one certified apps. Not sure how we would select >> which certified app to use if there are more than one and the built-in app >> has been removed). >> >> On Apr 30, 2012, at 12:13 PM, Mike Habicher wrote: >> >>> >>> Regarding emergency calls: although the regulatory requirements vary, >>> generally, phones must be able to make emergency calls under all >>> circumstances, even if the phone contains no or an invalid SIM card, or if >>> the phone is on a lock-screen. (For example, my BlackBerry lock screen UI >>> has three buttons: Unlock, Cancel, and Emergency Call. If I click on the >>> latter, the UI says, "Press [Phone Button] to attempt an emergency call.") >>> >>> The intent is that under no circumstances should the handset second-guess a >>> user's desire or need to make an emergency call, even in the absence of a >>> subscriber/billing system. >>> >>> (Wikipedia has a fairly good overview of the underlying process--see the >>> "Emergency numbers and mobile telephones" section: >>> http://en.m.wikipedia.org/wiki/Emergency_telephone_number) >>> >>> >>> Sent on the TELUS Mobility network with BlackBerry >>> >>> -----Original Message----- >>> From: Lucas Adamski <[email protected]> >>> Sender: [email protected]: Sun, 29 >>> Apr 2012 21:20:49 >>> To: <[email protected]> >>> Cc: <[email protected]>; <[email protected]>; >>> dev-b2g mailing list<[email protected]> >>> Subject: Re: [b2g] WebAPI Security Discussion: Web Telephony >>> >>> Updated proposal: >>> >>> Name of API: Web Telephony >>> References: >>> https://wiki.mozilla.org/WebAPI/WebTelephony >>> *B2G Meta telephony bug https://bugzilla.mozilla.org/show_bug.cgi?id=699235 >>> *Web Telephony meta bug: >>> https://bugzilla.mozilla.org/show_bug.cgi?id=674726 >>> >>> Brief purpose of API: Make and receive phone calls >>> >>> General Use Cases: None >>> >>> Inherent threats: >>> * Place calls to high cost numbers, >>> * Route calls through high cost network, >>> * Direct calls through MITM network (spying). >>> * Possibly with audio API, record phone calls, record touch tone signals >>> (account numbers?). >>> * In addition, there is a high likelihood that this API will need to be >>> controlled for legal reasons. >>> >>> Threat severity: high to critical, confidential information disclosure and >>> direct financial risk >>> >>> == Regular web content (unauthenticated) == >>> Use cases for unauthenticated code: click on a phone number in an email or >>> browser to dial >>> Authorization model for uninstalled web content: explicit (web activities) >>> Authorization model for installed web content: explicit (web activities) >>> Potential mitigations: When user clicks on a phone number, app triggers a >>> web activity to initiate the call. User interaction required to trigger. >>> >>> == Trusted (authenticated by publisher) == >>> Use cases for authenticated code: >>> * Fun dialers (eg. rotary dialer) >>> Authorization model: explicit >>> Potential mitigations: >>> * UI indication (e.g. small blinking phone icon in the top of the screen or >>> status bar) which can not be hidden when a call is active, and user can >>> interact with to manage the call >>> * We should try to avoid, where possible, giving full telephony API control >>> to an app, just so it can include MyContactList / MyFriendPhoto / >>> MyCoolBackground. Perhaps we should address those use cases through >>> extensibility of our built-in Dialer app. [mhanson] >>> >>> == Certified (vouched for by trusted 3rd party) == >>> Use cases for certified code: >>> * Handler for telephony web activities >>> * Replacement dialer >>> * Voice conference software (e.g. connect Voip with a mobile call)? >>> * Mediate incoming calls (accept/reject/merge) >>> * Query transceiver state >>> Authorization model: implicit >>> Potential mitigations: none >>> >>> Notes: How to handle access to emergency services (ex. 911)? Does the API >>> need to be aware of emergency services and handle them differently from >>> other calls? What about emergency-only access? >>> >>> On Apr 11, 2012, at 10:33 PM, Lucas Adamski wrote: >>> >>>> Name of API: Web Telephony >>>> References: >>>> https://wiki.mozilla.org/WebAPI/WebTelephony >>>> *B2G Meta telephony bug https://bugzilla.mozilla.org/show_bug.cgi?id=699235 >>>> *Web Telephony meta bug: >>>> https://bugzilla.mozilla.org/show_bug.cgi?id=674726 >>>> >>>> Brief purpose of API: Make and receive phone calls >>>> >>>> General Use Cases: None >>>> >>>> Inherent threats: >>>> * Place calls to high cost numbers, >>>> * Route calls through high cost network, >>>> * Direct calls through MITM network (spying). >>>> * Possibly with audio API, record phone calls, record touch tone signals >>>> (account numbers?). >>>> * In addition, there is a high likelihood that this API will need to be >>>> controlled for legal reasons. >>>> >>>> Threat severity: high to critical, confidential information disclosure and >>>> direct financial risk >>>> >>>> == Regular web content (unauthenticated) == >>>> Use cases for unauthenticated code: click on a phone number in an email or >>>> browser to dial >>>> Authorization model for uninstalled web content: explicit (OS mediated) >>>> Authorization model for installed web content: explicit (OS mediated) >>>> Potential mitigations: When user clicks on a phone number, the OS pops up >>>> a prompt asking the user to confirm before dialing >>>> >>>> == Trusted (authenticated by publisher) == >>>> Use cases for authenticated code: >>>> * Fun dialers (eg. rotary dialer) >>>> Authorization model: explicit >>>> Potential mitigations: >>>> * UI indication (e.g. small blinking phone icon in the top of the screen >>>> or status bar) which can not be hidden when a call is active, and user can >>>> interact with to manage the call >>>> >>>> == Certified (vouched for by trusted 3rd party) == >>>> Use cases for certified code: >>>> * Replacement dialer >>>> * Voice conference software (e.g. connect Voip with a mobile call)? >>>> * Mediate incoming calls (accept/reject/merge) >>>> * Query transceiver state >>>> Authorization model: implicit >>>> Potential mitigations: none >>> >>> _______________________________________________ >>> dev-b2g mailing list >>> [email protected] >>> https://lists.mozilla.org/listinfo/dev-b2g >>> _______________________________________________ >>> dev-webapps mailing list >>> [email protected] >>> https://lists.mozilla.org/listinfo/dev-webapps >> > _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
