Privacy-Driven Classification of Contact Tracing Platforms: Architecture and Adoption Insights

Abstract

Digital contact-tracing (CT) systems differ in how they process risk and expose data, and the centralized–decentralized dichotomy obscures these choices. We propose a modular six-model classification and evaluate 18 platforms across 12 countries (July 2020–April 2021) using a 24-indicator rubric spanning privacy, security, functionality, and governance. Methods include double-coding with Cohen’s $\mathsf{\kappa }$ for inter-rater agreement and a 1000-draw weight-sensitivity check; assumptions and adversaries are stated in a concise threat model. Results: No single model dominates; Bulletin Board and Custodian consistently form the top tier on privacy goals, while Fully Centralized eases verification/notification workflows. Timelines show rapid GAEN uptake and near-contemporaneous open-source releases, with one late outlier. Contributions: (i) A practical, generalizable classification that makes compute-locus and data addressability explicit; (ii) a transparent indicator rubric with an evidence index enabling traceable scoring; and (iii) empirically grounded guidance aligning deployments with goals G1–G3 (PII secrecy, notification authenticity, unlinkability). Limitations include reliance on public documentation and architecture-level (not mechanized) verification; future work targets formal proofs and expanded double-coding. The framework and findings generalize beyond COVID-19 to privacy-preserving digital-health workflows.

1. Introduction

Coronavirus disease 2019 (COVID-19) has strained public health frameworks in their efforts to contain the spread of infectious diseases. This strain is partly due to the novel nature of the virus and partly due to its peculiar characteristics of rapid transmission [1,2]. Virus outbreaks have led to lockdowns, quarantines, strict social distancing, and proximity tracing [3,4]. Contact tracing (CT) is a vital measure to minimize the spread, but workers must be hired, trained, and deployed to manually research and trace infected cases [5]. For instance, the United States started with a workforce of more than 37,000 contact tracers in place, with an additional 31,000 in reserve, and still fell short by 100,000 people [6]. Therefore, officials have sought to build and augment mobile contact-tracing tools [7]. Contact tracing approaches may gather Personally Identifiable Information (PII), making some users reluctant to use these solutions [8]. By contrast, privacy-preserving contact tracing motivates participation and increases the effectiveness of disease control [9,10,11].

As COVID-19 spread, smartphone-based solutions such as proximity tracing were proposed to break transmission chains [12]. Proximity records identify contacts that may require testing or self-isolation [13,14]. However, privacy concerns and vulnerabilities are attached to these tools, and we classified these issues into four categories. First, the privacy of personal devices, such as smartphones, is vulnerable to attacks such as theft or coercion, where a user may be forced or persuaded to reveal their PII [15,16]. Second, contact advertisement messages, such as aliases exchanged between devices, are likely to occur on cell phones and are present in all architectures. Third, users’ PII can be stolen and misused from healthcare servers, exposing sensitive social proximity data [16,17]. Both centralized and decentralized systems are vulnerable to (partial) visualization of proximity estimation [18]. Finally, through side-channel attacks, an adversary may detect that an alert has been generated or that a person has gone into quarantine, potentially preventing the exposed person from receiving critical notifications [19]. Thus, cyberattacks may lead to partially or fully deanonymized PIIs, depending on the architecture and the amount of information stored or transmitted via side channels.

Architectural design choices in digital contact-tracing (CT) systems shape privacy, security, and public adoption. The common centralized–decentralized split signals only one decision and misses finer differences in data flow, control, and exposure risk [20]. We therefore introduce a modular six-model framework that makes these differences explicit. To guide our investigation, we focus on the following research questions:

• How do architectural design choices in digital contact-tracing platforms shape privacy (e.g., PII exposure and unlinkability), security (e.g., verification/notification authenticity), and observed adoption and evolution over time?
• Does a modular six-model classification provide a more informative and actionable understanding of contact-tracing architectures than the traditional centralized–decentralized split, enabling consistent comparison across deployments and clearer guidance for design and policy?

Although the analysis focuses on COVID-19 deployments, the framework is scalable beyond COVID-19, offering a structured lens for privacy-preserving digital-health workflows (e.g., tuberculosis, influenza, future biosecurity responses). We examined 18 platforms using a 24-indicator rubric across privacy, security, functionality, and governance, interpreted under a concise threat model and aligned with CDC assessment criteria. Results include comparative model scores, inter-rater agreement, weight-sensitivity checks, and adoption timelines.

Contributions: This work (i) introduces a privacy-driven six-model classification along two orthogonal axes, locus of risk processing and data addressability; (ii) provides a transparent 24-indicator rubric across privacy, security, functionality, and governance, with an indicator → evidence catalog for auditability; (iii) establishes reproducibility through two-rater coding and Cohen’s $\mathsf{\kappa }$, and robustness via a 1000-draw weight-sensitivity analysis; (iv) maps architectural choices to security goals G1–G3 (PII secrecy, notification authenticity, unlinkability) to clarify trade-offs; and (v) synthesizes adoption and operational constraints that help explain observed shifts toward privacy-preserving designs.

2. Related Work

Research on digital contact tracing (DCT) spans architectures/protocols, privacy–security and governance, adoption determinants, and operational evaluations. Architecturally, deployments have been framed as centralized, decentralized, or hybrids [21], with later work arguing that this dichotomy hides important design variation; socio-technical frameworks emphasize criteria across citizens, technology, and governance and encourage privacy-preserving designs in the Google/Apple Exposure Notification (GAEN)/DP-3T family [22,23,24]. Beyond GAEN/DP-3T, protocol refinements continue; for example, DP-ACT supports both active and passive participants without reverting to centralization [25].

Privacy and governance studies document challenges in anonymization, lawful processing, and data rights across jurisdictions [26], alongside calls for interoperability and data standards to enable effective cross-system operation [27]. Ethical analyses warn that public-sector data collection can enable profiling if not constrained by purpose, minimization, and transparency [28,29].

Adoption is shaped by perceived benefits, trust, and ease-of-use; privacy concerns alone are not uniformly predictive once other factors are controlled [30]. Cultural context and attitudes toward surveillance moderate acceptance [22,24], with QR/BT-based approaches more accepted in some Asian settings than in the US/EU, irrespective of protocol choice [31]. Recent work also shows preferences vary with governance and data-use terms [32], and qualitative studies highlight communication clarity, digital literacy, and transparency as persistent barriers [33,34].

Operational evaluations reveal end-to-end constraints: measured delays from positive test to notification and low contact-notification coverage point to cascade bottlenecks [35], while large-scale analyses estimate population-level impact (e.g., NHS app) [36]. Design choices such as notification-window length trade off epidemiological effect and adherence [37], and system audits identify recurring “points of failure” to address for real-world effectiveness [38]. These findings motivate our six-model classification and 24-indicator evaluation of privacy (G1/G3), authenticity/timeliness (G2), functionality, and governance.

3. Methodology

We created a comprehensive inventory of contact tracing (CT) platforms deployed by 20 countries, including those utilizing the globally adopted Google Exposure Notification (GAEN) API, starting in July 2020. Our search methodology combined manual exploration via the Google search engine and app listings in the Play Store, accessed from both Canada and Pakistan, to ensure broader geographic visibility. We used a set of consistent keywords, including “contact tracing,” “COVID-19,” and “coronavirus app/platform,” paired with country-specific queries (e.g., “coronavirus contact tracing app in USA”) to maximize the identification of localized platforms.

Platforms were included in the evaluation if they met at least one of the following criteria: over 10,000 downloads, availability of open-source code, existence of a technical white paper or report, or coverage in peer-reviewed literature. We continued this process through recursive exploration, following recommendation links, official documentation trails, and developer-provided resources, until no additional qualifying CT platforms were discoverable under our inclusion parameters.

Functional analysis began by installing the applications on Apple iPhone 11 (Apple Inc., Cupertino, CA, USA; iOS 13.5–13.6) and Apple iPhone 12 (Apple Inc., Cupertino, CA, USA; iOS 14.2–14.5), as well as on Google Pixel 3 (Google LLC, Mountain View, CA, USA; Android 10 and Android 11), that allowed cross-border access, permitting direct testing and behavioral inspection. For region-locked or sunset platforms, we relied on documentation and public technical records to understand their functionality. We conducted a detailed review of each platform’s architectural and security components using source code (when available), white papers, reports, and scholarly analyses. Each platform was then evaluated based on five core security dimensions: (i) system architecture, (ii) communication and security protocols, (iii) cryptographic implementation, (iv) user identity management approach, and (v) backend integration with healthcare servers and government systems, as illustrated in Figures 1–6.

