Best Practices for Handling Andr
[By Nick Kralevich, an engineer on the Android Security Team]
As the use of mobile applications grows, people are paying more attention to how these applications use their data. While the Android platform contains extensive permissions designed to protect users, application developers are ultimately responsible for how they handle users’ information. It’s important for developers to understand the code they include, and consider the permissions they request, as mishandling these issues can result in users perceiving a violation of trust.
Maintaining a healthy and trustworthy ecosystem is in every Android developer’s best interest.
Here are a few tips for writing trustworthy Android applications:
- Maintain a privacy policy
- Minimize permissions
- Give your users a choice regarding data collection
- Don’t collect unnecessary information
- Don’t send data off the device
- ... but if you have to, use encryption and data minimization
- Don’t use code you don’t understand
- Don’t log device or user specific information.
** Maintain a privacy policy**
Trustworthy applications are up-front about the data they collect and the reasons for collecting it. Users are generally happy to share information via such apps if they believe they will personally benefit. A clear and concise privacy policy, with details about the type of information collected and how it’s used, goes a long way towards generating trust and goodwill. You can link users to your privacy policy right from your app's Google Play listing — visit the Developer Console to add the link.
** Minimize permissions**
Android is unique among mobile operating systems for its simple, straightforward, operating-system-enforced permission model. All Android applications must declare the permissions they require, and users must approve these permissions before the application is installed. Users tend to distrust applications that require excessive permissions.
For example, a user installing the tic-tac-toe game at left might reasonably wonder why it needs to take pictures.
** Give your users a choice regarding data collection**
It’s called the paradox of privacy [PDF, 890K]. Users are often happy to share their information, but they want control over that sharing. Trustworthy applications give users control over their information. For example, the Android Browser has privacy settings which enable users to control how their information is shared.
** Don’t collect unnecessary information**
Trustworthy applications limit the kinds of data they collect. Collecting unnecessary information, especially if you never use it, just invites suspicion. When in doubt, don’t collect it.
** Don’t send data off the device**
If you have to handle user data, ensure that the data remains on the device whenever possible. Users are comforted knowing that their private information strictly resides in the phone. Sending data outside the phone, even if done for the user’s benefit, tends to draw suspicion.
** ... but if you have to, use encryption and data minimization**
Sometimes, the collection of data is necessary. In that case, applications need to ensure that it is handled safely. A privacy policy will avoid leading to surprised and irritated users; in some cases, it may be advisable to prompt the user before transmitting data off-device.
First, minimize the amount of data you collect. Do you really need the user’s full phone number, or would the area code be sufficient? Can you use a one-way cryptographic hash function on the data before sending it to the server to help protect the user’s confidential information?
Second, encryption is critical to the safe handling of user data. Phones often operate on untrusted networks where attackers can sniff confidential traffic. Encrypting data in transit is a critical part of protecting user information.
Finally, when communicating with a server over HTTP, it’s a good idea to avoid encoding user information in a URL that is used with HTTP GET; rather, POST it in a message body. While using POST doesn’t guarantee that your information won’t be sniffed, putting it in the URL increases the likelihood that it will be automatically logged; out of the box, most web server software logs all the URLs that are received.
** A case study: User Favorites**
Suppose you want your app to maintain a list of “favorites” for each of your users, without going through a full registration process. In theory, you could do this by sending your server some combination of their phone number, device ID, or SIM ID. But why take the chance of worrying people about privacy issues; why not send a one-way hashed signature of whatever the identifying information is? Or even better, create a random unique id and store it on the phone, and use this unique id as the registration key for your application.
In the end, you’ll will still be able to retrieve their favorites, but you won’t need to send or store anything sensitive.
** Don’t use code you don’t understand**
In the open-source Android environment, it’s common (and good) practice to rely heavily on other people’s code, in the form of libraries and frameworks. But if that code is handling your users’ information inappropriately, it’s your problem. So make a point of checking code before you rely on it.
** Don’t log user or device specific information**
Application developers should be careful about on-device logs. Android makes it easy to write to the phone’s log, and anyone who has looked at “logcat” output knows that it is full of important but seemingly random debugging information from many applications. In Android, logs are a shared resource, and are available to an application with the READ_LOGS permission (only with user consent, of course!). Even though the phone log data is temporary and erased on reboot, inappropriate logging of user information could inadvertently leak user data to other applications.
原文地址
