159818353: Dynamic Links causes a warning banner to appear under iOS 14

[rhysforyou]

[REQUIRED] Step 1: Describe your environment

• Xcode version: Version 11.5 (11E608c)
• Firebase SDK version: 6.10.0
• Firebase Component: Dynamic Links
• Component version: 6.10.0
• Installation method: CocoaPods

[REQUIRED] Step 2: Describe the problem

When launching my app on a device running the iOS 14 or iPadOS 14 beta, when I've copied something on another device, I get this system generated banner:

This appears to be caused by Firebase Dynamic Links, which attempts to check for a dynamic link saved in the pasteboard by a previously visited landing page.

Not sure what the best solution here is, but we're definitely going to get complaints when users update to iOS 14, launch our app, and immediately see something that looks like us harvesting their data.

[google-oss-bot]

I found a few problems with this issue:

• I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
• This issue does not seem to follow the issue template. Make sure you provide all the required information.

[PycKamil]

There are new iOS 14 Pasteboard API available on, this should probably be used now to avoid getting this banner https://developer.apple.com/documentation/uikit/uipasteboard/detectionpattern/3618951-probableweburl?changes=latest_major

[ryanwilson]

Thanks for the report! And thanks @PycKamil for pointing out the new Pasteboard API. We'll look at getting this resolved quickly because you're right - that's not a good user experience at all.

[eldhosembabu]

