Why does openURL:"tel:// " require user confirm in iOS10.3?

I read below text in iOS 10.3 Beta4 release note.


When a third party application invokes openURL: on a tel:/ facetime-audio:/, or facetime-audio:/

iOS displays a prompt and requires user confirmation before dialing.


Is this new feature or a bug in iOS 10.3 Beta4?




Replies

Could be in response to this https://9to5mac.com/2017/03/06/911-ios-exploit/

It's probably a feature, but a super annoying one.

Totally agree ... to what I understand there were some apps in the past automatically initiating phone calls resulting in DDoS attacks to e.g. emergency call centers (911). So I agree that Apple should implement a mechanism to prevent misuse of the openURL feature related to tel://. But showing a prompt to the user is really the worst solution I could think of.


I'm sure there are many apps alreading doing it the right way today and showing their own UIAlertView. Using those apps you'll get now two prompts in a row, one from the app and an additional one from iOS. How bad! So should we add something like if (iOS >= 10.3) then dismiss UIAlertView and directly call openURL? In my app I already implemented an own UIAlertView but in some situations there are more than one option (e.g. "Call via iPhone", "Call via FRITZ!Box Call Through", "Call via FRITZ!Box Click To Dial" ...) so I can't get rid of my own UIAlertView. 😟 ... UX at its best. Would it be possible to get a handler to the iOS generated prompt to add own options (buttons) to it?

But what is the purpose of App Review if not to weed out malicious apps like this?


It seems like the software Apple (apparently) uses to automatically determine (for instance) if an app is using an undocumented API, could also detect calls to openURL, rather than forcing users to see this alert every single time they want to call from an app.

I'm in a similar situation having an action sheet with "Call 123…" and "Skype 123…". So having the system prompt after that is really annoying.


I agree that malicious apps might abuse the tel: URL. However, the chosen remedy in 10.3 seems suboptimal and punishes all users for a small number of malicious apps.

I propose one of the following alternate solutions:

  • Only blacklist a certain set of "dangerous" phone numbers such as 911, 112, 110, and premium toll numbers. Display the alert only for such dangerous numbers. International phone numbers might be added to this black list as well to prevent accidental international calling charges. (This requires a deep, non-trivial understanding of phone numbers. Libraries such as libPhoneNumber can accomplish this.)
  • Make using the tel: URL a similar privilege as one of the privacy settings that must be approved at first use. This would require a usage description key in Info.plist. That way, App Store review can easily identify apps that need this privilege and test accordingly. Apps that don't add the Info.plist key, should fall back to always showing the confirmation alert.
  • Provide a hook to allow adding other options (parameters: title + URL + completion block) to the system supplied prompt. This would allow us to add options to call using alternate providers such as Skype, or using alternate numbers (via the tel: scheme) such as certain dialing prefixes etc. The completion block should inform the app if the call was successful or not, potentially with an error object.


Logged as Radar 31153464 (also on Open Radar).

Can this be fixed/bypassed with the new openURL:options:completionHandler: method in iOS10 or will iOS still displays the prompt?

I think many existing apps are suffering from this change.Maybe it's introduced due to some security consideration.But I don't think this is necessary or best choice.

To mitigate the security consideration, why not add a checkbox "not alert any more" when the popup displays for the first time? It should acceptable because users are already aware of the risk, as well as have the full control on this kind of alert. If he/she chooses to suppress it, then the alert will not display any more. I think this is a common design for many softwares.

Please consider. Thanks in advance.

Apparently, you've never heard of "**** dialing"... These protections are in place to protect the user from unintended, unwanted calls. If your app uses this behavior, your app is behaving poorly and will likely be removed very quickly by anyone who finds the behavior annoying. Personally, any app that calls anyone without me specifically instructing it to do so, is removed within seconds of discovering this. My phone, calls those I wish it to call and ONLY those I wish it to call, when I want it to do so.

What you may not realize is that those apps, like mine, which are an explicit request by the user to make a phone call, are now totally annoyed that I cannot override this new step returned to the openURL protocol after about 6 generations of it being removed.


This changes wipes out single touch dialing by any 3rd party app.

The option:


Make using the tel: URL a similar privilege as one of the privacy settings that must be approved at first use. This would require a usage description key in Info.plist. That way, App Store review can easily identify apps that need this privilege and test accordingly. Apps that don't add the Info.plist key, should fall back to always showing the confirmation alert.


Sounds like a great compromise, the user decides which application is allowed to call on 1st use - this will solve the issue for all quick dial apps and Apple gets the option to test the apps requesting this privilage.

I agree. It's annoying. Have you reported this issue to Apple?

I'm actually surprised this is the only thread on this issue.


Firstly, I applaud Apple for fixing the issue of 3rd party apps calling emergency services automatically / without prompt, that is definitely a good thing.

However, the solution as is prompts for all phone numbers, which, if your app already prompts to call a number (e.g. with a button that says "Call ***") then this change aggrevates and confuses users.


I have submitted a bug report with feedback that the scope of the prompt should be changed under #32124347.


But I am also supportive of the suggestion from Dieg of it being another permission granted to the app by the user when the app starts.

Has there been any response to the bug report? Any other knowledge about whether this is a bug (to be fixed) or permanent feature ?


I agree that two taps to place a call, or three taps (!!) if an app is using UIAlertView as noted by CodingBandit is a frustrating user experience and there must be a better way to mitigate risk of a single touch dial button. Some great suggestions in this thread.


The issue I am facing is this wipes out my ability to measure call duration, because I cannot extract from IOS how long the user sits there and stares at the system alert. They could look at it for 10 minutes, confirm and place a 1 minute call, my app will log an 11 minute phone call.


Can anyone suggest a fix for measuring call duration?


Perhaps a timestap or something of the system alert?

Maybe you could use CXCallObserver.