Apps and sites can make different implementation choices when implementing a certain feature. While any of those choices can deliver the desired functionality, some of them may have dramatic consequences for privacy, possible oversight or potential for abuse. So it is important to pay attention.
For example, an app may make the choice of being open-source – which makes code review and innovation by third parties straightforward – or being closed-source – in which case users will have to trust the developer that they don’t do anything users wouldn’t approve behind their backs, as external code view is largely impossible.
Or, a contact tracing app may store all contacts on a server, together with all personal details of the people who met. This is terrible for privacy. Alternatively, a tracing app may only store randomized contact identifiers without any personal details; and still deliver warnings to people who may have been exposed to virus carriers.
Here is the list of choices we have encountered so far in our analysis.
- Availability of source code and licensing
- Is the source code available for review, reuse, or not at all.
- Type of the app's server-side backend
- Contact tracing
- Approach to implementing contact tracing
- Where does the app run
- User identification
- How users are identified in the system