

Using DNS to solve the mobile deep linking problem - danielrhodes
http://drhod.es/dns-deep-linking

======
redbeard0x0a
Android actually has functionality built in that can recognize certain URL
patterns and offer up a chooser of which app to open the link in.

You can register something like
[https://example.com/posts/{post_id}](https://example.com/posts/{post_id}) and
have it open the posts activity and show the specified post (if the user
chooses to open the url using the 'Example App'). If the app is not installed,
the url is opened by the default handler of https...

~~~
danielrhodes
Yeah I've seen things like this before. The problem is that any app could
register to listen to those addresses, and that opens up an avenue for mis-
leading the user. I'm sure Google would not like it if the Bing app started
trying to become the handler for google.com URLs. Likewise on iOS anybody can
submit an app which listens to the fb:// URL. Overall it seems unsafe.

~~~
dozy
> I've seen things like this before

It's actually pretty common in Android. Methinks you're an iOS user :)

> any app could register to listen to those addresses

This is core to the Android IPC design. Apps/Activities describe what they can
handle (Intents, actions, filters), and I think it works pretty well. Android
will ask you if you want the given app to be the default or not, and you can
always un-set the default. Also, if you have a new app that can handle the
given link, the next time you try to launch that link you'll be prompted to
see if you want to use the new app, and your previous selected default will be
highlighted as a reminder.

Also, I'm generally a believer that if an app is registering for an Intent
action filter that it does not handle well/shouldn't handle at all, then users
will give it a lot of bad review feedback, and apps will trend towards doing
the right thing.

------
jerluc
[Full disclosure, I'm a current employee at URX] We had actually briefly
discussed potentially using DNS to help resolve the linkage between a given
host/domain and its corresponding mobile apps. However, the problem lies in
that we need to discover the linkage from HTTP URL => deeplink URI, which
means we need _page-level_ mappings, something that can't exactly be done with
TXT records at the domain-level alone.

Android has IMO done a good job of supporting deeplinks to some apps "just
work" by allowing apps to handle HTTP URLs with specific host + path patterns
(though it is noteworthy that this can lead to security problems!), but iOS
does not support this same functionality.

I do, however, agree with the author in that a more seamless integration
pattern that can use existing infrastructure would be ideal, but it seems that
for now, the pattern of using metadata, HEAD requests, or Link headers in
responses is as good as it gets.

~~~
josteink
> Android has IMO done a good job ..., but iOS does not support this same
> functionality.

So basically the "problem" outlined here is not a problem in itself, but
merely a limitation in iOS and iOS is what needs to be fixed, not the web.

Gotcha.

Lets stop bending over backwards for the fruity company, eh? If you want
modern and advanced features, stop buying phones with software supplied by a
company hellbent on removing choice.

~~~
jerluc
I'm not sure if any of this is sarcastic, so sorry if I've completely missed
the mark. But I think despite the opinion that one should have more choice (of
which, don't get me wrong, I'm personally an advocate) the problem here goes
well beyond the age-old Android vs. iOS debate. Sure, I wish iOS could have
implemented features that align with Android and vice versa. But IMO the
problem here actually comes from how the "web of apps" evolved separately from
the WWW.

On a more concrete note, there are scenarios where neither DNS nor special
HTML metadata work. A great example of this is Uber or Lyft. Both of these
apps support mobile deeplinking, however there is no real concept of a "page"
in these apps. These kinds of apps are more like utilities or services (ride
sharing, making phone calls, starting a run, etc), rather than content to
consume (reading the news, playing music, watching a video, etc).

------
Zikes
Android's Intents system already does this without any DNS fiddling, but half
the apps that need it most apparently ignore it.

------
denniskane
Better solution: Instead of the app delivery mechanism (the OS) being outside
of the web, put it INSIDE.

Proof of concept: [https://www.urdesk.net](https://www.urdesk.net)

------
gprasant
I think all thats needed is a shared settings storage between a website and an
app. (This is only between a domain and an appId. ie.. google.com should have
access to the space of Google search app. maps.google.com should have access
to Google Maps app)

For example, the cases that can arise are :

1) User does not have app installed.

2) User has app installed and prefers to use the app for the service
(Something like google maps). This preference can be stored in the shared
settings space.

3) User has the app installed, but prefers to use the browser for the service
(Like google search / wikipedia / yellow pages / amazon )

\-----X----

In 1) When clicking on a url like www.amazon.com/gp/product-id, The browser
cannot find an app that has access to shared settings. Hence, the only thing
that can be done is to open the url on the browser.