To capture the dynamic nature of these platforms, we repeated the review at three points: July 2020 (immediately after early national launches and the public release of the GAEN API on 20 May 2020), November 2020 (after mid-course pivots and hardening updates, including U.S. state-level migrations), and April 2021 (when first-generation CT apps had largely stabilized). We focus on this window because most deployments were actively installable, maintained, and publicly documented during this period; major architectural shifts occurred within 3–6 months of initial release; and comparable evidence (policies, code, DPIAs) was available across jurisdictions. Beyond mid-2021, many apps entered maintenance or sunset, and later changes were sparse or administrative, which would confound an architecture-level comparison. A final set of 18 platforms from 12 countries was compiled from the union of these three review phases (

Table 1. Corpus and model mapping (July 2020–April 2021). Reference set of 18 CT platforms mapped to protocol lineage and architectural model; forms the basis for the model-level comparisons in Section 6.

#	CT Solutions	Developer	Deployed	Platform	Source Code	User Base +
1	GAEN APIs [39,40]	Apple & Google	37 Countries (Globally)	API	✓	Millions of users by 65 Apps
2	Health Code [41]	Tencent and Ant Group	China	Framework	✖	900 million
3	Aarogya Setu [21]	NIC, India	India	Android/iOS	✓	214 million
4	ConTra Corona [42]	FZI Research Center, Germany	Germany	Protocol	✓	48 million
5	Immuni (Pronto-C2) [21,43]	Italian Government	Italy	Android/iOS	✖	19 million
6	CovidSafe [44,45,46]	Australian Government	Australia	Android/iOS	✓	7 million
7	StopCovid/TousAntiCovid [21,47,48]	INRIA & Fraunhofer	France	Android/iOS	✓	5 million
8	TraceTogether (OpenTrace) [49]	Ministry of Health, GOVTECH & SG UNITED	Singapore	Android/iOS	✓	4.9 million
9	Hamagen [19,21]	Israeli Ministry of Health	Israel	Android/iOS	✓	2.5 million
10	CovidSafe-PACT (West-coast) [7,50,51]	University of Washington	USA	Protocol	✓	2 million
11	SwissCovid-DP-3T [52,53]	FOPH, Switzerland	Switzerland	Android/iOS	✓	1 million
12	CovidWatch–TCN [54]	ADHS-Arizona, Stanford University, and the University of Waterloo	Waterloo, Canada	Android/iOS	✓	10k
13	COVID Safe Paths (Private Kit) [6,55]	MIT Media Lab	USA	Android/iOS	✓	10k
14	Coronavirus Disease-19 [19,56]	South Korean Government	South Korea	Website	✖	–
15	DP3T [57]	Swiss Federal Institute of Technology (EPFL)	Europe	Protocol	✓	–
16	DESIRE protocol [58]	INRIA, France	–	Protocol	✖	–
17	EpiOne [59]	UC Berkeley, USA	–	Protocol	✖	–
18	PACT East Coast [50,51]	MIT, USA	–	Protocol	✓	–

Notes: ✓ = source code available; ✖ = source code not available; + = aggregate total across all listed applications; – = no user base information available.

). In addition to structural and functional evaluations, we performed privacy, computational, and contextual analyses, drawing on the CDC’s digital contact-tracing assessment criteria and our systematized parameters, which are aligned with our architectural subsets. This allowed us to score, compare, and map each platform’s operational model against existing CT architectures. Longer-term adoption and evolution signals through December 2022 are summarized in Section 7 to contextualize, but not re-score, the core evaluation.

3.1. Scoring Transparency, Reliability, and Robustness

• Indicator set: We operationalized the evaluation into 24 indicators grouped under four pillars: Privacy (P1–P6), Security (S1–S6), Functionality (F1–F6), and Governance (G1–G6). Each indicator has a short rubric with three levels: 1 = present/explicit, 0.5 = partial/conditional/unclear, 0 = absent/contradicted. The complete indicator → evidence catalog (codes, definitions, and what qualifies for 1/0.5/0) appears in Appendix A. Indicators and scores are interpreted under the assumptions and adversaries defined in Section 3.2. Specifically, P1 operationalizes G1 (PII secrecy on public channels), P2 operationalizes G3 (unlinkability of rotating tokens), and S1/S4 operationalize G2 (authenticity of case verification and notifications).
• Scoring procedure: For each platform, raters assigned a value in {0, 0.5, 1} per indicator based on publicly documented evidence (e.g., protocol/architecture documents, privacy policies, DPIAs, verification workflows, and, where applicable, open-source repositories or external audits [6,7,39,40,41,42,43,44,46,48,49,50,51,52,53,55,56,57,58,59,60,61]). Missing or ambiguous evidence was scored 0.5 rather than left blank to preserve comparability.
• Aggregation: Pillar scores are simple arithmetic means over indicators within the pillar; the model/platform overall score is the unweighted mean over all 24 indicators:

  $${\mathrm{S}}_{\mathrm{p}\mathrm{i}\mathrm{l}\mathrm{l}\mathrm{a}\mathrm{r}}={\displaystyle \frac{1}{\left|{\mathrm{F}}_{\mathrm{p}}\right|\mathrm{s}\mathrm{u}{\mathrm{m}}_{\mathrm{f} \mathrm{i}\mathrm{n} {\mathrm{F}}_{\mathrm{p}}}{\mathrm{s}}_{\mathrm{f}}}},\hspace{1em}\hspace{1em}{\mathrm{S}}_{\mathrm{o}\mathrm{v}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{l}\mathrm{l}}={\displaystyle \frac{1}{24}}\mathrm{s}\mathrm{u}{\mathrm{m}}_{\mathrm{f}=1}^{24}{\mathrm{s}}_{\mathrm{f}}$$
• Notations: Symbols are defined in Appendix B,

  Table A8. Mathematical symbols, parameters and formulas used in methods and results, including domains and brief meanings.

  Symbol	Meaning/Definition	Domain/Units
  $\mathrm{F}$	Number of indicators (here F = 24)	$\mathrm{N}$
  $\mathcal{I}$	Set of all platforms; ${\mathcal{I}}_{\mathcal{m}}\subset \mathcal{I}$: platforms in model m	set
  ${\mathrm{s}}_{\mathrm{f}\mathrm{i}}^{\left(\mathrm{r}\right)}$	Score given by rater r for platform i on indicator f	{0,0.5,1}
  ${\mathrm{s}}_{\mathrm{f}\mathrm{i}}$	Consensus score for platform i on indicator f: mean over raters	[0, 1]
  ${\mathrm{S}}_{\mathrm{i}}$	Platform unweighted score: $S_i={\displaystyle \frac{1}{F}}su{m}_{f=1}^F{s}_{fi}$	[0, 1]
  ${\mathrm{S}}_{\mathrm{m}}$	Model unweighted score: ${\mathrm{S}}_{\mathrm{m}}=\left(1/\left|{\mathrm{I}}_{\mathrm{m}}\right|\right){\displaystyle \sum _{\mathrm{i}\in {\mathrm{I}}_{\mathrm{m}}}}{\mathrm{S}}_{\mathrm{i}}$	${\mathcal{I}}_{\mathcal{m}}$
  ${\mathrm{S}}_{\mathrm{pillar}}$	Pillar score: mean of indicators within a pillar	[0, 1]
  ${\mathsf{\kappa }}_{\mathrm{f}}$	Cohen’s kappa for indicator f between two raters	[−1, 1]
  ${\overline{\mathsf{\kappa }}}_{\mathrm{P}}$	Macro-average kappa over indicators in pillar P	[−1, 1]
  $\mathrm{w}$	Indicator weight vector, $w \in {\mathbb{R}}_{\ge 0}^F, su{m}_f{w}_f= 1$	simplex
  $\mathrm{w}\sim \mathrm{Dir}\left(1,\dots ,1\right)$	Sampling scheme for sensitivity (uniform overweight simplex)	—
  ${\mathrm{S}}_{\mathrm{i}}\left(\mathrm{w}\right)$	Weighted platform score: $su{m}_f{w}_f{s}_{fi}$	[0, 1]
  ${\mathrm{S}}_{\mathrm{m}}\left(\mathrm{w}\right)$	Weighted model score: mean of $S_{i\left(w\right)for}i \in {\mathcal{I}}_m$	[0, 1]
  Top-1 change rate	Fraction of weight draws where the top model differs from unweighted baseline	[0, 1]
  Top-2 set stability	Fraction of draws where the top-2 set matches baseline (order ignored)	[0, 1]
  ${\mathsf{\Delta }}_{\mathrm{notify}}$	Verification/notification latency (test → code → notification)	days
  ${\mathsf{\rho }}_{\mathrm{share}}$	Positive users’ share rate (uploaded codes/positives)	[0, 1]
  ${\mathrm{C}}_{\mathrm{cov}}$	% of exposed contacts notified	[0, 1]

  ; we use $\mathsf{\kappa }$ for Cohen’s kappa, ${\mathrm{s}}_{\mathrm{f}}\in \left\{0,0.5,1\right\}$ for indicator scores, and $\mathrm{w}\sim \mathrm{D}\mathrm{i}\mathrm{r}\mathrm{i}\mathrm{c}\mathrm{h}\mathrm{l}\mathrm{e}\mathrm{t}\left(1,\dots ,1\right)$ for sensitivity weights.
