Sure thing, updated below. This will limit the trusted use case, but
personally I dont think it was that compelling.
We have the Telephony security review tomorrow so we can through it then
if more detail is needed.
Name of API: Web Telephony
References:
https://wiki.mozilla.org/WebAPI/WebTelephony
*B2G Meta telephony bughttps://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 (web activities)
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
On 6/4/12 7:32 PM, Jonas Sicking wrote:
I don't think we'll want a different model for trusted compared to
uninstalled/untrusted content here.
In all cases we should only expose a subset of the API which uses
"intents" to bring up the standard dialer app. I.e. we'd show some
type of notification asking the user if they want to place a call,
either by putting a dialog on screen (this is what iPhone does I
think), or by opening the built-in dialer app with the selected phone
number prefilled.
/ Jonas
On Thu, May 31, 2012 at 2:41 AM, [email protected]
<[email protected]> wrote:
"Final" proposal. Please reply-to [email protected] with any major
issues.
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: Need to ensure that emergency services
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
