A recent video from UX thought leader Luke Wroblewski gave some great tips on how to make app permissions – and asking for them – a much more successful process. Watch below:
Asking for permission on what apps are allowed to access can be somewhat of a touchy procedure, especially as users are becoming increasingly more aware of privacy concerns. Luke points out that developers should keep in mind that people want to be in complete control over what their software will do on their behalf – and since there are multiple permission settings/opportunities over a wide variety of form factors, that’s a lot of responsibility on the shoulders of the developer to make sure the process is straightforward.
Privacy in regards to apps, especially when apps ask for information in order to function, is also starting to become a common issue, especially with the glut of apps out there, the amount of apps that consumers download on their devices, and the lack of oversight for app privacy. Most people actually do expect quite a bit of privacy out of their apps, even though for the most part, that privacy is perceived. According to a recent study:
“46 percent, for example, believe that carriers should not store location information for any length of time at all, while 59 percent believe data on a phone is "about as private" as data on a personal computer — which isn't necessarily the case depending on how a phone is loaded up.”
Even though most people realize that many apps and social networking services do gather information , like location, names, username, and other data, users still value their privacy very highly and want control over how that data is collected, used, or shared. In order to make privacy a reality and not just an “anomaly”, apps need to have reasonable disclosure of information that the apps plan on collecting, with a clearly written menu that helps them to make thoughtful choices about what information they want to share. While information gathering is the standard, it doesn’t have to be overly intrusive; users should be respected by the developers behind the apps, with safety measures in place that protect sensitive data.
Usually the app permissions process goes something like this: app is activated, it asks for access to location (yes or no), if someone says yes, the app is on to the next thing, but if someone says no? Then there’s a (potential) problem. If permission is refused at a system level, it’s difficutlt to get that back, so it’s important to really think trhough how permission is asked for.
Asking right up front – i.e, when an app first starts up – does not have a strong return rate. In fact, Luke states that 40% of people at most will give a “yes” for permissions. That’s a whopping 60% that choose to opt out, and as previously mentioned, getting these permissions added in later can be tricky. Instead of just merely asking for permission without giving a good reason, it’s important to actually let people know what they are going to receive for that permission.
For example, you might open a photo journaling application that you intend to use to keep track of your European vacation. In order to do that, the app is going to need to capture your location. If you tap “grant location” when the location dialogue pops up – offering you a practical reason why it needs your information – the approval rate goes through the roof; 95% acceptance for this kind of dialogue is the norm. Location permissions such as these let people know why they are being asked and they thus understand the benefits, so they are much more likely to accept than in other applications that don’t offer this. Simply being intuitive (gauging when the user is most likely to actually need to grant permissions in order for the app to function correctly), transparent (being completely upfront with why the permission is needed), and dangling a carrot (giving the clear benefit to the user of what granting permissions really will mean) seems to be the best way to navigate the app permission process.
For a higher level view of how developers can work to guard user’s privacy, the Electronic Frontier Foundation (EFF) has released a very thoughtful “Mobile User Privacy Bill of Rights” that includes these concrete, practical recommendations that developers can take into account to guard user privacy:
· Anonymizing and obfuscation: Wherever possible, information should be hashed, obfuscated, or otherwise anonymized. A "find friends" feature, for example, could match email addresses even if it only uploaded hashes of the address book.
· Secure data transit: TLS connections should be the default for transferring any personally identifiable information, and must be the default for sensitive information.
· Secure data storage: Developers should only retain the information only for the duration necessary to provide their service, and the information they store should be properly encrypted.
· Internal security: Companies should provide security not just against external attackers, but against the threat of employees abusing their power to view sensitive information.
· Penetration testing: Remember Schneier's Law: "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break." Security systems should be independently tested and verified before they are compromised.
· Do Not Track: One way for users to effectively indicate their privacy preferences is through a Do Not Track (DNT) setting at the operating system (OS) level.
How concerned are you about privacy – both for yourself and for your users? How are you providing privacy boundaries in the apps you are building? What about permissions – how do you handle those? Share with us in the comments below.
For more in this 2 in 1 series from Luke Wroblewski, check out the following links:
- Multiple input types and the 2 in 1 form factor
- 2 in 1 and Wide Screens: Orientations
- Virtual Keyboards and 2 in 1's
- Intel Developer Zone - User Experience