• Rater protocol (inter-rater reliability): To test reproducibility, two independent ratings were produced for six representative platforms, one per architectural model in this study (Fully Centralized, Subset Data, Bulletin Board, Indexed Data, Dedicated Servers, Custodian). Each rater coded all 24 indicators for each platform using the rubric in

  Table A1. Indicator catalog and scoring rubric (24 indicators). Defines P1–P6 (Privacy), S1–S6 (Security), F1–F6 (Functionality), and G1–G6 (Governance), with decision rules for 1/0.5/0 and typical evidence sources. Aligns with goals G1–G3 and the threat model in Section 3.2.

  Code	Pillar	Indicator	Scoring Rubric (0/0.5/1)
  P1	Privacy	No PII on public channels (BLE/network payloads)	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  P2	Privacy	Rotating IDs unlinkable across time/devices	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  P3	Privacy	Data minimization (only needed metadata)	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  P4	Privacy	Consent-bound uploads & limited scope	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  P5	Privacy	Explicit retention limits & deletion	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  P6	Privacy	Local-first matching by default	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  S1	Security	Verified diagnosis upload (lab/TAN)	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  S2	Security	Submission validation & deduplication	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  S3	Security	Replay/relay resistance documented	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  S4	Security	Notification authenticity (crypto)	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  S5	Security	Abuse rate-limits/fraud controls	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  S6	Security	Secure transport & crypto transparency	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  F1	Functionality	Automated proximity logging (BLE/QR)	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  F2	Functionality	End-to-end exposure notification workflow	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  F3	Functionality	Verification & follow-up to testing/care	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  F4	Functionality	Interoperability/federation/cross-region	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  F5	Functionality	Offline resilience (queued updates)	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  F6	Functionality	Opt-out & data deletion by user	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  G1	Governance	Role separation (PHA vs. infra/keys)	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  G2	Governance	Access controls & least privilege	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  G3	Governance	Transparency (DPIA/privacy report)	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  G4	Governance	Open source or external audit	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  G5	Governance	Sunset/exit plan documented	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}
  G6	Governance	Incident response & disclosure	{“1.0”: “Present/explicit”, “0.5”: “Partial/conditional/unclear”, “0.0”: “Absent/contradicted”}

  . We computed Cohen’s $\mathsf{\kappa }$ per indicator and report macro-averages by pillar.
• Model-level scores (unweighted): Averaging the two raters and then averaging platforms per model yielded model-level scores, presented in Figure 7.
• Sensitivity to indicator weights: To assess robustness to alternative priorities, we drew 1000 random weight vectors $\mathrm{w}$ from a symmetric $\mathrm{D}\mathrm{i}\mathrm{r}\mathrm{i}\mathrm{c}\mathrm{h}\mathrm{l}\mathrm{e}\mathrm{t}\left(1,\dots ,1\right)$ over the 24 indicators, recomputed weighted platform scores, $\mathrm{s}\mathrm{u}{\mathrm{m}}_{\mathrm{f}}{\mathrm{w}}_{\mathrm{f}}{\mathrm{s}}_{\mathrm{f}}$ and re-ranked models by the means of their platforms.
• Reproducibility artifacts: We provided Table A1 (rubric),

  Table A5. Rater 1’s Ratings. six representative platforms × 24 indicators. Raw 0/0.5/1 entries used for κ computation and model-level means.

  Platform	P1	P2	P3	P4	P5	P6	S1	S2	S3	S4	S5	S6	F1	F2	F3	F4	F5	F6	G1	G2	G3	G4	G5	G6
  TraceTogether (BlueTrace)	1	0.5	0.5	0.5	0.5	0	1	0.5	1	0.5	0.5	1	1	1	1	0.5	1	1	0.5	0.5	0.5	0.5	0	0.5
  TousAntiCovid (ROBERT early)	1	0.5	0.5	0.5	0.5	0	1	0.5	1	0.5	0.5	1	1	1	1	0.5	1	1	0.5	0.5	1	0.5	0.5	0.5
  SwissCovid (DP-3T/GAEN)	1	1	1	1	1	1	1	0.5	1	1	0.5	1	1	1	0.5	0.5	1	1	1	0.5	1	1	0.5	0.5
  Pronto-C2 (research)	1	1	1	1	1	1	0.5	0.5	1	1	0.5	1	1	1	0.5	0.5	1	1	0.5	0.5	0.5	0.5	0	0.5
  ConTra Corona (research)	1	1	1	1	1	0.5	1	1	1	1	0.5	1	1	1	0.5	0.5	1	1	1	0.5	0.5	0.5	0	0.5
  Epione (UC Berkeley)	1	1	1	1	1	1	1	1	1	1	0.5	1	1	1	0.5	0.5	1	1	0.5	0.5	0.5	0.5	0	0.5

  and

  Table A6. Rater 2’s Ratings. six representative platforms × 24 indicators. Companion to Table A5 for inter-rater analysis; differences feed the Cohen’s $\mathsf{\kappa }$ ($\mathsf{\kappa }$).

  Platform	P1	P2	P3	P4	P5	P6	S1	S2	S3	S4	S5	S6	F1	F2	F3	F4	F5	F6	G1	G2	G3	G4	G5	G6
  TraceTogether (BlueTrace)	0.5	0.5	0.5	0.5	0.5	0	0	0.5	1	0.5	0.5	1	1	1	1	0	1	0	0.5	0.5	0.5	0.5	0	0.5
  TousAntiCovid (ROBERT early)	1	0.5	0.5	1	0.5	0	1	0.5	1	0.5	0.5	0	1	0.5	0	0.5	1	0	0.5	0.5	1	0.5	0.5	0
  SwissCovid (DP-3T/GAEN)	1	1	1	1	1	1	1	0.5	1	1	0.5	1	1	1	0.5	1	0.5	1	1	0.5	0.5	0	0.5	0.5
  Pronto-C2 (research)	1	0.5	1	1	1	1	0.5	0.5	0	1	0.5	1	1	1	0.5	0.5	1	1	0.5	0.5	0.5	0	0	0.5
  ConTra Corona (research)	1	1	1	1	0	1	1	1	1	1	0	0.5	1	0	1	1	1	1	1	0.5	1	0.5	0	0.5
  Epione (UC Berkeley)	1	1	1	1	1	1	1	1	1	1	0.5	1	0.5	1	0.5	0.5	1	1	0.5	0.5	1	0	0.5	0.5

  (rater matrices), and Appendix B (notation/procedures). These artifacts enable exact replication of all numbers reported here.
• Limitations: Our Scoring reflects publicly documented behavior and artifacts, which vary by jurisdiction and time; the inter-rater study covers six representative platforms (model-level inference). Baseline aggregation is unweighted to avoid hidden priorities; we mitigate subjectivity with the 1000-draw sensitivity analysis. We do not present formal cryptographic proofs, code audits, or user-level trials; these are listed as future work with explicit goals/adversaries.

3.2. Security Assumptions and Threat Model

• Assets: PII; rotating proximity tokens (e.g., RPIs/seeds); diagnosis verification codes; integrity of exposure notifications.
• Adversaries: (A1) active network attacker (Dolev–Yao) on public channels; (A2) malicious user attempting bogus uploads or re-identification; (A3) honest-but-curious backend that follows protocols but seeks extra inferences.
• Assumptions: App–server links use modern TLS; platform crypto uses OS-attested key storage and documented primitives; diagnosis codes are bound to lab workflows; ephemeral identifiers rotate as specified; consent gates uploads; no side-channel, baseband, or physical-layer attacks; the adversary does not break standard cryptography.
• Goals: (G1) PII secrecy on public channels; (G2) authenticity of case verification and notifications; (G3) unlinkability of rotating tokens at scale; (G4) data minimization and bounded retention.
• Scope: We evaluate architecture-level protections and governance controls. Formal mechanized proofs, device compromise beyond the user handset, global cross-app fusion, and side-channel/timing attacks are out of scope and noted in Discussion/Limitations.

4. Contact Tracing Platform Corpus and Mapping

We analyzed 18 digital contact-tracing platforms (May 2020–April 2021) across 12 countries and for each platform we, identified its protocol family (e.g., GAEN/DP-3T/other), assigned it to one of our six architectural models (based on compute locus and data addressability), and linked scores to primary evidence (official policy/Privacy Notice, technical spec/protocol, repository, DPIA or audit). Where cross-border installation was not possible, we relied on these official artifacts. Table 1 lists the corpus, Platform, Country/Scope, Protocol family, and Assigned model, and serves as the bridge to the comparative results reported in Section 6. Concise per-platform functional notes are provided in Appendix C (Platform Notes).

5. Capabilities and Attributes Analysis

Following an in-depth examination of individual tools, we conducted a quality assessment using the evaluation criteria set by the US Centers for Disease Control and Prevention (CDC). Additionally, we performed an ad hoc analysis focusing on security risks and potential attacks, along with general security guidelines relevant to contact-tracing (CT) platforms.

