Custom Schemes and the Evil Twin Problem

If you’ve been following along on my blog posts or interacting with me on Twitter, you’ll know that I’m fascinated by the idea of building a web of apps on every device. This is especially true on app centric mobile and tablet devices. But the idea also applies to browser-centric desktops because, sometimes, an app is the way to go.

The very first, and possibly the defining characteristic of the web is it’s interconnectedness. The ability for a web site to link to another one seamlessly. The irony is that an app can just as easily link to a web site hundreds (possibly thousands) of miles away. But when it comes to linking to other apps on the SAME device, well, that just happens a lot less often.

Fortunately, custom schemes or custom protocols are a great way for apps to connect to each other on-device. In fact, there’s sizable industry momentum building around the idea of using custom schemes to deep link between apps. There are at least three initiatives that I’m very interested in and have been following closely in this area:

All three have interesting facets of their own but the idea is simple: take an http link (such as http://spotify.com/artist/Beyonce) and provide a way to transform it into a custom scheme link (Spotify://artist/Beyonce).

Custom schemes aren’t new. They’ve been around since at least 1996 when the Internet Explorer team (yes, that Internet Explorer!) first debuted them at Microsoft’s Professional Developer Conference. Other notables at that conference? A keynote by Douglas Adams, a session by Steve Jobs and our very own Andrew Clinick (@andrewclinick) as an attendee. Andrew also happens to be my source for this info! Basically, the idea is that an app signs up for a custom scheme and then other apps can launch it with a URI that uses the custom scheme. The wonderful thing is that custom schemes works on Windows, Android and iOS. Of course the APIs are different on every platform. If you’re interested in how custom schemes work on iOS, start here. Here’s how they work on Android. A detailed walkthrough that shows how to handle custom schemes in a Windows app lives here.

Okay, that’s great. You defined a custom scheme that can be used to deep link into your app. You’ve also decorated your http pages with the right metadata so other apps can find your custom scheme. Pretty soon, you’ll discover a problem that is unique to custom schemes. There is no authoritative way to take ownership of a custom scheme! Say you went with myawesomeapp: and you’ve got apps in the Android, Windows and iOS stores. That does not prevent someone else from coming along and using the same scheme. Unlike the World Wide Web, there is no central authority that polices and mandates that these schemes be unique. You can use strategies like reverse domain naming which is recommended by the Internet Engineering Task Force. But that still doesn’t prevent a malicious app from engaging in this behavior.

So, what ends up happening is that an app attempts to deep link into your app and the user might end up in a place neither you nor the calling app expected. I call this the Evil Twin problem. How do you prevent your friends directing a user to your evil twin instead of you on Windows? Well I’m glad you asked!

First things first, here’s how an app deep links into another app on Windows:

Launcher.LaunchUriAsync(new Uri(“com.aruntalkstech.tumbleme:?Oh=Yes”))

Now that’s C# code up there but the C++ and JavaScript equivalents aren’t that different. Notice that the app I’m trying to deep link into uses the reverse domain naming convention for their custom scheme. That’s good practice! But how do I prevent my user from going to another app installed on the same device and signing up for the same custom scheme. Well, that’s where the new TargetApplicationPackageFamilyName property we’re adding for Windows 10 comes in. We change the code to:

var options = new LauncherOptions();
options.TargetApplicationPackageFamilyName = “24919ArunjeetSingh.Build2014PhotoBlog_5gh9hndrtk5nw”;
await Launcher.LaunchUriAsync(new Uri(“com.aruntalkstech.tumbleme:?Oh=Yes”), options);

We add LauncherOptions when calling the LaunchUriAsync API. The new launcher option we are using is called TargetApplicationPackageFamilyName. A Package Family Name is simply an identifier that uniquely identifies a Windows app. The assumption here is that at some point, the owner of the app we want to deep link into (the app that signed up for com.aruntalkstech.tumbleme://) gave us their package family name. Now it is important to note that every Modern windows app has a package family name. The simplest way to obtain the package family name for your app is to call the Windows.ApplicationModel.Package.Current.Id.FamilyName API within the app. This works for Silverlight 8.1 apps, Windows Phone 8.1 apps, Windows 8.x apps and of course Windows 10 apps.

Where does the Package Family Name come from? Lets analyze the one above: 24919ArunjeetSingh.Build2014PhotoBlog_5gh9hndrtk5nw. The part before the underscore is a generated name the Windows developer center gave me when I reserved a name for my app. So this part is unique to my app within the Windows store. It is also what is known as the Package Identity Name. The second part is a hash of the certificate used to sign my app. Remember, your users will either obtain your app from the Windows store or by way of an enterprise deployment. Either way, it will be signed using a certificate issued to you for app signing. So unless you manage to compromise that certificate, you can be sure that another app can’t steal your package family name.

PackageIdentityName
Getting the Package Identity Name

Well there you have it! A detailed (too detailed?) discussion of the Evil Twin problem and the way we’re hoping to solve it with Windows 10. If you have feedback or questions, please leave a comment or tweet me @aruntalkstech. The code above came from https://github.com/arunjeetsingh/ContractsAndPickers. This repository has the app we’re trying to deep link into as well as the Launcher code shown above. Finally, the app we’re trying to launch has already been published to the Windows Phone store and lives here: http://www.windowsphone.com/en-us/store/app/build-2014-photo-blog/7a5612c4-1a7f-4e7e-806a-06f0970d854a. Happy hacking! 🙂

Advertisements

Build 2015: ShoppingDemo

I wanted to really quickly make a note that the first commit of my Build 2015 demo is now up on https://github.com/arunjeetsingh/Build2015. If you’ve been following me on Twitter (@aruntalkstech) you might know that I plan to build my Build demo in my GitHub repository. The code in there should build with the latest Windows 10 preview tools but not all of it runs flawlessly on 10041 or 10049. So while you can play around with it be wary of not implemented exceptions and other places you’ll fall off a cliff because we’re not done yet. Still, great way to explore what’s coming.

Here’s a quick back of the envelope map of the world showing what’s interesting in there:

I’ll have more details as we continue to build out this demo. Feedback/Comments are very welcome. Leave them here or tweet them @aruntalkstech. Happy hacking! 🙂

Building a Web of Apps on Windows 10

If you haven’t heard the news, well, let me be the first one to let you know. The tools for building apps for Windows 10 are here: http://dev.windows.com/en-US/windows-10-developer-preview-tools. Sure, it’s still Visual Studio and a Windows SDK but the BIG difference this time is that not only can you build for Windows and Windows Phone, you can also build for potentially any platform that runs Windows out there. That includes Xbox, Hololens, Raspberry Pi, the Surface Hub, tablets, laptops, desktops, phones. And those are just the ones I know about!

The ambition of the Windows 10 release and the scope of this SDK is hard to overstate. Over the past year, we’ve been busy building a set of tools to connect apps on Windows in my little corner of the world. You see, my team work on a bunch of APIs that apps can use to talk to each other. These APIs give apps the ability to share data with each other using the share contract, launch each other using custom URI schemes and file associations, share files with each other using the file picker APIs. We also work on humble but important APIs such as the clipboard APIs. Basically, any time an app needs to talk to one of the other apps on a device, we come into play.

With Windows 10, our challenge was to extend these APIs all of the devices Windows is now available on. Now, not all the APIs work exactly the same everywhere. There’s no sense in making the share picker on the phone fly out from the right and cover only part of a small screen for example. The clipboard on an Internet of Things (IoT) device such as the Raspberry Pi will have **some** differences compared to the one on a full-blown desktop machine. Nevertheless, we wanted to make the majority of these APIs universally available so that apps on all these devices could talk to each other.

Our vision of app to app APIs (app to app is what we call ourselves and we’re still looking for a nicer name :D) has always been one of a web of apps. There is no reason apps have to be islands. Now that does not mean app isolation isn’t important. It is VERY important. In fact, the lack of true app isolation on most desktop class operating systems frequently means that a user’s experience can be held hostage by one or a handful of rogue apps (virii, malware et al). However, that does not imply that every app must be an island unaware of other apps on the device. The user forever doomed to shuttling in and out of the start (or home) screen trying to accomplish the simplest tasks.

When apps talk to each other beautiful things happen. You install one app and it enriches your experience in other apps you might already have. We’ve all seen this happen, but it is still something of a dark art. Our goal is to make app to app communication easier, less of a dark art and make your device as useful as your browser. You should never, ever have to choose an app before you choose what to do. We’re not quite there yet, but I think you’ll agree it is a noble goal.

Thanks for reading this far. For the next few posts, I will be talking about enhancements and new app to app features we have built for Windows 10. Please use comments or my twitter handle @aruntalkstech to reach out. The code will always be at http://www.github.com/arunjeetsingh. Happy hacking!