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
> * Possibly with audio API, record phone calls, record touch tone signals (account numbers?).
>> * 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-webapps mailing list