5.1. CDC Criteria

CDC has defined a set of preliminary criteria for the Minimum and Preferred characteristics of digital contact tracing tools, demonstrating the quality-based differences between these systems [62]. Their goal is to support health authorities in resolving COVID-19 contact-tracing workflow bottlenecks and in deploying a regulation-compliant digital CT infrastructure. These metrics are drawn from preliminary research and targeted discussions with contact tracing and informatics experts across the county, state, and federal governments, national public health associations, academic consortia, and nongovernmental organizations [62]. Table 2 illustrates the quality assessment of our centralized and decentralized contact-tracing apps/frameworks developed based on the CDC’s evaluation criteria. The main evaluation parameters were Patient Identification, Contact Elicitation, Contact Notification, User Involvement, Availability, Trustworthiness, Platform support, Data Interoperability, Privacy, Technical support, Vendor Experience, Contact Follow-up, Customizability and Localization. Each platform performs differently according to its preferences and resources; however, the general definition of these parameters is as follows:

• Patient Identification: The platform enables the user to report their validated test status, relevant demographic data, data facilitating the connection with supportive services, and the best means of communication.
• Contact Elicitation: Enables the manual import of proximity data.
• Contact Notification: Enables automated notification to community contacts as per proximity, keeping the patient anonymous.
• User Involvement: Awareness spread; motivation created and confidence built.
• Availability: Rapidly deployable or successfully in use by jurisdictions.
• Trustworthiness: is Open source.
• Platform support: Supports cross-platform functionality, caching and offline data entry.
• Data Interoperability: Secure Data transfer over secondary channels (by PHAs).
• Privacy: Authorized data access only.
• Technical support: Develops/vendors provide technical support.
• Vendor Experience: Working experience in a healthcare setting.
• Contact Follow-up: Immediate exposure assessment and relevant notifications to contacts and PHAs.
• Customizability and Localization: Allow some level of customization and choice of language.

Table 2. Capabilities and attributes by architecture. At-a-glance differences in compute locus, data addressability, and verification/notification path, interpreted under Section 3.2 threat model (G1–G3).

Tools	P.I.	C.I.	C.N.	U.I.	A	T	P.S.	D.I.	P	T.S.	V.E.	C.F.	C	L
TraceTogether (OpenTrace)	<	<	<	<	✦	✦	✦	<	<	✓	✓	<	<	✓
Coronavirus Disease-19	<	<	<	<	<	<	<	<	<	✓	✓	<	<	✓
Health Code	<	<	<	<	✦	<	<	<	<	✓	✓	<	<	✖
CovidSafe	<	<	<	<	✦	✦	✦	<	<	✓	✓	<	<	✖
StopCovid	<	<	<	<	✦	✦	✦	<	<	✓	✓	<	<	✖
Aarogya Setu	<	<	<	<	✦	✦	✦	<	<	✓	✓	<	<	✓
GAEN APIs’s Apps	<	<	✦	✦	✦	✦	✦	✦	✦	✖	✖	✦	✦	✖
PACT East Coast	✦	✦	✦	✦	<	<	✦	✦	✦	✖	✖	✦	✦	✓
CovidSafe-PACT (West-coast)	✦	✦	✦	✦	<	<	✦	✦	✦	✖	✖	✦	✦	✓
SwissCoviD-DP-3T	✦	✦	✦	✦	✦	✦	✦	✦	✦	✖	✖	✦	✦	✓
DP-3T Unlinkable	✦	✦	✦	✦	✦	✦	✦	✦	✦	✖	✖	✦	✦	✓
CovidWatch-TCN	✦	✦	✦	✦	✦	<	✦	✦	✦	✖	✖	✦	✦	✖
Hamagen	✦	✦	✦	✦	✦	✦	✦	✦	✦	✖	✖	✦	✦	✓
COVID Safe Paths	✦	✦	✦	✦	<	✦	✦	✦	✦	✖	✖	✦	✦	✓

Notes: “✓” means yes while “✖” means No; “<“ denotes the Minimum criteria, whereas “✦” denotes achieving the Preferred Criteria [62].

Table 2. Capabilities and attributes by architecture. At-a-glance differences in compute locus, data addressability, and verification/notification path, interpreted under Section 3.2 threat model (G1–G3).

Tools	P.I.	C.I.	C.N.	U.I.	A	T	P.S.	D.I.	P	T.S.	V.E.	C.F.	C	L
TraceTogether (OpenTrace)	<	<	<	<	✦	✦	✦	<	<	✓	✓	<	<	✓
Coronavirus Disease-19	<	<	<	<	<	<	<	<	<	✓	✓	<	<	✓
Health Code	<	<	<	<	✦	<	<	<	<	✓	✓	<	<	✖
CovidSafe	<	<	<	<	✦	✦	✦	<	<	✓	✓	<	<	✖
StopCovid	<	<	<	<	✦	✦	✦	<	<	✓	✓	<	<	✖
Aarogya Setu	<	<	<	<	✦	✦	✦	<	<	✓	✓	<	<	✓
GAEN APIs’s Apps	<	<	✦	✦	✦	✦	✦	✦	✦	✖	✖	✦	✦	✖
PACT East Coast	✦	✦	✦	✦	<	<	✦	✦	✦	✖	✖	✦	✦	✓
CovidSafe-PACT (West-coast)	✦	✦	✦	✦	<	<	✦	✦	✦	✖	✖	✦	✦	✓
SwissCoviD-DP-3T	✦	✦	✦	✦	✦	✦	✦	✦	✦	✖	✖	✦	✦	✓
DP-3T Unlinkable	✦	✦	✦	✦	✦	✦	✦	✦	✦	✖	✖	✦	✦	✓
CovidWatch-TCN	✦	✦	✦	✦	✦	<	✦	✦	✦	✖	✖	✦	✦	✖
Hamagen	✦	✦	✦	✦	✦	✦	✦	✦	✦	✖	✖	✦	✦	✓
COVID Safe Paths	✦	✦	✦	✦	<	✦	✦	✦	✦	✖	✖	✦	✦	✓

Notes: “✓” means yes while “✖” means No; “<“ denotes the Minimum criteria, whereas “✦” denotes achieving the Preferred Criteria [62].

The minimum and preferred criteria for the technical and general attributes of these tools are outlined below. Even if a platform achieves a partial expectation of a parameter, it is classified as meeting the minimum standard; otherwise, approximately or completely fulfilled criteria are regarded as reaching the preferred rank. For instance, comprehending its demonstration, “privacy,” the primary concern of all tracing applications, is under discussion. The minimum capabilities of these tools for privacy are expected to have the following characteristics [62]: transparently informing users of which data is collected, how it is used, how long it will be retained, implementing measures to prevent the introduction of false data, requiring the consent of both index patient and contact before using PII, encrypting data in transit and at rest, providing individuals access to their data and ability to revoke consent at any time, providing individuals with the ability to delete their data, providing publicly available independent security and privacy assessments that address issues of trustworthiness, for instance, using open architectures, open standards, providing open-source code, security, and privacy, and lastly, authorized data access only for PHAs and must be limited to a need-to-know basis. At the maximum preferred rate of characteristics, these apps should allow individuals to delete their own data.

Patient Identification (P.I.), Contact Elicitation (C.E.), Contact Notification (C.N.), User Involvement (U.I.), Availability (A.), Trustworthiness (T), Platform Support (P.S.), Data Interoperability (D.I.), Privacy (P), Technical Support (T.S.), Vendor Experience (V.E.), Contact Follow-up (C.F.), Customizability (C) and Localization (L).

5.2. Security Risks and Attacks

We assessed threats under the adversaries and goals defined in Section 3.2. Five recurring risks span the six models (details summarized in

Table 3. Privacy-relevant exposure points and re-identification vectors per architecture (indicator definitions P1–P6 and goals G1 (PII secrecy)/G3 (unlinkability)).

Architecture	Primary Privacy Exposure Points	PII at Risk/Data Items	Re-identification Vectors	Other Notes
Centralized Apps	User end; Server end; Secondary channels	All user data stored or referenced centrally	Linkage via secondary channels (e.g., correlating app/broadcast metadata)	Susceptible to contact-advertising message correlation; proximity detection concerns reported
Decentralized Apps	User end; Secondary channels	Seeds & chirps on devices; uploads are keys/seeds	Traffic analysis/linkage via side information	False positives are possible by relaying chirps (if mitigations are weak)
Hybrid Apps	User end; Secondary channels	Risk of PII de-anonymization in some flows	Correlation of anonymous broadcast data via secondary channels	Similar proximity/advertising concerns if broadcasts are linkable

and

Table 4. Security and operational threats by architecture (indicator definitions S1–S6 and goal G2 (authenticity of verification/notifications)).

Architecture	Server/User-ID Protection Threats	Consequences If Server Is Compromised	Typical Attack Surfaces	Relative Difficulty
Centralized Apps	Single point of failure/attack; weak auth on BLE contact info	Broad data exposure (all user data)	DoS; Replay/Relay; Linkage attacks	Easy
Decentralized Apps	Less central SPOF; risks shift to key distribution and client integrity	Access to seeds/chirps may enable graph inference if combined with side info	Traffic analysis; DoS; Limited replay; Relay; Linkage	Hard
Hybrid Apps	Mixed: partial central services + device-side matching; correlation risks	PII de-anonymization possible if joins occur	DoS; Relay; Linkage (esp. via secondary channels)	Hard

).

