Security considerations need details #26

marcoscaceres opened this Issue May 20, 2013 · 12 comments


None yet

3 participants


The security considerations need to be more detailed - i.e., explain why the API can only be used with trusted content.

zolkis commented May 22, 2013

Indeed, we need a list of threats and resolutions. I have some in mind, will update.

@marcoscaceres marcoscaceres added a commit to marcoscaceres/telephony that referenced this issue Jun 10, 2013
@marcoscaceres marcoscaceres Added an issue in spec regarding bug #26 262265d
@marcoscaceres marcoscaceres added a commit to marcoscaceres/telephony that referenced this issue Jun 11, 2013
@marcoscaceres marcoscaceres Added an issue in spec regarding bug #26 26406c8
jplyle commented Jun 18, 2013

Yes, this definitely needs more detail. Below is a bit of brainstorming for this document and/or the runtime & security document.

I'm not an expert on this API, but it appears to offer way more to developers than Android or iOS, which only allow calls through intents / IPC. It isn't entirely clear whether you would ever have more than one application using this API on a device, and whether it would ever be replaced by anyone other than the handset manufacturer / OS provider.

Threats to the telephony API:

  • The API could be used to create a denial of service condition on the phone, preventing it from making other calls.
  • The API could be misused by multiple devices to launch a DDoS attack on a remote call system (e.g., emergency numbers, helpfully listed).
  • The API could be used to obtain information about who the current user is calling and communicating with (privacy).
  • The API could be used to make calls to premium-rate telephone numbers, costing the end user money.
  • The API could be misused to launch distributed telephone "spam" campaigns.
  • The API could be misused to impersonate the user for identity theft and to defeat 2-factor authentication
  • The API could be misused accidentally, causing the user's device to call numbers in an unwanted or unexpected fashion, costing them money.
  • The API could cause embarrassment by calling numbers unexpectedly.
  • The API could call a number other than the one the end user was expecting, resulting in loss of money, or (in effect) eavesdropping / confidentiality loss / embarrassment.
  • The API could be misused to call USSD codes to reset the phone, wipe the SIM card, and more (See: "Dirty USSD hack").
  • The API could be misused to access the user's voicemail recordings.
  • The API could be misused to dial an outside number at an unexpected time, effectively eavesdropping on the end user. It could also record calls.

Some potential security requirements:

  • The API should only be used by offline, static applications certified by a trusted party. No remote content should be able to use this API.
  • Applications that use this API should come from an authentic source and there should be a mechanism to ensure their integrity. Any application that can use this API should be remotely removable (unless no other emergency dialling apps are available)
  • The API should have different behaviour when used with premium-rate numbers. For instance, it should require an additional permission declared by the application and require further consent by the end user. There might even be a different way of invoking the API when using a premium rate number compared to a normal number. The ability to detect that a number is premium-rate is a requirement placed on the implementing platform.
  • The API should have different behaviour when using 'special' characters such as '#*' etc.
  • It should be obvious, visually, when the API is invoked and a call is being made. This call information should be brought to the foreground and it must not be possible for an application to hide this indicator.
  • It should not be possible to side-load an application that has access to this API.
  • Rate limiting should be introduced to prevent an application making too many calls in too short a period of time.
  • User consent should be required before a call can be made.
  • The fact that a call has been made should be displayed to users immediately after it has ended, unless the user has interacted with the device call interface at an earlier date (e.g., it should not be possible to make a call and for the user to never have interacted with the device).

B2G documentation:

Apple Phone URL scheme:

Dirty USSD incident:

zolkis commented Jun 18, 2013

Thanks, John! I will include the text, with an Acknowledgement.


Agree! This is great @jplyle! Thanks for putting that together. It justifies why this API can't be exposed openly quite nicely.

Some reactions: I don't see the harm in having multiple dialer apps - as long as they are properly vetted. It is also somewhat of a requirement that dialer is only access through some kind of intent, but the API itself if agnostic to that.

@zolkis please hold off integrating this text until I've finished the noLegacyStyle migration. I'm making good progress on that.

jplyle commented Jun 18, 2013

@marcoscaceres - It's not necessarily that multiple dialler apps would be harmful, more that I don't see the point in them. For 80% of all use cases, this API gives more power than needed when compared with a simple Intent-like API, as you find on Android or iOS. That power can easily be abused.

