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-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