• Single point of risk/attack (A3): Centralized storage or broad addressability increases blast radius unless bounded by minimization, retention, role separation, and audit.
• Linkage: Correlating ephemeral identifiers with side information can re-identify users; unlinkability depends on rotation schedules and non-inverting indexes (G3).
• Denial of service (DoS): Floods of well-formed but bogus beacons/uploads drain client/server resources; rate-limits and verification gates mitigate (G2).
• Replay/relay: Re-broadcast of recently valid identifiers can trigger false matches; rotation and timestamp checks reduce impact (G2/G3).
• Traffic analysis: Observing upload/download patterns can reveal status changes; padding, batching, and uniform fetch policies reduce inferences (G1/G3).

Model posture: Server-side matching (Fully Centralized/Subset) eases verification and notification integrity (G2) but raises addressability and linkage risk; device-side matching (Bulletin Board/Dedicated) strengthens PII secrecy and unlinkability (G1/G3) and relies on robust verification gates for G2. Custodian/Indexed balance queryability with separation of roles and careful index design. Table 3 and Table 4 consolidate threats and typical mitigations by model; Appendix D provides concise, cited examples.

5.3. CT Platforms’ Security Guidelines

We followed community guidance (e.g., secure mobile build/release practices and verification-code binding) and observed recurring pitfalls: debug features in production, over-persistent identifiers or characteristics, insufficient rotation/salting of indexes or tokens, and weak role separation in verification gateways. Concrete case notes and mitigations (e.g., disabling WebView debugging in release builds; prompt clearing of BLE characteristics; GAEN/DP-3T rotation hygiene; bounded retention; audit trails) are provided in Appendix D, with references to primary artifacts.

6. Proposed Frameworks

On our archived list of 18 platforms, we conducted CDC criteria assessment and ad hoc analysis to elicit privacy and security properties, in addition to their quality features and limitations. The conventional categorization of contact-tracing systems into centralized and decentralized approaches has proven inadequate when evaluating the effectiveness of these systems in meeting the specific resource and security requirements of healthcare jurisdictions. It is essential to recognize the diverse roles played by health authorities, central servers, and user devices in the contact-tracing workflow and the complex nature of data flow within these systems. This highlights the necessity for new criteria to assess the architectures of contact-tracing systems, moving beyond the traditional binary classification of centralized and decentralized systems. The limitations of these conventional classifications are evident when we consider the intricacies of workflows and the need to determine whether a customized design aligns with the unique health and computational constraints of different jurisdictions.

As examined, all protocols and platforms have different server roles, built-in protections, trust assumptions, privacy and security concerns, and measures taken. Considering these takeaways, all contact-tracing platforms were re-investigated within our proposed sub-architectural designs, CDC, and privacy criteria to bring out further differences, scores, and efficacy of the CT systems.

Our Models

• Fully Centralized Model: The server manages the security keys, generates anonymous IDs, conducts contact risk analysis, and performs notification processes. Such architectures push the risk analysis and notification processes to the centralized server, and health authorities decide the rate of notifications provided by pandemic conditions. The central server plays a key role in carrying out staple functionalities such as storing encrypted PII, generating anonymous TempIDs, risk analysis, and notifications for close contacts. The server is found to be trustworthy in this architecture. Contact tracing applications, that is, TraceTogether (OpenTrace), Coronavirus Disease-19, Health Code, and CovidSafe, were examined as part of these architectures and are illustrated in Figure 1.
  In this role, the server starts the process by verifying the device through a telephone network. Once the device verification and user registration at the server end are completed, the server shares the encrypted pairs of tempIDs and timestamps (T). Now, the devices start contact tracing by sharing TempID, phone model, and transmitting power (TxP) with any other device in proximity to the same application installed. In addition to these values, the user’s PII is stored in the database of personal nodes. On the other hand, the server keeps the records of the user’s PII, T, TxP, and received signal strength indicator (RSSI). Whenever a user has symptoms of COVID-19, they will trigger Step 3 by sharing their unique TempID, TxP, and RSSI values with the server to perform a risk assessment that will further request the public health authority (e.g., hospital) to verify the patient information by sharing the user’s PII only. Hence, based on the hospital’s verification, the server will notify the user about a self-isolation or “no danger” message.

2.

Subset Data Model: Roles are divided between user devices and servers, and the central server undertakes risk analysis and notifications. It also differs in its level of privacy, based on the type of user data stored at the server end. The protocols also vary in the notification process, that is, how vulnerable users are notified. Users are also expected to check the status of EphIDs regularly with the server to determine if they are exposed to risk. The Robert and Desire protocols and StopCovid and Aarogya Setu applications are classified under a subset data model, as shown in Figure 2.

Unlike a fully centralized server, it does not approach the health authority to perform user verification and risk analysis. Instead, the hospital keeps updating the server’s database with an active patient list and deleting the data of cured patients from their end. Another privacy benefit is the privilege given to the user to manually delete their records from the central server once their quarantine is over.

3.

Custodian Data Model: Based on the Inria-EpiOne protocol, health authorities maintain a database of tokens corresponding to infected users. Here, the server cannot locate vulnerable users with the disease without colluding with healthcare authorities. Similarly, the healthcare provider is not allowed access to randomize contact tokens without colluding further with the server. Even if the server can link a user to specific tokens or seeds in its database, no further information can be drawn. This confines the limit of exposure to the event of collusion or database breach, in contrast to a fully compartmentalized or dedicated server model.

Similarly, in Figure 3, the device generates a random key K_t, computes Sid_t (metadata, e.g., IP address) and Pid_t (time, location), stores them, and uploads K_t to a central server that recomputes Sid_t and Pid_t in the same way. Again, Rid_i is the real ID, for example, name, phone #, etc., and R_test = Request for a medical test, while Wid_i = Warning ID about exposure.

4.

Dedicated Servers Model: This is a server architecture designed based on the ConTra Corona protocol. It features a strict separation of tasks under different servers, which are submission, matching, deduplication, notification, and warning servers. Without learning the signed and encrypted public identifiers, health authorities upload them to the server, which looks up the respective registered secret identities and encrypts a pseudonym. The warning server then decrypts this later. The deduplication and submission servers share a symmetrical key. On submission arrival, the submission server marks all individual entries with a random identifier, that is, the deduplication identifier, which is encrypted with the shared symmetric key. The deduplication server decrypts the deduplication identifier and maintains only a random ‘$Sid\_i″$’ for each deduplication identifier. Then, it discards all deduplication identifiers and hands all the individuals ‘$Sid\_i″$’ to the warning server that publishes them to the users for further verification by healthcare.

For every time period t, the device generates a random key K_t and computes Sid_t (metadata, e.g., IP address) and Pid_t (time, location), stores them, and uploads K_t to a central server that recomputes Sid_t and Pid_t in the same way. Here, Rid_i is the real ID, for example, name, phone #, etc., and R_test = Request for a medical test, while Wid_i = Warning ID about exposures, as shown in Figure 4.

5.

Bulletin Board Model: In this framework, all the major servers’ centralized roles are transferred to the devices, while the server acts simply as a bulletin board. In addition, it aims to keep users’ identities secret from the central server. Consequently, a server security breach in this architecture would result in less information leakage. The following contact tracing applications come under this category: GAEN APIs Apps, PACT East Coast, CovidSafe-PACT (West-coast), SwissCoviD-DP-3T, Hamagen, and COVID Safe Paths.

In addition to the locally stored seed data used to generate chirps, chirp data, including the received time, PII, location, and signal strength, are also stored at personal nodes. At any stage, if a user feels the symptoms of coronavirus, it voluntarily uploads its seeds and a time stamp with the central server. In this framework, the server only keeps the set of seeds and timestamps for infected users and shares them with all the devices that have come into proximity with infected users in the past few days. Regional healthcare authorities can broadcast to users directly with alerts. Overall, the risk verification and notification processes were performed at a personal node. In Figure 5, UId is the user identity information and T(t_b = beginning time, t_e = expiry time).

6.

Indexed Data Model: This design responds to the claims of a decentralized model subjected to linkage and enumeration attacks. Previously, daily keys for infected users were available to all other devices in the network. The server needs to be careful to minimize the chances of false positives, although this drawback has been claimed to be overcome within this design. Additionally, the server can be used to store encrypted pseudonyms and authentication. For instance, unlike typical decentralized structures, only compact seed data (master key, expiry time, etc.) are uploaded to the server rather than the entire list. All seeds that belong to a case can be tested easily, as they are produced and bound to the same master key.