The only app that would really use this kind of API is a dialler. I don't consider it likely that you would have more than one of those on your system at any time. Furthemore, It would be a security nightmare to allow users to download new and exciting diallers to replace the stock version on their handset. No ecosystem / app store / manufacturer in their right mind would allow this option.


I might be wrong about the apps that would use this API. Are there any documented use cases?

It also seems to me that there is a heavy burden on implementers to get the UI right for this API. I would go as far as to suggest that this API requires some example UIs. It would be extremely easy to implement this API in an insecure fashion.

zolkis commented Jun 18, 2013

@jplyle - You are right that this API is meant for dialer apps. This API is not for normal apps. Therefore the security policy can be tight on it. For normal apps it is enough to have a phone URI scheme, or intent-like mechanism, which invokes the dialer. Also, normal apps eventually only want to know whether there is an ongoing call in the system, and what media channels are taken. But this is in the scope of a different API.

I also wondered in the beginning why do we think there would be a need for multiple dialers, but yes, there is.
There may be a system dialer which handles GSM/CDMA calls. One may implement an alternative dialer offering some extra service, or different user experience etc.
There may be a separate system dialer which handles e.g. SIP calls. One may implement an alternative dialer supporting multiple protocols. And so on.

Perhaps these clarifications could be added to the text.

" It would be extremely easy to implement this API in an insecure fashion."

That is true, but it is not the API's responsibility to enforce security policies. The implementations should build the security mechanisms, and the device makers/stores define the security policies.


The use cases are in the sysapps wiki. We will move them into the spec before Last Call. The use cases need to be further expanded to capture some of the restrictions above.

Would like to hear more about the UI examples. Is this something you might be able to help with?

jplyle commented Jun 18, 2013

@zolkis The API should explain the security requirements that it places on the runtime. This might all be divorced from the API and moved into the Runtime specification, but it should be somewhere. In my opinion, the API should, at the very least, describe the expected security policy that a platform might implement in order to use the API in a secure way. No expectations about the UI that should be displayed are given, either, and it only takes a brief look at the threats to spot that these are essential to the security of the overall system.

I'd also like to suggest that you avoid using the term "trusted" and instead spell out exactly what you mean. "Trust" is a dangerous word, as it has multiple meanings and connotations and is known to be unhelpful [1]. What I think you mean is that this API should only be exposed to applications that have been vetted by the handset manufacturer or operating system vendor. You also probably mean that applications must be of a high quality and of a known authenticity, free from interference by any external party. A pointer to the runtime and security specification might be the best way to achieve this.

@marcoscaceres - I've made the same suggestion on the WebCrypto API. Essentially, a usable graphical interface is an essential component of any implementation of the API, for security and privacy reasons. It is therefore irresponsible to produce a standard specification where such a large burden is placed on the UI, without making it clear what a satisfactory UI might be (in terms of requirements and even mock-ups). At present, an implementer is left with little choice but to make guesses, and will get this badly wrong. Worse still, there may not even be a right way of doing it - which would imply that the API needs redesigning.

Browsers have such a terrible history in this respect - see, for instance, every attempt to display SSL warnings - and I think we should learn from this. UI guidelines (and proof of concept) ought to be a minimum requirements on new APIs.



@jplyle I think @zolkis and I in violent agreement about the points you are making - we are asking if you want to help take over editing the security aspects and guidance? We can then collectively evaluate what impact this has on the API design itself.

jplyle commented Jun 18, 2013

Ok, great. I probably can do this. Are there any deadlines looming?


@jplyle awesome! :) No, there are no hard deadlines. The first public working draft will be published today (or Thursday) - but then we free to continue exploring the problem space. However, we should have something concrete by the F2F in August - by which point we should be ready to go to (first) Last Call.

@jplyle jplyle pushed a commit to jplyle/telephony that referenced this issue Jun 18, 2013
John Lyle Improve security & privacy guidance
This is a first attempt at listing some of the threats and
potential mitigations for this API.  It does not cover
user interaction guidelines, and is a bit vague about the
mitigations.  It also does not really consider privacy in
much depth.

Issue #26

Added @jplyle as Editor. Closing this for now. Will make a separate bug for user interaction guidelines.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment