AppLinks assetlinks.json appears not to be used for validation

Question

I'm implementing app links on Android. Our server team have hosted assetlinks.json on our dev end point /.well-known/assetlinks.json.

In my apps manifest, I've written the intent filter as per the official documentation like so:

<!-- Intent filter for supporting deep linking (referred to as magic login links) -->
<intent-filter
    android:autoVerify="true"
    tools:ignore="UnusedAttribute">
    <action android:name="android.intent.action.VIEW" />

    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />

    <data
        android:host="@string/app_link_login_host"
        android:scheme="https" />
    <data
        android:host="@string/app_link_login_host"
        android:scheme="http" />
</intent-filter>

Now, as I understand it, when the app is first run, the Android OS will search the manifest for all intent filters which contain a host/scheme pair, where autoVerify=true, and the VIEW action and DEFAULT and BROWSABLE categories are present. It will then go to the host URL and request the assetlinks.json file from the /.well-known/ path, and use the SHA hash and package name within this json file to validate the app is allowed to accept deep links from the given host. If this succeeds, then the app should be flagged as status: always with respect to links provided from the host within the intent filter. If it fails, then the app would be flagged as status: never for the host.

However, our server team have setup a new endpoint for staging and they have NOT uploaded the assetlinks.json file to the /.well-known/ path (in fact they haven't hosted it at all). Yet the application is still hooked up to accept links from the host specified in the manifest (when it should have failed validation due to no assetlinks file being present on the end point).

This is when I realized that perhaps the dev endpoints assetlinks.json file was never being used for verification of the application either, and I've only just noticed because the deep link still worked on the staging environment (when it shouldn't have).

Is this a bug with Android OS (in other words, it's not doing assetlink checking at all?). And yes, I did an uninstall of the old application that was pointing at dev server before installing the version that points at staging...

Here are the official docs:

https://developer.android.com/training/app-links/

And here is the paragraph in particular which is the root of my problem (as it clearly states that if ANY of the hosts do not resolve an assetlinks.json file at the /.well-known/ path (including validating the retrieved assetlinks.json file against the client application) then the application will not be hooked up to accept the links (i.e. status: none).

When android:autoVerify="true" is present on any one of your intent filters, installing your app on devices with Android 6.0 and higher causes the system to attempt to verify all hosts associated with the URLs in any of your app's intent filters. Verification involves the following:

The system inspects all intent filters that include:
Action: android.intent.action.VIEW
Categories: android.intent.category.BROWSABLE and android.intent.category.DEFAULT
Data scheme: http or https
For each unique host name found in the above intent filters, Android queries the corresponding websites for the Digital Asset Links file at https://hostname/.well-known/assetlinks.json.
Only if the system finds a matching Digital Asset Links file for all hosts in the manifest does it then establish your app as the default handler for the specified URL patterns.

Evincive

During a clean install of the app, check logcat for IntentFilterIntentSvc and SingleHostAsyncVerifier. – Allegorical

I will do that when I get hoe in 30 minutes – Evincive

@SimonMarquis - Ok, I did as you suggested and indeed the verification process failed (as it should have), but why then does my app still get linked up (verified via the adb shell dumpsys package domain-preferred-apps command.... – Evincive

App Links feature is not mandatory. If it is not set, or invalid, it will still fallback to the old deeplinking methods with a disambiguation dialog. And this dialog might not even show up if the application is set as a default (in the System settings). – Allegorical

@SimonMarquis - Are you 100% sure about this? Because here is a proposed problem with that (which my senior at work is concerned about): let's say I have created an application called TEST and it uses the deep links. Then, let's assume some malicious 3rd party creates an app called T3ST and set the manifest up to handle deep links from my end point. If a user accidentally installs T3ST instead of TEST, then that 3rd party application can re-route the potentially secret information to a server without ever having physical access to the device. – Evincive

When I first read the documentation, I was also under the impression that the assetlinks/applinking was purely to do with setting up the default handler for deep links (and had nothing to do with security). But, upon further reading, the official docs do explicitly state that it's a security feature: Android App Links offer the following benefits: Secure and specific: Android App Links use HTTP URLs that link to a website domain you own, so no other app can use your links. developer.android.com/training/app-links – Evincive

Yes, any application can use the same deeplink. But then, a disambiguation dialog will appear, until the user choose to 'always open with'. AppLinks helps prevent other apps to be opened instead of yours (no more disambugation dialog). But if your app isn't already installed, any third party app might handle the deeplink. (Don't store sensitive data in urls anyways) – Allegorical

Hi @SimonMarquis, I've just posted a similar question, related to Oauth2 on Android, can you please check it out ? Thanks! #51825049 – Quadripartite

@SimonMarquis, do you mean a third-party app can handle the deep link, but not app link? Yes, in any moment of time. But app link protects from capturing URL, if that domain belongs to you. – Orfinger