Data Privacy Conference

This submission is a summary of the Birds of Feather (BOF) session held on 28 April, 2021 with Chirayu Desai (CalyxOS), Madhusudhan Sambojhu (Able.do) and Apurva Jaiswal (Zeta) on security practices that individual developers and teams can undertake to ensure better data privacy.

The following were some of the key issues discussed, along with possible solutions:

1. Major data security challenges: For data at rest, tooling is available for iOS and Android platforms that developers can use often, but they don’t. SQL Cipher and Log Management is another area that is often overlooked.
   For data in motion, developers must use HTTPS to communicate over their network (to prevent non-secure transfer of data), be aware of MITM attacks, and refresh persistent tokens constantly. TLS and encrypted channels are recommended as safeguards.
2. Importance of processes and training: Code peer reviews and automatically triggering static security testing when your builds are getting created can help in securing your application. Regular security testing by an internal security team, or regular application audits by a third-party vendor can help add an additional layer of security.
   Some practices like:

• Never put secrets in your application code.
• Always make sure that secrets are stored only on the servers should be followed.
• Android engineering teams can be staffed with either more engineers or skilled developers because of the fragmentation issue.

3. Use of vault storage for managing sensitive data: Data at rest can be classified into sensitive data and non-sensitive data. Do not put all of the data in the vault storage because you may want to give some of the data upfront to the user. But all sensitive data, including your private keys, tokens and secrets, must be stored in the private vault storages. Other non-sensitive data such as some configurations, profile information, and probably some metadata can be stored in secure preferences. It is highly recommended that vault storage be accessible only when the user gives the app consent to access it. The developer can use SDKs to ensure that the basic tenets of security are maintained.
4. Security in Operating Systems (OSes): Mobile devices and mobile operating systems are sandboxed from day one. Application data can only be accessed by the application itself as long as you keep it in internal storage. Even if you don’t use any encryption measures, your data will still be encrypted at rest because these devices are always encrypted by default. The moment you turn off the device, that data is completely encrypted. And when you reboot the device, until you enter the PIN, the data stays encrypted and cannot be accessed by anybody who has access to the device.
   One advantage probably with iOS is the closed system where it is really difficult to root the device.
   Above are some of the challenges with Operating Systems. You can get over them by using tooling that is available and by making the software development system more robust by adding reproducible builds.

Common mistakes that developers and teams make: Small companies may not conduct external audits frequently, owing to lack of resources and/or bandwidth. This leads to data leaks, especially when logs are used. Developers and teams should try to use existing tools that suit their needs and test apps regularly to maintain security. They should also ensure that security standards are maintained across teams with updates, new apps, and new members. Development systems also need to be made more robust.

*This summary is written by Anwesha Sen. Reviewed by Chirayu Desai and Madhusudhan Sambojhu.