Some followup issues that came up in conversation: 1. There is a regulatory frame around E-911 that we need to understand. Do we need to indicate, through the API, that a device can be used for 911 calls but not other calls?
2. There are two distinct scenarios hidden in the use cases - one is an intent-to-call, as in clicking a tel: URL, which might cause a dialog to popup which confirms the call. The other is replacing the dialer, or the app which handles the intent-to-call, entirely. (which raises the question of multiple receivers for intents and disambiguation thereof) 3. 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. m 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