Health authorities trigger the process of contact tracing by verifying the illness that allows the user to upload encrypted information. The major difference is that the server does not share the infected users’ seeds directed toward endangered users; rather, the server shares the memory address where the infected seeds are stored at the server’s end. However, the user performs the risk verification process to provide the information that the monitor shares. Contact tracing platforms are believed to use this communication design, that is, CovidWatch–TCN, Pronto-C2, and DP-3T Unlinkable. As illustrated in Figure 6, UId_i is the user identity information, and T(t_b = beginning time, t_e = expiry time).

Table 5. Server-side roles and data persistence by model. Shows what is stored at device, server, and health-authority endpoints and whether records are addressable or recomputable, informing linkability/governance analysis (G3/A3).

Server Model	Device End	Server End	Health Authority
Fully Centralized Model	$\left[{\left\{\left(\mathrm{T}\mathrm{e}\mathrm{m}\mathrm{p}\mathrm{I}\mathrm{D},\mathrm{T}\right)\right\}}_{{\mathrm{k}}_{\mathrm{s}}},\mathrm{P}\mathrm{I}\mathrm{I},\mathrm{T}\mathrm{x}\mathrm{P},\mathrm{R}\mathrm{S}\mathrm{S}\mathrm{I}\right]$	$\left[{\mathrm{T}}_{\mathrm{i}},{\mathrm{P}\mathrm{I}\mathrm{I}}_{\mathrm{i}},{\mathrm{T}\mathrm{x}\mathrm{P}}_{\mathrm{i}},{\mathrm{R}\mathrm{S}\mathrm{S}\mathrm{I}}_{\mathrm{i}}\right]$	$\left[\mathbf{P}\mathbf{I}{\mathbf{I}}_{\mathbf{i}}\right]$
Subset Data Model	$\left[{\left\{\left(\mathrm{E}\mathrm{p}\mathrm{h}\mathrm{I}\mathrm{D},\mathrm{T}\right)\right\}}_{{\mathrm{k}}_{\mathrm{s}}},\mathrm{P}\mathrm{I}\mathrm{I},\mathrm{T}\mathrm{x}\mathrm{P},\mathrm{R}\mathrm{S}\mathrm{S}\mathrm{I}\right]$	$\left[{\mathrm{T}}_{\mathrm{p}},\mathrm{P}\mathrm{I}{\mathrm{I}}_{\mathrm{p}},\mathrm{T}\mathrm{x}{\mathrm{P}}_{\mathrm{p}},\mathrm{R}\mathrm{S}\mathrm{S}{\mathrm{I}}_{\mathrm{p}}\right]$	$\left[\mathbf{P}\mathbf{I}{\mathbf{I}}_{\mathbf{p}}\right]$
Bulletin Board Model	$\left[{\mathrm{S}}_{\mathrm{i}},{\mathrm{C}}_{\mathrm{i}},\mathrm{T},\mathrm{P}\mathrm{I}\mathrm{I},\mathrm{R}\mathrm{S}\mathrm{S}\mathrm{I},\mathrm{L}\right]$	$\left[{\mathrm{S}}_{\mathrm{b}},\mathrm{T}\right]$	$\left[\mathrm{P}\mathrm{I}{\mathrm{I}}_{\mathrm{i}}\right]$
Indexed Data Model	$\left[Ep{h}_{x i}, S{K}_{x i}, Add{r}_{x i}, T_i, K_i\right]$	$\left[Ep{h}_x, T_x, K_i\right]$	$\left[\mathrm{P}\mathrm{I}{\mathrm{I}}_{\mathrm{i}}\right]$
Dedicated Servers Model	$\left[\mathrm{P}\mathrm{I}{\mathrm{d}}_{\mathrm{i}},\mathrm{W}\mathrm{I}{\mathrm{d}}_{\mathrm{i}}^{\prime },\mathrm{R}\mathrm{I}{\mathrm{d}}_{\mathrm{i}},\mathrm{S}\mathrm{I}{\mathrm{d}}_{\mathrm{i}}\right]$	$\left[\mathrm{S}\mathrm{i}{\mathrm{d}}_{\mathrm{i}}^{″},\mathrm{P}\mathrm{I}{\mathrm{d}}_{\mathrm{i}}\right]$	$\left[\mathrm{P}\mathrm{I}{\mathrm{d}}_{\mathrm{i}},\mathrm{W}\mathrm{I}{\mathrm{d}}_{\mathrm{i}},\mathrm{R}\mathrm{I}{\mathrm{d}}_{\mathrm{i}},\mathrm{S}\mathrm{I}{\mathrm{d}}_{\mathrm{i}},\mathrm{d}\mathrm{a}\mathrm{t}\mathrm{e}\right]$
Custodian Data Model	$\left[\mathrm{P}\mathrm{I}{\mathrm{d}}_{\mathrm{i}},\mathrm{W}\mathrm{I}{\mathrm{d}}_{\mathrm{i}}^{\prime },\mathrm{R}\mathrm{I}{\mathrm{d}}_{\mathrm{i}},\mathrm{S}\mathrm{I}{\mathrm{d}}_{\mathrm{i}}\right]$	$\left[\mathrm{S}\mathrm{i}{\mathrm{d}}_{\mathrm{i}},\mathrm{P}\mathrm{I}{\mathrm{d}}_{\mathrm{i}}\right]$	$\left[\mathrm{P}\mathrm{I}{\mathrm{d}}_{\mathrm{i}},\mathrm{W}\mathrm{I}{\mathrm{d}}_{\mathrm{i}},\mathrm{R}\mathrm{I}{\mathrm{d}}_{\mathrm{i}},\mathrm{S}\mathrm{I}{\mathrm{d}}_{\mathrm{i}},\mathrm{d}\mathrm{a}\mathrm{t}\mathrm{e}\right]$

compares different server models and database nodes from contact-tracing platforms for the different sets of values stored at their ends. The data were examined to be interoperated in various ways in all architecture types to and in PHAs. For example, structured implementations allow manual data import from PHA information systems, whereas the majority of the forms use programmatic means of safe data transmission within information systems within jurisdictions. Contact elicitation is also a crucial feature of CTAs because it allows for the simultaneous importation of proximity and exposure data both manually and automatically, providing user consent. For instance, a fully centralized model allows PHAs to manually record and import data. In contrast, in the bulletin board model, either the patient’s self-reported data or once they have given consent, it starts to import automatically. However, they have the additional advantage of deleting data at the PHA end at any given time. Likewise, contact notification adds more value to the job as it generates exposure notifications based on the proximity data but keeps the patient’s ID anonymous. These notifications, their method of communication, duration, distance of proximity, and further healthcare actions, such as isolation and testing, followed by notifications, vary within both architectures. These are imposed in a fully centralized model while optional or broadcast pertinent community information in bulletin board systems.

7. Modular Review

7.1. Qualitative Re-Assessment

This study shows the significance of contact tracing platforms in controlling the spread of coronavirus. Our research is well defined in the subcategorization of the aforementioned traditional architectural designs and the evaluation of the unique roles of servers in different models. Although comparative computational analysis is performed on individual applications, users can differentiate the tools, but do not obtain any insights into which combination of approaches or models is better or suitable under specific healthcare, governmental, or public circumstances and preferences. Therefore, we evaluated modular approaches under the same CDC criteria and addressed both concerns by presenting the results in

Table 6. Modular evaluation of capabilities and attributes (quality scores). Ordinal scores 1–4 summarize documented capabilities by architectural model (e.g., notification, interoperability, privacy).

Server Models	Patient Identification	Contact Elicitation	Contact Notification	User Involvement	Availability	Trustworthiness	Platform Support	Data Interoperability	Privacy	Technical Support	Vendor Experience	Contact Follow-up	Customizability and Localization
Fully Centralized Model	4	1	2	2	4	2	3	3	2	3	3	4	3
Subset Data Model	4	1	2	3	2	3	3	3	2	3	3	4	3
Bulletin Board Model	2	4	4	2	3	4	4	4	4	4	1	2	4
Indexed Data Model	2	4	4	2	2	4	2	4	4	2	1	2	2
Dedicated Servers Model	3	2	4	2	1	4	1	4	3	1	4	4	1
Custodian Data Model	3	2	3	2	1	1	1	3	3	1	4	4	1

Notes: Gray shading highlights higher scores for quick scanning. Ranking: 1 = none; 2 = low; 3 = medium; 4 = high.

.

To the best of our knowledge, computational and attribute analyses have been evaluated to present a bulletin board model that outperforms the others. After performing this comparative analysis, we concluded that these criteria superficially touched on privacy concerns and that there is a dire need for privacy-centric re-assessment. Drawing on what we have learned thus far, we need to reexamine CT workflows based on privacy attributes.

7.2. Privacy Properties