May be we should be able to query the pasteboard with new api (https://developer.apple.com/documentation/uikit/uipasteboard/detectionpattern?changes=latest_minor) before trying to access it.

[ncooke3]

Hey everybody,

While we are still exploring potential solutions, we would appreciate feedback on a current approach we are exploring. Feel free to pull in the below version of 'Firebase/DynamicLinks' and let us know if this reduces the issue in your tests.

pod 'Firebase/DynamicLinks', :git => 'https://github.com/firebase/firebase-ios-sdk.git', :branch => 'nc-dl-ios14'

We'll keep this thread updated with future developments!

[rasod]

@ncooke3 Out of transparency could we have some questions officially answered regarding this feature.

1. When does the SDK currently (production version) access the Pasteboard to check for a DL? Every foreground? On Interval? First Launch Only? Other Events.
2. Is the contents of the pasteboard sent off device for any reason? If so why?
3. If the SDK didn’t access the pasteboard at all what features of DL would stop working? It makes sense that the pasteboard is used to complete the journey when the user goes from the landing page of a DL to the App Store then to first run. What other features of DL are enabled by the pasteboard?

Thanks

[paulb777]

Internally tracked at b/159818353

[roelwillems]

@ncooke3 Out of transparency could we have some questions officially answered regarding this feature.

1. When does the SDK currently (production version) access the Pasteboard to check for a DL? Every foreground? On Interval? First Launch Only? Other Events.
2. Is the contents of the pasteboard sent off device for any reason? If so why?
3. If the SDK didn’t access the pasteboard at all what features of DL would stop working? It makes sense that the pasteboard is used to complete the journey when the user goes from the landing page of a DL to the App Store then to first run. What other features of DL are enabled by the pasteboard?

Thanks

This would be very helpful for companies investigating what is happening with there apps. Do you have a time frame for clarification on this topic?

[blwinters]

I saw that a fix was merged into master that will first check pasteboard.hasURLs before accessing it, which is awesome.

In the case of reopening the app and the pasteboard happens to have a URL in it, I believe the pasteboard banner would be shown again which could be confusing for the user. I have a feature request in for this through support, but I'll mention it here for discussion purposes:

It would be nice for the API to allow us to turn off pasteboard checks if the app logic no longer needs to check initial launch dynamic links from the pasteboard (unless I'm mistaken and the check already won't be triggered by subsequent app opens). I see that this commit allows for disabling the pasteboard check entirely via a plist setting, but I'm thinking more of allowing us to only check it once following install, then disabling the check for all subsequent app opens.

[phungkytown]

@ncooke3 I updated by Podfile to target the nc-dl-ios14 branch as you suggested, but am not seeing those changes after running pod install. Do the podspec files need to be updated for that branch so that I don't keep pulling the latest production release?

[paulb777]

@phungkytown You would also need to point all of the dependencies of FirebaseDynamicLinks to their podspec versions in the branch.

An easier way to try is likely to just update a standard Firebase 6.27.* installation with the diffs from https://github.com/firebase/firebase-ios-sdk/pull/5905/files

[phungkytown]

Figured it out. Thanks for the assist, @paulb777!

[noremac]

There appears to be a blessed way to do this now on iOS 14+: UIPasteboard.DetectionPattern. Is there any plan to use this?

[blwinters]

@noremac When I accessed the pasteboard using that API it still showed the banner. I noticed that API is currently only in the Objective-C headers, so seems it is still in motion. Perhaps the behavior will change in a later beta.

[eldhosembabu]

Hi @rasod , Please find official answers for your questions inline below:

@ncooke3 Out of transparency could we have some questions officially answered regarding this feature.

1. When does the SDK currently (production version) access the Pasteboard to check for a DL? Every foreground? On Interval? First Launch Only? Other Events.

During the very first launch of the app (post-install), FDL sdk will check the pasteboard to see whether the app was installed as a result of clicking on an FDL.

It is possible that some apps might have misconfigured their FDL integration, where the pasteboard is checked at every app launch. This happens when the app fails to call dynamicLinkFromCustomSchemeURL method described in FDL docs.

2. Is the contents of the pasteboard sent off device for any reason? If so why?

If the SDK identifies pasteboard content as an url (and the contents look like a FDL short url), the url from the Pasteboard is sent to FDL servers to validate and report the installation count back to the app developer. This data is processed in accordance with the Firebase DPST.

3. If the SDK didn’t access the pasteboard at all what features of DL would stop working? It makes sense that the pasteboard is used to complete the journey when the user goes from the landing page of a DL to the App Store then to first run. What other features of DL are enabled by the pasteboard?

FDL SDK uses the pasteboard for deep-linking post app install (deferred deep-linking, where the link is copied on the app preview page) and app install attribution; otherwise, FDL does not use the pasteboard for anything else.

Disabling pasteboard access affects the app in the following ways:

• Deferred deep-linking will not work as reliably. At best, your app receives weak matches for deep-links.
• App install attribution stats will be less accurate (potentially undercounting app installs).

To disable pasteboard access, set the Info.plist property FirebaseDeepLinkPasteboardRetrievalEnabled to false.

Thanks

[rasod]

@eldhosembabu thank you for the info. For clarity the plist option is available starting on version 6.28.0 of the iOS SDK correct?

[paulb777]

@rasod Yes the plist option was released with 6.28.0. Leaving this issue open for a more complete solution.

[lorenc-tomasz]

@paulb777 Solution on 6.28.x is good enough for now, however maybe it was good to consider add there a condition that disables it only on iOS 14?

[rasod]

As we know, one of the main selling features of DL is the first run experience, where you can take a new user directly to the place that caused them to install the app. That being a social link or a marketing campaign or coupon. Disabling that feature ends up gutting DL. Having the paste notification on the other hand, even only on first launch, is not the best first impression to make. Even if your intentions are good users will assume the worst, and that you are “spying” on them. “No good deed goes unpunished”.

I did file a radar with Apple to suggest an additional detection pattern similar to the current WebURL one, but specific only to the apps associated domains. That way the app would only need to access the pasteboard if the url contained was a DL/URL for that apps website, possibility asking for permission first if it does contain a DL.

Ultimately the writing is on the wall and using the pasteboard for simple inter-app communication is not a viable solution anymore. In the long run App Clips may end up being better approach allowing the app to take the user directly to a specific journey - coupon redemption page, article page, video player etc.

Thanks

[GracieJP]

I'm not able to see this plist attribute after updating to the most recent version. I added the attribute myself but it didn't affect the reading of the clipboard upon launch. Any guidance would be very helpful.

[m-j-g]

I'm not able to see this plist attribute after updating to the most recent version. I added the attribute myself but it didn't affect the reading of the clipboard upon launch. Any guidance would be very helpful.

Yeah I just tried the same thing, same experience. This is really bad.

[impl-kano]

I'm not able to see this plist attribute after updating to the most recent version. I added the attribute myself but it didn't affect the reading of the clipboard upon launch. Any guidance would be very helpful.

Same here ...but solved by clearing the cache and DerivedData.

• Use the SDK above 6.28 and add the property FirebaseDeepLinkPasteboardRetrievalEnabled to false.
• Run the command below

watchman watch-del-all &&
rm -rf node_modules/ &&
rm -rf ios/Pods ios/build ios/Podfile.lock &&
yarn cache clean —force &&
rm -rf $TMPDIR/react-* &&
rm -rf $TMPDIR/haste-* &&
rm -rf $TMPDIR/metro-* &&
rm -rf ~/Library/Developer/Xcode/DerivedData/

then my project works fine now.

[GracieJP]

I had no success with your solution @impl-kano

[albertoramonj]

No success here either

[joaoffcosta]

@GracieJP @nnarayann it may be that the issue is with some other library. Investigate for instance Google’s Mobile Ad SDK which has also been linked with this issue.

I don't think there is a way of knowing which is the offending library without doing something like this: https://hugotunius.se/2020/06/05/snooping-on-the-clipboard-snoopers.html

[m-j-g]

@joaoffcosta
I removed dynamic links from my project and the alerts stopped.

[albertoramonj]

Thank you very much @joaoffcosta. At the end, it was a problem in our side, but you helped us out to find what the real issue was.

[agordeev]

With FirebaseDeepLinkPasteboardRetrievalEnabled set to false dynamic links stopped working on the first app install. On other hand, displaying that the app is reading from the user's pasteboard is unacceptable. Looks like we need to wait for a better solution :-/

[yz]

any update on this?

[henrySSiberian]

Any update on this topic? I think the bug still remains because I have not seen that they have recently released an update of the firebase ios sdk library :/

[eldhosembabu]

With FirebaseDeepLinkPasteboardRetrievalEnabled set to false dynamic links stopped working on the first app install. On other hand, displaying that the app is reading from the user's pasteboard is unacceptable. Looks like we need to wait for a better solution :-/

hi @agordeev could you please let me know whether you are not at all receiving any links after FirebaseDeepLinkPasteboardRetrievalEnabled set to false? You are supposed to get FDL working with a weak/default match. Please let us know if thats not the case. thanks

[yz]

With FirebaseDeepLinkPasteboardRetrievalEnabled set to false dynamic links stopped working on the first app install. On other hand, displaying that the app is reading from the user's pasteboard is unacceptable. Looks like we need to wait for a better solution :-/

hi @agordeev could you please let me know whether you are not at all receiving any links after FirebaseDeepLinkPasteboardRetrievalEnabled set to false? You are supposed to get FDL working with a weak/default match. Please let us know if thats not the case. thanks

Hi, how to get the weak/default match? Is there any code sample?

[misyobun]

With FirebaseDeepLinkPasteboardRetrievalEnabled set to false dynamic links stopped working on the first app install. On other hand, displaying that the app is reading from the user's pasteboard is unacceptable. Looks like we need to wait for a better solution :-/

hi @agordeev could you please let me know whether you are not at all receiving any links after FirebaseDeepLinkPasteboardRetrievalEnabled set to false? You are supposed to get FDL working with a weak/default match. Please let us know if thats not the case. thanks

Hi, how to get the weak/default match? Is there any code sample?

@yz Hi, You can get the weak/default match info like this.

// DynamicLink
if let dynamicLink: DynamicLink = DynamicLinks.dynamicLinks().dynamicLink(fromCustomSchemeURL: url) {
    print(" \(dynamicLink.matchType)") <---------
}

I can guess that the match(weak/default) is based on the device information here.

https://github.com/firebase/firebase-ios-sdk/blob/master/FirebaseDynamicLinks/Sources/FIRDynamicLinkNetworking.m#L208

[abbas-mulani]

Any update on this?

I have done following:

1. Added FirebaseDeepLinkPasteboardRetrievalEnabled and set it to false in Info.plist.
2. Perform diagnosis :

[FIRDynamicLinks performDiagnosticsWithCompletion:nil];

Output : performDiagnostic completed successfully! No errors found.

Then also, it is showing popup of paste board.

[santiagolimas]

Has there been any update on this topic?

[kaz-mercari]

Is there any updates on this?

[paulb777]

I'm going to close this issue, since the original problem was addressed with the plist option in 6.28.0. Please open another issue for related or other questions and issues.