This article is based on reporting originally published at analyticsindiamag.com (May 2020) and covers the open-source debate around COVID-19 contact tracing applications.
The Privacy Problem with Contact Tracing Apps
During the COVID-19 pandemic, governments worldwide rushed to deploy contact tracing applications to slow the spread of the virus. While the public health intent was clear, the rapid rollout raised serious questions among privacy advocates, security researchers, and ordinary citizens: who has access to the data these apps collect, how is it stored, and what prevents misuse?
These concerns were not hypothetical. Personal data collection at national scale — including location proximity data derived from Bluetooth signals — is inherently sensitive. If citizens distrust an app, adoption rates fall, and the epidemiological value of the tool collapses. Low adoption is arguably the single biggest technical failure mode for contact tracing software.
One proposal that gained traction across multiple governments was simple: make the source code publicly available. Open-sourcing a contact tracing app does not solve every privacy problem, but it shifts the trust model from “trust us” to “verify for yourself.”
Singapore’s TraceTogether and the BlueTrace Protocol
Singapore was among the first countries to release both a contact tracing application and its underlying protocol as open source. The TraceTogether app uses Bluetooth to log proximity events between devices. Crucially, the Singaporean government published the BlueTrace protocol — the technical specification governing how devices exchange identifiers — along with a reference implementation called OpenTrace.
TraceTogether is available on GitHub under the GPL-3.0 licence, meaning anyone can read, audit, fork, and contribute to the code. Publishing the protocol separately from the app is a meaningful distinction: it allows other countries and developers to implement compatible systems without depending on Singapore’s specific codebase.
The BlueTrace/OpenTrace approach was subsequently evaluated or adopted by several other countries, including Australia and New Zealand, as they built their own contact tracing applications. This cross-border reuse demonstrates one of the practical advantages of open-source licensing in a global health crisis: shared infrastructure, shared auditing, and faster iteration.
Centralized vs. Decentralized Architectures
A key technical decision in any contact tracing app is whether contact matching happens on a central server or on the user’s own device.
- Centralized model: Devices upload proximity logs to a government or health-authority server. Matching and notification are performed server-side. This gives authorities rich datasets but creates a high-value target for attackers and a large surface area for potential misuse.
- Decentralized model: Devices exchange ephemeral, rotating identifiers. Matching is performed locally on each device. Servers only distribute anonymized keys of confirmed positive cases. This significantly limits what any central party can learn about individual movement patterns.
Singapore initially launched TraceTogether with a centralized design and later moved toward a more decentralized approach in response to public feedback — a process that was made more transparent precisely because the code was open source. The Apple/Google Exposure Notification API, released in May 2020, formalised the decentralized approach at the operating-system level.
The Case of Aarogya Setu
India’s contact tracing application, Aarogya Setu, also uses Bluetooth (and GPS) for proximity detection. At the time of the original reporting in May 2020, the app had been installed by tens of millions of users, making it one of the largest contact tracing deployments in the world.
Aarogya Setu was not initially open source, which drew criticism from privacy researchers. A notable incident involved security researcher Elliot Alderson (Baptiste Robert), who publicly claimed on Twitter to have identified a privacy vulnerability in the app, stating that data belonging to a large number of users was potentially at risk. The development team acknowledged the report and engaged with the researcher — but the episode underlined how closed-source code makes independent verification impossible until someone is motivated enough to reverse-engineer the app anyway.
Officials from NITI Aayog indicated at the time that the government was considering open-sourcing Aarogya Setu. The argument made by advocates was straightforward: if thousands of developers and security researchers can read the code, vulnerabilities are more likely to be found and fixed before they are exploited, rather than after.
Concrete Benefits of Open-Sourcing Contact Tracing Software
1. Independent Security Auditing
Open source enables security researchers, academic institutions, and bug bounty hunters to audit code without needing special access. Vulnerabilities discovered through community review are reported through responsible disclosure channels and patched — often faster than internal teams alone would manage. This is not a theoretical benefit; it is the established model behind the security of major open-source infrastructure projects.
2. Transparency Builds Public Trust
A citizen who can read the source code — or rely on a trusted security researcher who has — is far more likely to install an app voluntarily. Mandatory installation with no ability to verify claims is a recipe for non-compliance and, ultimately, failed public health outcomes.
3. Prevention of Backdoors and Scope Creep
Open-source licensing makes it structurally difficult to embed hidden data collection mechanisms. Any feature that goes beyond the stated purpose of the app is visible in the code and would be flagged immediately by the community. This is a meaningful check on government overreach, even when that overreach might be unintentional.
4. Accelerated Innovation and Standards Development
Open protocols — like BlueTrace — allow the broader developer community to propose improvements, optimizations, and extensions. Multiple implementations of a shared standard create a competitive environment that tends to produce better software faster than a single closed team working in isolation. Open standards also make interoperability between national apps more feasible, which matters as travel resumes across borders.
5. Platform Tooling Supports Open-Source Security Workflows
Platforms like GitHub provide built-in tooling for tracking security advisories, automating dependency vulnerability scanning, and managing patch releases. Hosting contact tracing code on such platforms means the project inherits this tooling at no extra cost, and the public can follow the security fix history in real time — a level of accountability that closed-source projects simply cannot offer.
Limitations and Considerations
Open-sourcing an app is not a silver bullet. Several important caveats apply:
- Open source ≠ open data: Publishing code does not automatically make the data the app collects publicly accessible or auditable. Data governance policies, data retention limits, and access controls must be defined and enforced independently.
- Server-side code matters too: If back-end infrastructure remains closed, a decentralized client-side app can still connect to opaque servers. Full transparency requires open-sourcing both client and server components.
- Code can be audited; deployments are harder to verify: There is no guarantee that what runs in production exactly matches the published source. Code signing, reproducible builds, and independent binary auditing are additional steps that close this gap.
- Community review requires active community engagement: Simply publishing code is not enough. Projects need clear contribution guidelines, triage processes for reported issues, and funded maintainers to act on what the community finds.
Key Takeaways
The debate over open-sourcing contact tracing apps is ultimately a debate about the relationship between government, technology, and citizen trust. From a purely technical standpoint, open-source development offers measurable improvements in security review depth, vulnerability disclosure speed, and interoperability — all of which are directly relevant to public health software deployed at national scale.
Singapore’s TraceTogether and the BlueTrace protocol provided an early template. The key lessons for any government or development team building contact tracing — or any sensitive public-sector — software are:
- Default to a decentralized architecture where technically feasible.
- Publish both the protocol specification and the reference implementation.
- Choose an appropriate open-source licence (GPL, Apache, MIT) and apply it from day one — retrofitting is harder.
- Establish a formal vulnerability disclosure and bug bounty program alongside the open-source release.
- Treat the open-source release as an ongoing commitment, not a one-time publication.
Open source does not make privacy problems disappear, but it makes them visible — and visibility is the prerequisite for any meaningful fix.