As per the CDC’s preliminary criteria for the minimum and preferred characteristics of digital contact tracing tools [62], a qualitative analysis was performed on both individual platforms and on a modular basis. As per the risks and security reviews, general interpretations were provided in addition to security guidelines. Because this set of metrics barely addressed privacy concerns, combined with what we learned from our server models, we reexamined the CT workflows. This is based on more comprehensive and methodical privacy attributes to reveal further model differences, scores, and efficacies. Our privacy-centric re-assessment criteria are as follows:

Ranks (1–4): 4 indicates the highest capability/preference, while 1 is the lowest.

Yes/No: Yes (1), No (0)

PHAs Data Access: How much access do PHAs allow for patients’ PII and exposure to servers?

• Complete
• Need-basis
• Pseudonyms
• Nothing about data

PHAs Access Criteria: On what basis do PHAs allow access to patients’ PII and server exposures?

• No-Consent
• On-demand
• Consent
• Never

PHAs Data Longevity: How long do PHAs allow storing patients’ PII and exposure by servers?

• Permanently
• Until requested to delete
• Few weeks
• Two weeks

PHAs Data Request: Who can request PHAs to allow storing patients’ PII and exposure by servers?

• Nobody
• PHAs
• User
• Both/Either

Users’ risk of Anonymization: Based on users’ PII, exposures, and pseudonyms shared, can a user be vulnerable if servers are compromised?

• Identity reveals if the central server is compromised
• Identity reveals if any server (multiple) is compromised
• Identity reveals if interacted/interacted/another user’s device is compromised
• Identity is revealed only if the user’s device is compromised

The Indexed data model had higher privacy scores than the others regarding privacy capabilities. However, the Bulletin board works almost as well as the indexed data model. Compared with the quality/general attributes assessment in Table 6, the bulletin board model was more effective in controlling diseases and preventive measures. However, in

Table 7. Privacy-Centric Reassessment Criteria for CT Workflows (Privacy Scores). Ordinal scores 1–4 (higher = better) rate workflow elements relevant to privacy (e.g., access criteria, longevity, data requests, risk of de-anonymization).

Attributes	Fully Centralized Model	Subset Data Model	Bulletin Board Model	Indexed Data Model	Dedicated Servers Model	Custodian Data Model
PHAs Data Access	1	2	3	3	2	2
PHAs Access Criteria	1	1	4	4	3	3
PHAs Data Longevity	1	2	4	4	3	3
PHAs Data Request	1	1	4	4	2	2
Users’ Risk of Anonymization	1	1	3	4	4	2
Total	5	7	18	19	14	12

Notes: Gray shading highlights higher scores for quick scanning.

, the indexed data model has higher privacy scores than the others. Overall, based on general and privacy-centric evaluation, the bulletin board outperforms all models with a clear distinction, while the indexed data model stands in the second rank.

7.3. Architectural Comparison: Privacy and Security Trade-Offs

To support a deeper understanding of the design trade-offs in contact tracing platforms, we present a comparison of the six categorized architectural models.

Table 8. Architectural Comparison: Privacy And Security Trade-Offs. Concise, qualitative summary linking each model’s control locus, key risks, privacy level, and strengths to aid design choices.

Model	Control Type	Key Security Risks	Privacy Level	Strengths
Fully Centralized	Government	Single point of failure, mass data breach	Low	Centralized control, full data visibility
Subset Data Model	Government/User Shared	Linkage attacks, limited anonymization	Medium	Partial data isolation, improved privacy over full centralization
Custodian Data Model	User-Controlled	Data integrity issues, potential user mismanagement	High	User maintains control over exposure and health status data
Dedicated Servers	Government/3rd Parties	DoS attacks on segmented servers	High	Segmented risk zones, scalable and resilient infrastructure
Bulletin Board Model	Anonymous Relay Server	Traffic analysis, replay attacks, metadata correlation	Very High	Strong anonymity, public exposure keys without direct identifiers
Indexed Data Model	Mixed Control	Index leakage, possible metadata profiling	Medium-High	Fast retrieval with partial anonymity, balance of privacy and speed

outlines each model’s control type, primary cybersecurity risks, privacy levels, and key strengths. Unlike the binary centralized vs. decentralized classification, our modular approach provides a more practical framework for evaluating system resilience and user trustworthiness.

This comparative overview supports the argument that a modular perspective enables more targeted decision-making for system design. It also illustrates that cybersecurity resilience is tightly coupled with architectural choices, necessitating thoughtful integration of cryptographic protections, data segmentation, and user control models. In terms of our goals, the Bulletin Board model best meets G1 (PII secrecy) and G3 (unlinkability), while Fully Centralized architectures often ease G2 controls (case-verification/notification authenticity) via clearer authority boundaries, explaining the observed Privacy–Security trade-offs.

7.4. Reliability and Robustness Results

Details of the scoring rubric, rater protocol, and analysis are in Section 3.1; the outcomes are reported below. Privacy and security findings are evaluated against goals G1–G3 from Section 3.2.

• Inter-rater reliability (Cohen’s $\mathsf{\kappa }$, macro-average by pillar): Privacy 0.606 (substantial), Security 0.433 (moderate), Governance 0.468 (moderate), Functionality 0.067 (low). The lower $\mathsf{\kappa }$ for Functionality reflects more variable or under-specified public documentation; we clarified functional indicator definitions and cite evidence per indicator in Appendix A.
• Model-level scores (unweighted mean across 24 indicators): Bulletin Board 0.823; Custodian 0.792; Dedicated Servers 0.771; Indexed 0.708; Subset 0.615; Fully Centralized 0.583. A bar chart of model-level scores appears in Figure 7.
• Sensitivity to indicator weights (1000 draws): Using $\mathrm{D}\mathrm{i}\mathrm{r}\mathrm{i}\mathrm{c}\mathrm{h}\mathrm{l}\mathrm{e}\mathrm{t}\left(1,\dots ,1\right)$ weight vectors over the 24 indicators, the Top-1 model changed in 20.5% of draws, while the Top-2 set remained the same in 63.4%. Thus, while exact ordering can shift under alternative priorities, the top tier (Bulletin Board/Custodian) remains robust across a wide range of reasonable weightings. Notation and step details appear in Appendix B (

  Table A7. Symbols and Terms. Standardizes terms for consistent usage across the paper.

  Symbol/Term	Meaning	Used in
  PII	Personally identifiable information (e.g., name, phone, national ID)	Threat model; Privacy indicators
  TempID	Short-lived device pseudonym used for proximity beacons	Centralized/Hybrid models
  TEK	Temporary Exposure Key; seed from which RPIs are derived	GAEN/DP-3T (Bulletin Board)
  RPI	Rolling Proximity Identifier broadcast to nearby devices	GAEN/DP-3T (Bulletin Board)
  Seed	Uplinked value from which observers can recompute RPIs	Bulletin Board/Indexed
  Index	Pointer or reference to server-side data without raw content	Indexed Data model
  PID	Pseudonymous account/device ID used for backend association	Centralized/Subset
  VC	Verification Code bound to a lab result for diagnosis upload	All models with case verification
  Match (local)	On-device risk computation against downloaded data	Decentralized models
  Match (server)	Server-side risk computation against uploaded data	Centralized/Hybrid
  A1/A2/A3	Adversaries: (A1) network attacker, (A2) malicious user, (A3) honest-but-curious backend	Section 3.2 Threat model
  G1–G3	Goals: G1 PII secrecy (public channels); G2 authenticity (verification/notifications); G3 unlinkability (rotating tokens)	Section 3.2; Section 7.4
  P1/P2/S1/S4	Indicators mapping to goals: P1 → G1, P2 → G3, S1/S4 → G2	Section 3.1
  TTL/Retention	Time-to-live/retention window for stored data	Privacy/Governance
  Gateway	Cross-jurisdiction exchange service for keys/alerts	Interoperability

  and Table A8; Procedures B1–B2).
• Security verification status: In this study, we verified architecture-level conformance to G1–G3 under the threat model in Section 3.2 by scoring indicators P1/P2/S1/S4, reporting Cohen’s $\mathsf{\kappa }$ for inter-rater agreement, and stress-testing conclusions with a 1000-draw weight-sensitivity analysis. We contextualized effectiveness with operational KPIs observable in deployments, verification latency (test → code → notification), notification coverage (share rate and percent of exposed contacts notified), susceptibility to false-positive/relay, interoperability, and retention/exit compliance, when such data are available.

7.5. Trends over Time

This study analyzed the protection and privacy of 18 contact-tracing platforms. It ranked the most critical features, such as a specific protocol, cryptographic technique, deployment framework, user identification approach, and role/trust of healthcare officials. Over time, and until December 2022, we examined the changing trends within these platforms regarding architectural shifts under our modular divisions, source code availability, and recent CTA launches. First, in the observations of architectural designs from May 2020 to April 2021, centralized app designs were seen to be more trusted and pioneering. After a few months of app deployment, many security vulnerabilities and privacy concerns came to the surface, and Apple/Google released its API interface on 20 May 2020. Centralized apps for iPhone users were challenging previously because of the way iOS/Apple restricts the use of Bluetooth, which also convinced the developers to shift their approach to fall into line with the decentralized design used by this API, and ended up having more than 65 applications by April 2021, while five shifts within our selected CT platforms. The governments of Germany, Switzerland, Israel, and the USA, for their platforms, Corona-warn-app, SwissCovid-DP3T, DP3T Unlinkable, Hamagen, and EpiOne, respectively, abandoned their centralized databases and shifted to decentralized approaches. This shift further within our architectural subclassification is shown in Figure 8.

