The security considerations need to be more detailed - i.e., explain why the API can only be used with trusted content.
Indeed, we need a list of threats and resolutions. I have some in mind, will update.
Added an issue in spec regarding bug #26
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:
Some potential security requirements:
Apple Phone URL scheme:
Dirty USSD incident:
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.
@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.
@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?
@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 . 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.
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.
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
Added @jplyle as Editor. Closing this for now. Will make a separate bug for user interaction guidelines.