New privacy changes to canOpenURL should not be enforced in openURL

Originator:agiletortoise
Number:rdar://21320635 Date Originated:10-Jun-2015 10:47 AM
Status:Open Resolved:
Product:iOS SDK Product Version:iOS 9 beta 1
Classification:Serious Bug Reproducible:Always
 
Summary:
Per the discussion in WWDC Session 703 ("Privacy and Your Apps"), iOS 9 has added new controls to limit the use of the [UIApplication canOpenURL] method to detect the presence of other apps on a device.

The new system using the LSApplicationQueriesSchemes array in the app's Info.plist to whitelist allowed URL schemes is also being applied to the [UIApplication openURL] method.  If URLs with schemes not explicitly declared in the plist are called, the same system log entries are made as those of "canOpenURL" and openURL fails silently.

I believe "openURL" should continue to function on any URL.

The stated goal of preventing app detection using "canOpenURL" can still be acheived without limiting the functionality of "openURL". The user experience for users of apps wishing to open arbitrary URLs may be decreased without a way to detect certain other apps, but since "openURL" will always open the other app, it can not be exploited in the same way as "canOpenURL" to scan user systems.

Steps to Reproduce:
- call [UIApplication openURL] with a URL based on a scheme not declared in LSApplicationQueriesSchemes, but which can be handled by an app installed on the device.

Expected Results:
- URL will be opened by system. 

Actual Results:
- [UIApplication openURL] call fails silently.

Version:
iOS 9 beta 1

Notes:


Configuration:
Any

Attachments:

Comments

As of iOS 10.3.2 openURL will open arbitrary URL not in white list

Simple demo app demonstrates that canOpenURL returns no if not white listed, but openURL succeeds even when canOpenURL says no.

By chuck.krutsinger at June 13, 2017, 8:30 p.m. (reply...)

I tried with the iOS 9 version and this restriction still exists (we are not able to launch another app using a custom URL). How are others working around this?

By venu.thachappilly at Oct. 5, 2015, 3:51 a.m. (reply...)

I posted rdar://21327213

...where I suggest keeping both methods as they were and instead making user give permission for all apps to be opened/checked for.

By claes.jacobsson at June 10, 2015, 9:01 p.m. (reply...)

Same thought here

I have the same thought about this. I will prefer to let user to decide whether they want to authorise the permission or not rather than just block it.

By quentintsai.ucl at June 29, 2015, 2:16 p.m. (reply...)

Engineers say it's a bug in `openURL:`

I just spoke to the presenter of the "Privacy and your App" session at the Security and Privacy Lab. She indicated that openURL: should behave as it always has in iOS 9 and was glad to see the blog post and radar.

She said that "universal links" in iOS 9 are a possible alternative to this issue and recommended the "Seamless Linking to Your App" session at WWDC (Thursday @ 3:30).

By peter.kamb at June 10, 2015, 6:27 p.m. (reply...)

Thanks, duped: rdar://21321998

This bug also does affect our Where To? app which integrates with 50+ 3rd party navigation apps, some of them supporting x-callback-url.

By futuretap at June 10, 2015, 5:06 p.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!