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 <ladam...@mozilla.com> > Sender: dev-b2g-bounces+mikeh=mozilla.com@lists.mozilla.orgDate: Sun, 29 Apr > 2012 21:20:49 > To: <dev-weba...@lists.mozilla.org> > Cc: <dev-web...@lists.mozilla.org>; <dev-security@lists.mozilla.org>; dev-b2g > mailing list<dev-...@lists.mozilla.org> > 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 > dev-...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-b2g > _______________________________________________ > dev-webapps mailing list > dev-weba...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-webapps _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
