These postings are provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.
Paul LabergeDeveloper Evangelist
Frédéric HarperDeveloper Evangelist
Securing your software product is one of the key, non-negotiable items you need to do before you release it and make it available to customers. Regardless of who you are, security should be top-of-mind when you build your Windows Phone apps as well. In this post, we’ll go over tips and tricks on how you can secure your Windows Phone app as well as touch on the various types of security you need to keep in mind when building your app.
Let’s call a spade a spade and say unequivocally that the world of technology is a vastly different and more dangerous place than it ever was even 10 years ago (or perhaps even one year ago…). The days where functionality of software being the primary focus are now gone, being replaced by a combination of functionality, experience, ubiquity, manageability and certainly not the least of which is security.
The world continues to change with new and stronger threats to be challenged every day. This includes our software creations. Clearly a black market economy has emerged around technology, specifically in getting data from software that may be valuable to unsavoury people looking to gain insights to the information that the software (or data stores used by the software) can provide.
There is an amazing book by James Gleick call The Information: A History, A Theory A Flood that talks about what information is, how it has evolved and explains in great detail what the value of information truly is. In it, Gleick makes a case for why information is important and how it has become a means for people to gain a competitive advantage.
When you look at software in its fundamental form (regardless of the channel – mobile, pc-based, web, service or otherwise), the only purpose it serves is to provide you, the user, with data that you can transform into information that you or your business can act upon based on the facts or probabilities it provides. The true value of your software is the information it holds.
Because the information your software product holds on your users’ behalf is valuable, you need to protect it. The viability and future of your software depends on your ability to build trust with the user and that includes making sure nothing that non-authorized users shouldn’t see gets leaked to them.
When I am talking to others about data security, I’m reminded of a great scene from the movie Heat (one of my all-time favourites, actually). The scene is near the beginning of the movie where Robert DeNiro’s character and Jon Voigt’s character meet with an unnamed man that knows when a certain bank is going to get an influx of bearer bonds in their vaults (which, of course, they decide to steal). At the end of the scene, DeNiro asks the man “How do you know this stuff?” to which the man answers (and I am paraphrasing) “It’s in the airwaves, all around us. You just have to know how to find it. I know how to find it.”.
That scene is actually really telling. You get a sense for how the human mind can find correlations across disparate, almost seemingly non-connected bits of data (in the case of the movie, the ability to get building blueprints from city, having information that a large shipment of bonds will be in the vault at a certain date and time, electrical schematics for disabling that specific bank’s alarms, etc.). Basically, your software is in a eternal battle against the vastness of intelligence and creativity of the human mind. Sounds daunting, right? Well, luckily for us as software developers, there are a number of tried and tested best practices that we can use to protect our software and they also work for Windows Phone. Some of these are listed below:
Since mobile devices figure out ways to get lost, if your app is expected to handle sensitive data (by sensitive, I mean private, confidential, etc.), make sure your data footprint on that device is minimal. A great example of this is the way banks in implement mobile banking apps in general on smartphones (and web browsers for that matter). Account numbers are never kept on the device – instead, mobile banking apps tend to use transient tokens (i.e.: non-permanent tokens that go stale after a certain amount of time) on the device that is paired specifically to that device and the user on the server side. In other words, full account data is not kept on the device and any data kept on the device goes stale quickly.
After figuring out what data would need to reside locally (however transiently) for your app to work, you must architect and plan for that data to be encrypted and isolated from other apps and system functions. Please remember, however, that if you are worried about security and privacy within your app and you have the option to store that data server-side, you should always do so.
In Windows Phone, make use of isolated storage for your local data. You can (and in the case of sensitive data, should) encrypt the data in isolated storage. Oh, and don’t “roll your own” encryption algorithms – you should use those provided by the .NET platform for Windows Phone if at all possible as they are tested and proven solid. That is, unless you love cryptomath, love creating salted hashes and get giddy at the though of getting home from work and scheming up new encryption methods to thwart hackers (if that rocks your boat, I strongly suggest you grab a copy of the applied cryptography bible written by Bruce Schneier – it’s a great book but not for the faint of heart).
(By the way, extra credit for those that can identify the typewriter-looking-thingy associated with this section!)
Challenge/Response is an old security pattern, but it is one that is very effective. Especially true in Line-of-Business app scenarios, but equally relevant in any case where you want users to prove their identity to the app, Challenge/Response is basically a request made by the app to authenticate themselves before they are let in the gate. Authentication is the process by which a user provides a user name and password (or something similar like biometric feedback or other methods) to basically act as a proxy to the app demonstrating the user is who he/she say she/he is. That’s all it is – permission to enter the property.
Authorization, on the other hand, is where the second line of defence resides and it is also the way apps with well-architected security really shine, in my opinion. Once you have authenticated, the app knows who you are. At that point, the app (and any server-side logic the app consumes) uses your credentials to determine what data you will have access to. For example, if your app was a fantasy football pool, a football league commissioner would likely have the ability to set new rules and send special, league-wide notifications to the members of the league, while as a regular league member using the same app would have access to only his/her fantasy football team. Authorization is the magic that makes this happen.
There are very few scenarios where you have a mobile app that has a requirement for security and encryption that doesn’t have a server-side or internet connectivity component. As such, make sure your mobile app does have a central management capability outside of the app itself (likely a web app for the server or something similar). If something goes wrong (especially if it affects more than one individual user), you are going to need a way to fix the issue quickly and through ways that won’t require you as a manager of the central data to have physical access to the app on the user’s device.
There are many more ways to secure your phone apps, to be sure, but these are some of the ones to start a discussion. Throughout the following weeks, stay tuned for further posts around data security in Windows Phone apps.
If you were born in the 70’s like I was, you may remember a show hosted by Leonard Nimoy called In Search Of… that explored unexplained phenomena and some of the theories behind it. Being young and impressionable, I soaked in the theories that this show presented about things supernatural and odd and I thought it was fascinating. As I got older, I realized that it was highly unlikely that many (if not all) of the theories the show presented had real merit, but it was good television (including the wicked 70’s fashion Leonard sported). In comical kind of way, you might feel that finding open source code targeting Windows might make for a great episode for a modern day In Search Of… You may feel that they are unnatural together and finding FOSS creations for Windows is an elusive challenge. Well, we have an answer for you that is a lot more solid than the often vapid theories the original show. There is a site that Microsoft (yes, Microsoft) created that is solely dedicated to allowing you as a developer to consume, create and host FOSS that benefits the entire developer community. That site is Codeplex.
If you’re familiar with Codeplex, you are probably already familiar with the value of the site. Some of the best open source software for Windows can be found here, including NuGet (if you don’t have and use it yet, you really need to check it out), JSON.net and even Windows Phone tools (which I’ll list later on in this post). Some are actually created and provided by Microsoft itself and some are provided by the open source community. All in all, it’s a great repository that you as a developer, whether you are targeting Windows Phone, Windows Azure, Windows 7 or even other platforms that work with Windows.
As I referenced above, there is a lot of goodness that Codeplex provides for you if you are targeting the Windows Phone platform. If you are building apps for Windows Phone, there are some projects on Codeplex that are nice to have access to as they make your life easier as a developer, but there are actually some tools on Codeplex that I consider absolutely essential to have in your belt before you even start building your app. Below are some of my favourites:
Now, of course there are a lot more projects available on Codeplex to support your Windows Phone application development and you may have your own favourites. If you have one you use a lot that isn’t listed, feel free to share on this post!
By now, most people have realized (in theory) that recreating a PC-based app (or web app) is not exactly the right idea for mobile apps. In practice, however, it is clear that this is not as easy as it sounds. When you’re building an app that has no history on the PC or web, building the app for mobile is a little easier as you can resist the temptation to add too much of the functionality from that original app to your mobile app. But even then, it’s not always easy to pare down the functionality of your app to a mobile screen. The original scope of your app when you wrote it down on a napkin in a bar while talking to friends was a great start, but like most other software projects, you find the urge to add more in with the expectation that more functionality means more useful. Cluttering your app with more controls is not the answer. This post will provide some guidance on how to thoughtfully build functionality for your app’s user interface so that it meets the right balance of complexity and usability.
Let’s face it. Aging paradigm or not, successful PC apps and web apps have the ability to make you very productive. Get in, do the work, get out fast (and maybe hang out a while to check out other parts of the app afterward). That’s the aspiration PC/Web app developers have for the users of their apps. A good example of this is Microsoft’s OneNote product (if you’ve never heard of it, it’s a relatively new addition to Microsoft Office and one of the best apps I’ve used for productivity – it’s singlehandedly replaced Word and Notepad for my free-form thought transfer and note-taking tasks). It’s awesome and has materially increased my productivity while using my laptop. It’s also a fairly “busy” tool with lots of bells and whistles in the control ribbon to help me get things done. I like to humourously call this traditional app design the PC and Web app “Mullet”.
On the top (or front), it’s all business, meaning all of the controls go at the top. The “party” as it were, is on the bottom (or back), which is another way of saying the valuable information (your content) goes there. It’s similar with browser-based apps, with the web controls going on the top and the content below it.
This design is actually a very effective one as it allows you to focus in on the content on the screen and use your mouse to modify the content through the ribbon at the top. But how does this translate to mobile apps? You may have noticed that the most user-friendly mobile apps don’t use this standard PC-based design for presenting information to the user. There’s a good reason for that.
Let’s use a very early iteration of the FourSquare app for Windows Phone as an example. This is what one of the screens looked like, and the issue that was found with it:
Do you see the challenge in using this screen? If you guessed that the Check-In button caused the screen to be obstructed when you used the app, you would be right!
By placing the check-in button for this app near the top of the screen, the user cannot see other valuable information that it provides, such as the location map and other functionality such as getting directions or calling the establishment the user was checking into.
You might provide the counter-argument that most users would likely use their thumbs to use the controls on the screen and you’d be right, but the general principle still holds; if you place critical components of your app near the top of the screen, you will obstruct the view of the rest of the screen from the user which is a usability no-no. In other words, controls that represent critical functionality of the screen should be placed near the bottom of the screen, not the top.
The FourSquare team noticed this usability challenge very quickly and iterated their Windows Phone app quickly as a result, which ended up in a much more usable screen for the user. The screenshots below show this change for the FourSquare app, as well as how OneNote for Windows Phone was designed with this principle in mind as well:
Notice the change here? This is the exact opposite of how traditional PC and web apps are designed. The content is front and center near closer to the top, and the controls are at the bottom. Ladies and gentlemen, I present to you the classic mobile app design that I like to call the “Reverse Application Mullet”.
It’s important to note how both examples to the allow the content of the app to take center stage. Any real functionality in this case is handled by the app bar at the bottom. Well save that lesson for the upcoming fourth instalment in this blog post series, so stay tuned for that.
It’s also important to note that if you compare the PC and mobile versions of OneNote, they are clearly very different in look and feel. They both allow the user to do the same thing but the implementation of each does look very different. Consistency in the look and feel of your mobile app and it’s PC-based app counterpart (if there is one) is not something you truly need to aspire to. Look at what the mobile version of your app is meant to accomplish and keep a furious focus on that functionality (I talked about that in my first post in this blog post series). When porting a PC app to a mobile app, scope creep is your mortal enemy.
The last thing I want to impart on you is the importance of grid-like placement of your controls in your mobile apps. Clean, consistent lines make for a more desirable user experience in mobile apps. When you have a large screen size (like PCs and web apps generally do), you can get away with less consistency in lining up controls as the size of the screen can hide imperfections. When you have a smartphone-sized screen, the story is completely different. Use a grid to place the controls on your screen. This will allow you to align controls and add consistency to the personality of your app.
You may hear designers for mobile apps talk about a concept of “magic numbers” for mobile app platforms. These numbers act as guidelines for you to design your mobile app screens with a consistency that aligns with the platform in general. For example, the Magic Number for Windows Phone (i.e.: Metro) is 12. The number 12 is indicative of the best offset (i.e.: spacing) in between controls. That is to say, when grouping controls together on the screen, don’t group them any closer than 12 pixels apart. With the offset of 12, Microsoft has built a handy version of this design grid that you can use to design your apps with the magic number of 12 in mind. Basically, the grid is a series of 25 pixel squares (12 squares wide and 20 squares long), each square offset by 12 pixels with a 24 pixel border around the edges. There are two great posts on the grid that I encourage you to read, the first by Jeff Wilcox found here (which provides a download to the grid and an example Windows Phone code project) and the second by Arturo Toledo found here (which provides a download to the raw grid files in various formats for your own use).
Below are some great examples how the Windows Phone team adheres to the grid principle in areas like the People hub and others:
You’ll notice how the various controls and screen assets adhere to the grid guidelines. This allows for a truly consistent experience across the OS and through your own app. And trust me on this, your users will notice if things are out of alignment. They may not necessarily be able to state outright what the issue is, but they will notice something is a little off in your app. It takes a little more time to build out your app’s screens, but in the end it is worth it.
This post is the second in a five-part series on creating awesome mobile UIs and creating your app with mobility-first in mind. The first post was on resisting the urge to recreate a PC or web app on the mobile form factor. The third post will be on the size of UI assets on the screen and why it is important. The fourth post will be on when to use an app bar vs. populating controls on your app’s screens. The fifth and final post will be on implementing gestures and animations to make them useful to the app.