2) When clicking on a url, (like google maps directions), The browser reads
from the shared space and sees that this is a candidate for an app open. Now
it can open the app and pass in the url. The app can use this path to figure
out where to take the user to in the app.

3) When the user clicks on the url, and the settings say the user prefers to
use the browser for this kind of link, the browser can open up the URL.

------
0x0
The author dismisses the spoofing attack wrt TXT too quickly. SSL certificates
won't prevent spoofed TXT records giving the wrong bundle ID.

~~~
danielrhodes
Usually TXT is used to prevent spoofing (SPF etc.). If you can't rely on DNS
to be giving you non-spoofed information, going to the wrong app is the least
of your worries at that point.

~~~
0x0
Well, you can't rely on that. In fact, DNS is one of the most trivial
protocols to spoof since it mostly runs on UDP.

~~~
noir-york
In theory, and on a lan, yes, UDP is trivial to spoof.

However spoofing UDP packet source IP address is very hard on the open
internet due to egress filtering.

------
lazerwalker
Is solving this problem at the DNS level really necessary?

Apple already has tech in place to both associate a native app with a domain
name (so you can share login keychain items between a native app and its
corresponding site in Safari), and to associate a specific HTML page with a
native app + optional deep-link URL (see: the 'open in <X app>' banner in
Safari).

The fact that Apple hasn't connected the dots to provide a better experience
is bizarre, but seems to be one constrained by product decisions rather than
pure technical limitations. Mucking around with DNS adds in a lot of
complexity for few apparent gains.

(To say nothing of the major problem this doesn't seem to be trying to solve,
which is iOS not having a system like Android's Intents to manage routing a
single desired action to multiple apps that could all potentially handle it)

------
andrewmutz
I'm surprised we would want HTTP URLs for this. Especially since, as this
article is written, no HTTP requests are ever being made.

Why not have an ios:// (or android://) prefixed URL, and have whatever follows
that determine the app? If you passed along the rest of the path, you could
specify logical resources to link to.

~~~
profmonocle
Already possible on Android (and I believe iOS), but rather an application can
register its own URL scheme. (For instance, Twitter can set up twitter://)

The problem there is you can't have a single URL that just goes to the web
page if there's no app installed. That's what the author is trying to solve.

Android has a solution where an app can handle all links to a certain domain.
(The OS asks you if you want to use the browser or the app, and you can set it
to always use the app if you like.)

~~~
andrewmutz
Ok, now I see the problem the author is trying to solve. Thanks for clearing
that up.

I think from an HTTP perspective, the right way to solve this is to use vendor
specific content types and have the OS resolve whether to open it in an app or
not.

So when a link is clicked on in a browser, you use the request's Accept header
to indicate which apps are installed on the device (and have registered a
custom content-type). The server then can respond with a custom content type
and let the OS dispatch the response to the appropriate app.

For app to app links, the OS could just perform an HTTP HEAD to see which app
to dispatch to.

~~~
jerluc
This can be somewhat emulated with Android's support for vendor-specific MIME
types in intent-filters:
[http://developer.android.com/guide/topics/manifest/data-
elem...](http://developer.android.com/guide/topics/manifest/data-
element.html#mime)

Last I recall, this is how YouTube works to open the app when you try to play
it from the web player on a mobile device.

------
MichaelCrawford
If you're going to be monkeying with DNS, then you should take it to the IETF.

A problem we all have right now is that of authenticating to wifi. Many wifi
spots use ad-hoc solutions that work poorly on many systems. I feel there is a
legitimate reason for a wifi spot to direct me to its homepage when I
associate with it, but the way that's done is not in the RFCs, so may wifi
spots don't work for my devices.

~~~
AnthonyMouse
What those WiFi devices are doing is literally a man in the middle attack.
Anything that prevents the attack is going to break it, because it's doing
something it isn't supposed to.

What are you describing as the "legitimate reason" for WiFi devices to do
this?

~~~
MichaelCrawford
If a business is providing wifi to its customers, I regard it as reasonable
that the service be paid for by showing ads to the customers, also it's
reasonable that the users be expected to agree to an acceptable use policy.

That this is presently implemented as a man in the middle attack is a failing
of the 802.11x protocols. the 802.11x standardization committees should have
agreed on a documented, standard way for access points to do what so many had
to bolt on as an afterthought anyway.

~~~
AnthonyMouse
Most would regard inserting ads into third party websites as an attack.
Moreover, there is no obvious reason why the acceptable use policy has to be
delivered via MITM attack rather than e.g. posting it on the wall. It's not
like you can expect anybody to read it anyway.

