WebAPI Security Discussion: Web Telephony

[Lucas Adamski]

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

[Mike Hanson]

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

> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g

[Randell Jesup]

[ Reposting via mail interface because attempts to cross-post responses
in News appeared to cause my message to end up in approval queues for
the relevant mail lists - and no one appears to have approved them, at
least not in security and B2G ]

>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?

And don't forget that the regulatory issues are quite different from
country to country.

--
Randell Jesup, Mozilla Corp

[Lucas Adamski]

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?

[Jim Straus]

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

> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g

> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps

[Lucas Adamski]

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.

[Jim Straus]

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