Using DNS to solve the mobile deep linking problem | Hacker News Reader

Using DNS to solve the mobile deep linking problem

drhod.es

80 pointsdanielrhodes38 comments

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} 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...

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.

@apple and @google could start domain registrar service for the "AppWeb"

> 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.

> The problem is that any app could register to listen to those addresses

That's a feature, not a problem, and it's the kind of flexibility I expect from Android.

Take the domain reddit.com, for example. There are several Reddit apps, two or three of which are very popular. If the app to open was controlled by the owners of reddit.com, how would my favourite third-party app be able to register to handle those links?

Android already handles this. You get a popup box listing all of the apps that can handle a particular URL. You can choose whether to use that app just this time or to set it as default and not ask again. Defaults can be cleared in the system settings.

This really is a solved problem on Android.

You can do something similar with iOS as well - as far as handling parts of the url and query. One thing you can't do, unfortunately, is handle any url that starts with http - it has to be custom.

...which is the main motivator for all of these deep-linking services. Having one URL that gracefully degrades to the browser when the user does not have your app installed is not currently possible without annoying server-side hackery on iOS.

Right. The problem that has arisen is creating that mapping between those HTTP urls and the app URL, especially since only the app developer knows that URL and how it is interpreted inside the app, is almost non-existent. What has resulted is a shadow set of URLs which only work if the app is installed (which you can't tell from the web). All the great network effects you get from hyperlinks on the web don't get passed over to the mobile ecosystem because of these properties (hidden URL structure, inconsistent with the web, etc.).

When YouTube came pre-installed on iOS in the first few versions, when you clicked on an (HTTP) link to YouTube it would open the app. It was a great experience because the YouTube app had a nicer experience than the web. It would be great to be able to do this for more apps, if those apps wanted it.

Yup, Android will recognize YouTube links and open them in the app, same for play store links, and reddit links. I'm sure there are others that I haven't encountered yet. As far as I'm concerned, the author's issue has already been solved.

iOS does the same thing, at least for YouTube. It's why I keep uninstalling the app, as I hate the UI and most of the time I just want to stay in the browser.

> It's why I keep uninstalling the app, as I hate the UI and most of the time I just want to stay in the browser.

They don't let you choose which app you want to use? I know that's consistent with the half-assed way iOS (and honestly, Android) implements many things in the OS, but it's still pretty bizarre that they'd offer URL handling but no way to choose which app to use once or permanently.

You can unbind most of the intents, but I've not worked out a reliable way to stop youtube bouncing me to the app from the browser.

Android actually lets you choose the app to handle the link though, which is nice. I'm sure iOS will catch up in this regard at some point.

[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.

That doesn't sound like it'd be difficult to map to the DNS. Something like a record per mapping with each record containing a pattern and a template ought to work -- where does it get difficult?

Without pointing fingers at a specific app, there are several in particular that we have worked with who have "pretty URLs" for their website (e.g. "http://example.com/the-name-of-the-page") but their deeplinks are "ugly" (e.g. "example://page?id=123456"). There is no unified way here to derive the deeplink from the web URL or vice versa. As such, we cannot treat deeplinks and web URLs as always templatized; these are simply URIs whose identities should be considered arbitrary.

On another slightly relevant note, from the perspective of linked data and the semantic web, the <link> tag or "Link" header (both which are suggested by Google and URX) is meant precisely for this kind of reason: being able to link separate resources with a given relation (e.g. "alternate") who may have varying display/device/media qualities (e.g. media queries). Because semantic linkage is between two nodes of the web graph rather than DNS (which I guess would be a subgraph of the web?), one is able to use semantic metadata such as http://schema.org/docs/actions.html to describe not only how to access/consume a resource, but also alternate ways to do so (e.g. from an Android device instead of a desktop client).

Again the above isn't completely impossible to do with DNS, I'll give you that, but it simply is less tenable to assume template-like qualities of all URIs or to ignore the semantic implications of redefining how linked data has worked for the last decades.

> 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.

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).

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

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

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.

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

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.

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.

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.

On the contrary: you have to assume DNS is always compromised on the client (because it easily is). SPF records depend not on client DNS but on server DNS, so you have control over the lookups. That's a completely different ball-game.

Wide usage of DNSSEC is needed to trust DNS records. DNSSEC would also fully allow PGP keys to be stored in DNS...

See STEED...

http://g10code.com/docs/steed-usable-e2ee.pdf

But, yes! DNS is the correct and appropriate location for items like the OP posted... built-in widely used distributed 'trust'.

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)

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.

What happens as that ecosystem grows, though? There's Windows phones, Blackberry, and others. The solution would have to be either universal (like app://) or implemented by the OS/applications themselves (like Android Intents).

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.)

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.

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...

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.

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.

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?

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.

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.

Reply on news.ycombinator.com