How to handle user data on the Android platform
With the increasing use of mobile applications, people are paying more and more attention to how these applications use their data. Despite the fact that the Android platform uses different permissions designed to protect users, application developers are responsible for how they use user data. It is important that the developers understand what code they are connecting to, and carefully consider the requested permissions, since in case of misuse you can lose the trust of users.
Building a robust and trusted ecosystem is a priority for each developer on the Android platform.
Let's look at a few points for writing an application that will be trusted:
1. Use privacy agreement
2. Minimize the number of required permissions.
3. Give your users a choice when collecting information
4. Do not collect unnecessary information.
5. Do not send any user information from the device.
6. ... however, if it is really necessary, use encryption and minimize the amount of information transmitted.
7. Do not use code that you do not understand.
8. Do not keep device logs or user specific information.
Use privacy agreement
A trusted application is open about what data it collects and why. Users generally agree to share information with such applications if they get some benefit from it. A simple and clear confidentiality agreement, specifying what data is collected and how it is used, will ultimately lead to establishing trust in the application.
Minimize the number of required permissions
Android is unique among mobile platforms in that it provides a simple and clear permissions model. All applications for the Android platform are required to declare the permissions that they need to work, and the user must agree to grant these permissions before installing applications. Users tend not to trust those applications that request excessive permissions.
')
Give your users a choice when collecting information
This is called a privacy paradox [PDF, 890K]. Users often share information with pleasure, but they want to control this process. A trusted application gives users control over their data. For example, Android Browser has privacy options that allow users to determine what information they would like to share.
Do not collect unnecessary information.
A trusted application limits the categories of information it collects. Collecting unnecessary information, especially if you never use it, raises suspicions. When in doubt, do not collect it.
Do not send any user information from the device
If you need user information, try to make sure that it stays within the device. Users will feel safe knowing that their private information will not leave the phone. Sending data from the phone, even if it is done for the benefit of the user, leads to suspicion.
... however, if it is really necessary, use encryption and minimize the amount of information transmitted.
Sometimes access to user data is a must. In this case, applications must be sure that it is safe. The confidentiality agreement will allow users to avoid unnecessary surprises; in some cases, it may be advisable to directly ask users before transferring data from the device.
First of all, minimize the information you collect. Do you really need a full phone number, or will the territorial prefix be enough? Can you use one-way hashing of information before it leaves the device in order to protect user data?
Example: Favorites
Suppose your application wants to create a “favorites” list for each of your users, without having to go through the full registration process. Theoretically, you could do this by sending a specific combination of their phone number, device identifier or SIM card identifier to the server. But why bother people with doubts about confidentiality? Why not send the hash code of any information from the presented options? Or even better, create a random identifier and save it on your phone, and use this unique key when registering for your application.
Secondly, encryption is critical for secure data processing. Phones are often used in unverified networks, where attackers can intercept a confidential transmission. Data encryption is critical to protecting user information.
The latter, when communicating with the server via HTTP, it is better not to pass user information in the URL that is used in the HTTP GET request. It is better to use POST to send them in the message body. Using POST does not guarantee that your information will not be intercepted, but placing it in the URL increases this probability. In addition, by default, most web servers log all received URLs.
Do not use code that you do not understand.
Since Android is an open operating system, quite popular (and good) practice has become to rely on third-party code in the form of libraries and environments. However, if this code does not work correctly with user data, then this becomes your problem. It is better to check the code before using it.
Do not keep device logs or user specific information.
Application developers should be careful with logs created in devices. Android easily allows you to write to the phone log, and anyone who has seen the result of running “logcat” knows that it is filled with important, but largely random, debug information from a variety of applications. In Android, logs are shared resources, and are available for applications with READ_LOGS resolution (with the user's permission, of course!). Even if the information in the log is temporary and is destroyed upon reboot, inappropriate logging of information can lead to leakage to other applications.
Building a robust and trusted ecosystem is a priority for each developer on the Android platform.
Let's look at a few points for writing an application that will be trusted:
1. Use privacy agreement
2. Minimize the number of required permissions.
3. Give your users a choice when collecting information
4. Do not collect unnecessary information.
5. Do not send any user information from the device.
6. ... however, if it is really necessary, use encryption and minimize the amount of information transmitted.
7. Do not use code that you do not understand.
8. Do not keep device logs or user specific information.
Use privacy agreement
A trusted application is open about what data it collects and why. Users generally agree to share information with such applications if they get some benefit from it. A simple and clear confidentiality agreement, specifying what data is collected and how it is used, will ultimately lead to establishing trust in the application.
Minimize the number of required permissions
Android is unique among mobile platforms in that it provides a simple and clear permissions model. All applications for the Android platform are required to declare the permissions that they need to work, and the user must agree to grant these permissions before installing applications. Users tend not to trust those applications that request excessive permissions.
')
Give your users a choice when collecting information
This is called a privacy paradox [PDF, 890K]. Users often share information with pleasure, but they want to control this process. A trusted application gives users control over their data. For example, Android Browser has privacy options that allow users to determine what information they would like to share.
Do not collect unnecessary information.
A trusted application limits the categories of information it collects. Collecting unnecessary information, especially if you never use it, raises suspicions. When in doubt, do not collect it.
Do not send any user information from the device
If you need user information, try to make sure that it stays within the device. Users will feel safe knowing that their private information will not leave the phone. Sending data from the phone, even if it is done for the benefit of the user, leads to suspicion.
... however, if it is really necessary, use encryption and minimize the amount of information transmitted.
Sometimes access to user data is a must. In this case, applications must be sure that it is safe. The confidentiality agreement will allow users to avoid unnecessary surprises; in some cases, it may be advisable to directly ask users before transferring data from the device.
First of all, minimize the information you collect. Do you really need a full phone number, or will the territorial prefix be enough? Can you use one-way hashing of information before it leaves the device in order to protect user data?
Example: Favorites
Suppose your application wants to create a “favorites” list for each of your users, without having to go through the full registration process. Theoretically, you could do this by sending a specific combination of their phone number, device identifier or SIM card identifier to the server. But why bother people with doubts about confidentiality? Why not send the hash code of any information from the presented options? Or even better, create a random identifier and save it on your phone, and use this unique key when registering for your application.
Secondly, encryption is critical for secure data processing. Phones are often used in unverified networks, where attackers can intercept a confidential transmission. Data encryption is critical to protecting user information.
The latter, when communicating with the server via HTTP, it is better not to pass user information in the URL that is used in the HTTP GET request. It is better to use POST to send them in the message body. Using POST does not guarantee that your information will not be intercepted, but placing it in the URL increases this probability. In addition, by default, most web servers log all received URLs.
Do not use code that you do not understand.
Since Android is an open operating system, quite popular (and good) practice has become to rely on third-party code in the form of libraries and environments. However, if this code does not work correctly with user data, then this becomes your problem. It is better to check the code before using it.
Do not keep device logs or user specific information.
Application developers should be careful with logs created in devices. Android easily allows you to write to the phone log, and anyone who has seen the result of running “logcat” knows that it is filled with important, but largely random, debug information from a variety of applications. In Android, logs are shared resources, and are available for applications with READ_LOGS resolution (with the user's permission, of course!). Even if the information in the log is temporary and is destroyed upon reboot, inappropriate logging of information can lead to leakage to other applications.
Source: https://habr.com/ru/post/101097/
All Articles