Over the same period, quantitative evidence mirrors these shifts. A systematic review (76 studies; 25 meta-analyzed) finds that perceived benefits, trust, and ease-of-use consistently predict DCT acceptance, with cultural context moderating effects; “privacy concerns” alone are not uniformly predictive once other factors are controlled [30,63]. At population scale, the NHS COVID-19 app is estimated to have averted ~1 million cases during its first year [36], while an individual-level analysis in Belgium observed a ~1.2-day delay from PCR result to exposure notification and only ~4% of exposed contacts notified, highlighting cascade bottlenecks [35]. Design choices such as notification-window length also trade off epidemiological impact with adherence [37]. Preference and qualitative studies show willingness to install rises under public-health governance and privacy-preserving defaults, and falls with broad secondary data use; communication, digital-literacy, and transparency barriers further shape uptake [32,33,34]. Taken together, these findings help explain the observed trend toward bulletin-board/custodian architectures (trust/PII-secrecy/unlinkability) while more centralized variants often persisted where verification/authenticity (G2) workflows were prioritized.

We also witnessed other changes; for instance, the French government renamed its formerly introduced app from StopCovid to TousAntiCovid because of its slower adoption rate until July 2020 and updated the app in October. And COVID Safe Paths, an MIT-led project in the USA, was later named the Private Kit. In addition, a few countries had worked on protocols until July 2020. However, later, they launched their applications, such as the EpiOne protocol by UC Berkeley, which deployed its application “epione.net Patients”, version 5.7.0, on 18 March 2021. The German government introduced the “Corona-Warn-App” for its ConTra Corona Protocol on 29 March 2021. Until July 2020, a few protocols/apps’ source codes were not released online; however, until April 2021, the following changes were observed, as illustrated in

Table 9. Source-code releases and GAEN adoption timeline. Per-platform dates for open-source release and switch to GAEN were used to derive Figure 9 and Figure 10.

CT Solutions	Deployed	Source Code Release Date	Switch Date to GAEN API
GAEN APIs	37 Countries (Globally)	20 May 2020	N/A
Health Code	China	×	×
Aarogya Setu	India	June 2020	×
ConTra Corona	Germany	16 June 2020	July 2020
CovidSafe-PACT (West-coast)	USA	Novembre 2020	August 2020
Immuni (Pronto-C2)	Italy	25 May, 2020	1 June, 2020
StopCovid/TousAntiCovid	France	June 2020	×
TraceTogether (OpenTrace)	Singapore	29 March 2020	×
CovidSafe	Australia	8 May 2020	×
SwissCoviD-DP-3T	Switzerland	26 May 2020	June 2020
DP-3T Unlinkable	Europe	April 2020	May 2020
Hamagen	Israel	July 2020	×
Coronavirus Disease-19	South Korea	×	×
CovidWatch–TCN	Arizona, USA	April 2020	August 2020
COVID Safe Paths (Private Kit)	USA	June 2020	August 2020
DESIRE protocol	-	×	N/A
EpiOne	-	×	August 2020
PACT East Coast	-	August 2020

Notes: N/A = not applicable to this row. Examples: GAEN APIs are the underlying framework (not an app), so no “Switch Date to GAEN API”; DESIRE protocol is non-GAEN by design, so no switch date applies.

. Please note that “×” means “Code Not Released Yet,” while “–” means “Switch didn’t happen”.

All platforms under study were seen to release their source code within a month gap or at the same time when they adopted the GAEN API, except the CovidSafe-PACT (West-coast) developed by the University of Washington, USA, made public three months after the shift in November 2020. Its beta version was released in May 2020, shifted to this API-based decentralized approach in August 2020, and later released its source code in November 2020 once it had finished updating and analyzing its recent decentralized system. The overall trends of source code release and GAEN adoption are graphically represented in the sum of platforms out of the 18 CT systems under study, as shown in Figure 9 and Figure 10.

After the release of GAEN APIs on 20 May 2020, most countries adopted this decentralized approach within a month, except for the cluster of applications launched by more than 20 states in the USA, such as CovidSafe–PACT, CovidWatch, CovidSafe paths, and EpiOne, which shifted their architecture in August 2020 after analyzing its suitability and the API-based system, while the majority of others have already shifted earlier.

Looking ahead to future digital-health systems and other privacy-preserving applications, our two architectural axes, locus of risk processing (device vs. server) and data addressability (recomputable vs. addressable records), remain applicable and adapt to new technologies and evolving public-health needs. IoT: proximity beacons, wearables, and venue sensors fit Bulletin-Board or Custodian patterns to keep PII off public channels while enabling local matching; gateways support cross-site federation under minimization (G1/G3). Cloud: when timeliness, fraud control, or case-management integration dominates, Dedicated-Servers or Hybrid variants centralize only what is necessary to satisfy G2 (authenticity) while retaining scoped uploads, verified diagnosis codes, and role separation. Blockchain: append-only bulletin boards (e.g., permissioned ledgers) can provide publication/audit for diagnosis keys or revocations without putting PII on-chain; pairing with verifiable credentials, PSI/PIR, and threshold/attested issuance preserves unlinkability (G3) and secrecy (G1). As technologies and public-health needs evolve, the classification remains useful because it exposes trade-offs explicitly, allowing authorities to choose implementations that meet G1–G3 under local constraints rather than defaulting to a binary centralized–decentralized view.

8. Conclusions

Digital contact tracing (CT) plays a pivotal role in mitigating pandemics by identifying and interrupting chains of transmission. However, CT platforms vary significantly in their privacy architectures, and the traditional centralized–decentralized dichotomy fails to capture this diversity. To address this, we introduced a modular six-model classification that makes these architectural trade-offs explicit.

We evaluated 18 platforms across 12 countries using a structured, 24-indicator rubric, capturing changes in design, privacy models, and adoption signals over time. This evidence-based comparison highlights how architecture relates to privacy, security, and operational choices.

Our findings show that no CT platform offers complete protection against all privacy threats. Bulletin Board and Custodian models generally form the top tier of privacy goals, while more centralized designs ease verification/notification workflows. Following GAEN’s release, several deployments shifted toward more privacy-preserving designs, and transparency measures (open-source code, minimal data collection, clear governance) correlated with higher acceptance across regions.

Greater feature complexity did not guarantee adoption. Platforms prioritizing simplicity, user control, and privacy transparency fared better, and many systems adapted post-launch in response to public feedback and regulatory pressure, underscoring the value of responsiveness. Non-technical factors, such as institutional trust, communication, and perceptions of surveillance, also influenced outcomes.

The six-model lens clarifies how compute locus and data addressability interact with privacy, functionality, and control. Beyond COVID-19, the framework generalizes to future digital-health settings, supporting privacy-first designs aligned with data-protection principles.

This study underscores the importance of embedding privacy-by-design into digital health platforms. Governments and health authorities must not treat privacy as a trade-off but as a strategic enabler of trust and cooperation. By implementing robust encryption, data minimization, anonymization, and transparent governance, CT systems can ensure both public safety and individual rights. In doing so, they can increase participation, enhance effectiveness, and strengthen collective efforts to control the spread of infectious diseases, now and in the future.

Implications: The six-model lens and 24-indicator rubric translate into concrete deployment choices, compute-locus, data addressability, and governance controls that align implementations with G1–G3 and remain applicable beyond COVID-19.

Limitations: Our evaluation relies on publicly documented behavior and artifacts, which vary in depth and currency across jurisdictions; inter-rater agreement was substantial for privacy but lower for functionality; and the reliability check used a representative subset of platforms. Baseline aggregation is unweighted by design; we mitigate weight subjectivity with a 1000-draw sensitivity analysis, but alternative stakeholder weights may reorder close models. We verified architecture-level properties under the stated threat model rather than providing machine-checked protocol proofs or user-level field trials.

Future research: Formal verification of goals G1–G3 under Section 3.2 threat model (e.g., ProVerif/Tamarin) can be a next step, alongside expanded double-coding on a larger platform set, stakeholder-weighted MCDA (Multi-Criteria Decision Analysis) to reflect policy priorities, and longitudinal measurement of operational KPIs (verification latency, notification coverage, false-positive/relay susceptibility, interoperability, retention/exit). Pilot applications in adjacent domains (e.g., IoT beacons and wearables, cloud-integrated case management, and blockchain-backed auditability using verifiable credentials/PSI/PIR) can further validate how the classification guides design under evolving public-health needs.