Building a Privacy Web with SPIDEr -- Secure Pipeline for Information De-Identification with End-to-End Encryption

Abhay Sharma; Abhilash Venkatesh; Anshoo Tandon; Bryan Paul Robert; Hari Dilip Kumar; Kailash Reddy; Kaushal Kirpekar; Novoneel Chakraborty

REVIEW 4 major objections 4 minor 17 references

Building a Privacy Web with SPIDEr -- Secure Pipeline for Information De-Identification with End-to-End Encryption

T0 review · 4 major / 4 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read SPIDEr claims that a trusted execution environment can run de-identification end-to-end so the service provider never sees raw plaintext records.

desk verdict A clearly written design sketch for a TEE-backed de-identification pipeline, but with no evaluation and a trust model that does not support the central end-to-end encryption claim. read the letter →

arxiv 2412.09222 v1 pith:TJ2UPROA submitted 2024-12-12 cs.CR cs.ITmath.IT

Novoneel Chakraborty , Anshoo Tandon , Kailash Reddy , Kaushal Kirpekar , Bryan Paul Robert , Hari Dilip Kumar , Abhilash Venkatesh , Abhay Sharma This is my paper · ORCID

classification cs.CRcs.ITmath.IT

keywords trustedexecutionenvironmentdatade-identificationdifferentialprivacyk-anonymityremoteattestationend-to-endencryptionSEV-SNPconfidentialcomputing

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

SPIDEr is a proposed and deployed pipeline for de-identifying sensitive data in the cloud so that the party running the de-identification service never sees the raw records. The paper claims end-to-end encryption by establishing an encrypted link between the data owner and a trusted execution environment (TEE), and argues that decrypting and processing data inside the TEE preserves data privacy through hardware memory isolation. Within that enclave, SPIDEr supports classical techniques (suppression, pseudonymisation with SHA-256, generalisation, aggregation), k-anonymisation via the ARX tool, and differential privacy with a Laplace mechanism, including a batch-processing mode intended to improve performance on constrained TEE hardware. The central design contribution is the attested control flow: a remote attestation step verifies that the VM runs the correct software on trusted hardware, after which encrypted data is released to the enclave and only de-identified outputs are returned. If the security claim holds, the pipeline would let a data owner gain useful anonymised or differentially private releases without trusting the application provider or the cloud operator.

What carries the argument

The load-bearing mechanism is the attested TEE control flow: an AMD SEV-SNP confidential virtual machine provides hardware memory encryption and isolation, and a guest-attestation service (Azure Attestation) verifies the VM's configuration and PCR values, returning a JWT that an access-policy domain checks before a resource access token is minted. Hybrid encryption secures data at rest, TLS secures data in transit, and SHA-256 hashing supports pseudonymisation. For privacy, the pipeline uses the ARX tool for $k$-anonymisation and the Laplace mechanism $M(D)=f(D)+Z$ with $Z\sim\mathrm{Lap}(\Delta f/\varepsilon)$ for differential privacy; the batch-processing extension computes the noisy query on batches so that large datasets can be handled on the limited memory of the enclave.

What would settle it

A concrete test would be to run the control flow against an adversarial setup and attempt to (a) replay a valid attestation JWT from a VM with modified PCR values, (b) substitute a different or misconfigured VM after attestation, or (c) steal the resource access token and request the encrypted dataset; if raw plaintext is obtainable in any of these attempts, the end-to-end encryption claim is false. A separate check would be to run the batched differential-privacy mechanism on two neighbouring datasets and verify that the released output distribution satisfies the stated $\varepsilon$-DP inequality for all outputs.

Watch

Extended reading notes

Core claim

The paper's central claim is that a practical end-to-end encrypted de-identification pipeline can be built by running the anonymisation software inside an AMD SEV-SNP confidential VM and gating data release on remote attestation. In the proposed control flow, the data provider requests a run, the enclave generates a hardware report, a guest-attestation service verifies the VM configuration and platform configuration registers and issues a JSON Web Token, an access-policy domain validates that token, and only then is a resource access token issued that allows encrypted raw data to flow to the enclave. The provider's plaintext is decrypted and processed only inside the TEE, and the output is re-encrypted before leaving. The pipeline offers both k-anonymisation (implemented with ARX) and $\varepsilon$-differential privacy (implemented with the Laplace mechanism of Dwork et al.), and the paper asserts that its batch-processing mode preserves the formal differential-privacy guarantee while improving performance on constrained TEE hardware.

Load-bearing premise

The load-bearing premise is that the attestation and token-exchange flow can actually ensure that raw plaintext is decrypted and processed only inside a genuine, correctly configured SEV-SNP VM, because the paper presents this flow without a formal adversarial model, a proof, or security tests.

Editorial extensions

If this is right

If the attestation and token-exchange flow is sound, a data owner can share sensitive records with a cloud de-identification service without the service provider, the cloud operator, or an attacker who breaches them being able to read the raw data.
The same attested-enclave design can be extended to other cloud providers that offer confidential VMs with guest attestation, since the paper states the flow is extensible beyond the specific attestation service used.
Users of the pipeline can choose between a $k$-anonymised table release and a noisy differential-privacy query release, and can tune the privacy budget $\varepsilon$ with an accompanying mean-absolute-error graph to make the privacy-utility trade-off explicit.
Batch processing of differential privacy would allow privacy-preserving query answering on datasets larger than what the TEE memory could hold in a single pass, if the asserted guarantee is preserved.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

An implication the paper leaves implicit is that the end-to-end security guarantee rests entirely on the attestation and token-exchange flow; the paper offers no formal adversarial model or proof, so a rigorous security analysis of the numbered control-flow steps is the natural next step.
The paper asserts that batch processing preserves the differential-privacy guarantee without proof; a testable extension would be to verify that the batched noisy mechanism still satisfies the stated $\varepsilon$-DP inequality for every pair of neighbouring datasets and all possible outputs.
Extending the design to multiple data owners sharing one enclave would require a multi-party key-management and attestation scheme, which the current single-owner-to-enclave link does not cover.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

You should know two things about this paper. First, it is a design description, not a demonstrated system: it combines ARX for k-anonymity, the Laplace mechanism for differential privacy, Azure Attestation for SEV-SNP, and hybrid encryption, and it spells out an eleven-step control flow. Second, the central contribution — that the de-identification provider never sees raw data — is not actually supported by the described flow.

What the paper does well: it is clearly structured and reads as a plausible engineering blueprint. The attestation steps are concrete, the use of standard formal privacy tools is correctly cited, and the authors are honest that Theorem 1 is a known result. The support for both item-level and user-level privacy is a nice touch, even if it comes from their own prior work. The writing is plain and the figures seem purposeful.

Where it falls down is the evidentiary bar. There are no experiments, no performance numbers, no correctness tests, no security analysis, and no code artifacts. The only mathematical content is a restatement. The brief mention of batch processing for DP is a real soft spot: no detail is given on how batching interacts with composition, and it is easy to break the formal guarantee that way.

The deeper problem is the trust model, and here the stress-test note lands squarely. The paper says the Enclave Manager, Auth Server, and Access Policy Domain are custom modules, but it never says who controls them or what trust assumptions they carry. In a realistic deployment, the provider offering the de-identification service would operate those modules. If so, that provider can mint a Resource Access Token for its own VM, reload the data via the Resource Server, or simply approve a rogue attestation report. The data owner never directly verifies the VM's public key; they initiate a request and later receive output. Contribution 1 — that the service provider cannot access raw data — is therefore unsupported without an explicit threat model that places these modules outside the TCB or cryptographically pins the VM key to the owner-approved attestation. No such mechanism is described.

Who is this for? Practitioners building a similar TEE pipeline might find the control flow a useful starting point, but as a research submission it is too thin. I would not send this to peer review in its current form; it needs a stated adversarial model, a clear trust boundary, and at least a minimal evaluation. Desk reject, with encouragement to resubmit after adding substance.

Referee Report

4 major / 4 minor

Summary. The paper proposes SPIDEr, a de-identification pipeline that combines classical anonymization techniques (suppression, pseudonymisation, generalisation, aggregation) with k-anonymisation and differential privacy, executed inside an AMD SEV-SNP Trusted Execution Environment. The core contribution is a control-flow design for end-to-end encryption between a data owner and the TEE, using Microsoft Azure Attestation to verify the VM and a chain of custom modules (Auth Server, Access Policy Domain, Enclave Manager) to grant data access. The paper claims that the de-identification service provider never sees raw data and that the system has been deployed on the cloud, with batch processing of differential privacy queries to improve scalability.

Significance. If the claims were substantiated, SPIDEr would be a useful practical blueprint for confidential de-identification: the DP definition and Theorem 1 are standard and correctly cited, the choice of SEV-SNP and Azure Attestation is plausible, and the explicit goal of keeping raw data away from the service provider is well-motivated. However, the manuscript as submitted is an architectural sketch without experimental evidence, security analysis, or correctness tests, and the described control flow contains a trust gap that is load-bearing for the central privacy claim. The potential practical value is therefore not yet demonstrable from the paper itself.

major comments (4)

[Section III, items 5–9] The end-to-end encryption claim depends on trust assumptions that the paper never states. The JWT from Azure Attestation is verified by the Access Policy Domain (APD), the Resource Access Token is generated by the Auth Server (AS), and the Enclave Manager relays the token to the data resource. The paper calls these 'custom modules' but does not say who operates them or whether they are inside or outside the TCB. In a realistic deployment, the service provider would run these modules; a malicious or compromised provider could have AS issue a RAT for an attacker-controlled VM, have Enclave Manager redirect the RAT, or simply approve a forged attestation report if APD is coerced. This directly invalidates Contribution 1 ('the entity providing the de-identification service itself does not get to access the raw, unencrypted data'). The manuscript needs an explicit adversary model and a clear statement of which components are trusted and why; without that, the central security claim is unsupported.
[Sections I and II (overall evaluation)] The paper claims a working, deployed implementation (Contribution 4) and describes concrete functionality such as the web UI, ARX-based k-anonymisation, MAE-versus-epsilon graphs, and docker images, but provides no experimental results, no correctness tests, no performance measurements, and no evidence of deployment. There are no screenshots, no dataset descriptions, no runtime numbers, and no verification that the k-anonymised output actually satisfies k-anonymity or that the DP output meets the claimed privacy guarantee. As a systems paper, this absence of evaluation means the central claim of a functional SPIDEr pipeline is not established.
[Section II-B (batch differential privacy)] The paper says that 'we enable batch processing of data for differential privacy computations' (Contribution 2) but never defines what batch processing means, how the Laplace mechanism is applied to batches, or how the privacy budget is accounted for across multiple queries or records. A naive application of Theorem 1 to batched outputs would not automatically preserve ε-DP under composition; the paper gives no sensitivity analysis for batched queries and no proof that the batch mode satisfies the stated formal guarantee. This is load-bearing for Contribution 2, and the omission is not merely a presentation issue.
[Section II-B (privacy definition)] The DP definition in Section II-B is written generically over 'neighbouring datasets' but the paper later remarks that SPIDEr supports both item-level and user-level privacy, citing reference [14]. The neighboring relation is never formalized for either case, and no argument is given for how the Laplace mechanism with sensitivity Δf applies to user-level privacy, where the contribution of a single user can affect multiple rows. Without this formalization, the claim that SPIDEr provides a formal privacy guarantee for user-level privacy is not supported by the text.

minor comments (4)

[Section II-A] The text mentions 'open APIs provided by ARX' but does not specify which ARX version or interface is used; adding a direct reference to the ARX tool documentation would help reproducibility.
[Section III, item 10] The word 'inference' is used to describe the de-identification output in the Enclave Manager description; 'result' or 'output' would be clearer.
[Abstract and Section II] The web-based user interface is claimed but no figure, screenshot, or description of its configuration workflow is provided, which would make the system description more concrete.
[Throughout] Some technical terms are used imprecisely, such as 'separation kernel' in Section I, without a citation or definition; a brief clarification would help the reader.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: SPIDEr's central claims rest on external TEE, attestation, and standard DP results, not on its own outputs or self-citations.

full rationale

The paper contains no derivation chain in which a predicted quantity is equivalent to an input by construction. There are no fitted parameters, no post-hoc normalizations, and no uniqueness theorem invoked to force a choice. The central end-to-end encryption claim is an architectural assertion supported by AMD SEV-SNP hardware isolation and Microsoft Azure Attestation (Sections III, items 1-11), both cited as external infrastructure. The differential privacy guarantee is imported from Dwork et al. (ref [13]) via Theorem 1, and k-anonymisation is implemented using the external ARX tool (ref [12]); neither is derived from the paper's own assumptions. The only self-citation is ref [14], used to state that SPIDEr supports user-level differential privacy in addition to item-level privacy. That reference is not load-bearing: the paper's core security claim about encrypted communication between the data owner and the TEE does not depend on it, and removing it would not change any stated result or control flow. The paper's batch-processing claim for differential privacy is asserted without a formal proof of the composition or privacy amplification properties, but an unsupported or insufficiently justified claim is a correctness or completeness risk, not circularity under the stated rules. Accordingly, no specific circular step can be quoted, and the appropriate finding is no significant circularity with score 0.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The central claim relies on the correctness of external hardware and software components (SEV-SNP, Azure Attestation, ARX, standard DP mechanisms), all taken as given without independent verification in this paper. No new mathematical objects or free parameters are introduced.

assumptions (3)

domain assumption The AMD SEV-SNP TEE provides the claimed hardware-level confidentiality and integrity guarantees.
The security of the pipeline depends on the hardware's trustworthiness, assumed in Section III without analysis.
domain assumption Azure Attestation correctly verifies the guest firmware and PCR values and issues a valid JWT.
The attestation flow (items 2-7) relies on the correctness of MAA; no adversarial model is provided.
domain assumption The integration of ARX's k-anonymity implementation and the Laplacian mechanism correctly implements the formal definitions.
The paper invokes Theorem 1 and ARX [12] without testing or formal verification.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Building a Privacy Web with SPIDEr -- Secure Pipeline for Information De-Identification with End-to-End Encryption." pith.science (2026). https://pith.science/paper/TJ2UPROA

@misc{pith2026241209222,
  author       = {Pith},
  title        = {Pith review of: Building a Privacy Web with SPIDEr -- Secure Pipeline for Information De-Identification with End-to-End Encryption},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/TJ2UPROA}},
  note         = {Machine review of arXiv:2412.09222}
}

read the original abstract

Data de-identification makes it possible to glean insights from data while preserving user privacy. The use of Trusted Execution Environments (TEEs) allow for the execution of de-identification applications on the cloud without the need for a user to trust the third-party application provider. In this paper, we present \textit{SPIDEr - Secure Pipeline for Information De-Identification with End-to-End Encryption}, our implementation of an end-to-end encrypted data de-identification pipeline. SPIDEr supports classical anonymisation techniques such as suppression, pseudonymisation, generalisation, and aggregation, as well as techniques that offer a formal privacy guarantee such as k-anonymisation and differential privacy. To enable scalability and improve performance on constrained TEE hardware, we enable batch processing of data for differential privacy computations. We present our design of the control flows for end-to-end secure execution of de-identification operations within a TEE. As part of the control flow for running SPIDEr within the TEE, we perform attestation, a process that verifies that the software binaries were properly instantiated on a known, trusted platform.

Figures

Figures reproduced from arXiv: 2412.09222 by the authors.

**Figure 2.** Control flows between various entities of the SPIDEr framework, with [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

17 extracted references · 10 canonical work pages

[14]

Gupta, V

P. Gupta, V . A. Rameshwar, A. Tandon and N. Chakraborty, ”Mean Estimation with User-Level Privacy for Spatio-Temporal IoT Datasets,” SPCOM-2024, doi: 10.1109/SPCOM60851.2024.10631607

arXiv 2024
[1]

Anonymization Techniques for Privacy Preserv- ing Data Publishing: A Comprehensive Survey,

A. Majeed and S. Lee, “Anonymization Techniques for Privacy Preserv- ing Data Publishing: A Comprehensive Survey,” IEEE Access, vol. 9, pp. 8512–8545, 2021, doi: 10.1109/ACCESS.2020.3045700

arXiv 2021
[2]

Exposed! A survey of attacks on private data,

C. Dwork, A. Smith, T. Steinke, and J. Ullman, “Exposed! A survey of attacks on private data,” Annu. Rev. Stat. Its Appl., vol. 4, no. December, pp. 61–84, 2017, doi: 10.1146/annurev-statistics-060116-054123

doi:10.1146/annurev-statistics-060116-054123 2017
[3]

Anonymization: The imperfect science of using data while preserving privacy,

A. Gadotti, L. Rocher, F. Houssiau, A. M. Cret ¸u, and Y . A. de Montjoye, “Anonymization: The imperfect science of using data while preserving privacy,” Sci. Adv., vol. 10, no. 29, p. eadn7053, 2024, doi: 10.1126/sciadv.adn7053

doi:10.1126/sciadv.adn7053 2024
[4]

The 2010 Census Confidentiality Protections Failed, Here’s How and Why,

J. Abowd et al., “The 2010 Census Confidentiality Protections Failed, Here’s How and Why,” SSRN Electron. J., 2023, doi: 10.2139/ssrn.4675183

work page doi:10.2139/ssrn.4675183 2010
[5]

De- identifying government datasets:,

S. Garfinkel, J. Near, A. Dajani, P. Singer, and B. Guttman, “De- identifying government datasets:,” 2023. doi: 10.6028/NIST.SP.800-188

doi:10.6028/nist.sp.800-188 2023
[6]

Government of India, Digital Personal Data Protection Act 2023, no. Dl. New Delhi: Ministry of Law and Justice, 2023, p. 21. [Online]. Available: https://www.meity.gov.in/writereaddata/files/Digital Personal Data Protection Act 2023.pdf

work page 2023
[7]

No free lunch in data privacy,

D. Kifer and A. Machanavajjhala, “No free lunch in data privacy,” Proc. ACM SIGMOD Int. Conf. Manag. Data, pp. 193–204, 2011, doi: 10.1145/1989323.1989345

arXiv 2011

Show all 17 references

[8]

A model for protecting privacy,

L. Sweeney, “A model for protecting privacy,” Ieee S&P ’02, vol. 10, no. 5, pp. 1–14, 2002, [Online]. Available: https://tinyurl.com/8euzm7s5

2002
[9]

Trusted Ex- ecution Environments: Applications and Organizational Challenges,

T. Geppert, S. Deml, D. Sturzenegger, and N. Ebert, “Trusted Ex- ecution Environments: Applications and Organizational Challenges,” Front. Comput. Sci., vol. 4, no. July, pp. 1–6, 2022, doi: 10.3389/fcomp.2022.930741

2022
[10]

Protecting Sensitive Data with Secure Data Enclaves,

M. Howison, M. Angell, and J. S. Hastings, “Protecting Sensitive Data with Secure Data Enclaves,” Digit. Gov. Res. Pract., vol. 5, no. 2, 2024, doi: 10.1145/3643686

2024 doi
[11]

Trusted execution envi- ronment: What it is, and what it is not,

M. Sabt, M. Achemlal, and A. Bouabdallah, “Trusted execution envi- ronment: What it is, and what it is not,” Proc. - 14th IEEE Int. Conf. Trust. Secur. Priv. Comput. Commun. Trust. 2015, vol. 1, pp. 57–64, 2015, doi: 10.1109/Trustcom.2015.357

2015 doi
[12]

Highly efficient optimal K-anonymity for biomedical datasets,

F. Kohlmayer, F. Prasser, C. Eckert, A. Kemper, and K. A. Kuhn, “Highly efficient optimal K-anonymity for biomedical datasets,” 2012. doi: 10.1109/CBMS.2012.6266366

2012
[13]

Calibrating Noise to Sensitivity in Private Data Analysis

C. Dwork, F. McSherry, K. Nissim, A. Smith, “Calibrating Noise to Sensitivity in Private Data Analysis”, In TCC 2006

2006
[15]

The Evaluation Report of SHA- 256 Crypt Analysis Hash Function,

A. L. Selvakumar and C. S. Ganadhas,“The Evaluation Report of SHA- 256 Crypt Analysis Hash Function,” 2009 International Conference on Communication Software and Networks, doi: 10.1109/ICCSN.2009.50

2009 doi
[16]

AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More,

“AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More,” Jan. 2020. Accessed: Oct. 21, 2024. [Online]. Available: www.amd.com/content/dam/amd/en/documents/epyc- business-docs/solution-briefs/amd-secure-encrypted-virtualization- solution-brief.pdf

2020
[17]

Azure Attestation overview,

“Azure Attestation overview,” Aug. 2024. Accessed: Oct. 21, 2024. [On- line]. Available: learn.microsoft.com/en-us/azure/attestation/overview

2024

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.

[1] [14]

Gupta, V

P. Gupta, V . A. Rameshwar, A. Tandon and N. Chakraborty, ”Mean Estimation with User-Level Privacy for Spatio-Temporal IoT Datasets,” SPCOM-2024, doi: 10.1109/SPCOM60851.2024.10631607

arXiv 2024

[2] [1]

Anonymization Techniques for Privacy Preserv- ing Data Publishing: A Comprehensive Survey,

A. Majeed and S. Lee, “Anonymization Techniques for Privacy Preserv- ing Data Publishing: A Comprehensive Survey,” IEEE Access, vol. 9, pp. 8512–8545, 2021, doi: 10.1109/ACCESS.2020.3045700

arXiv 2021

[3] [2]

Exposed! A survey of attacks on private data,

C. Dwork, A. Smith, T. Steinke, and J. Ullman, “Exposed! A survey of attacks on private data,” Annu. Rev. Stat. Its Appl., vol. 4, no. December, pp. 61–84, 2017, doi: 10.1146/annurev-statistics-060116-054123

doi:10.1146/annurev-statistics-060116-054123 2017

[4] [3]

Anonymization: The imperfect science of using data while preserving privacy,

A. Gadotti, L. Rocher, F. Houssiau, A. M. Cret ¸u, and Y . A. de Montjoye, “Anonymization: The imperfect science of using data while preserving privacy,” Sci. Adv., vol. 10, no. 29, p. eadn7053, 2024, doi: 10.1126/sciadv.adn7053

doi:10.1126/sciadv.adn7053 2024

[5] [4]

The 2010 Census Confidentiality Protections Failed, Here’s How and Why,

J. Abowd et al., “The 2010 Census Confidentiality Protections Failed, Here’s How and Why,” SSRN Electron. J., 2023, doi: 10.2139/ssrn.4675183

work page doi:10.2139/ssrn.4675183 2010

[6] [5]

De- identifying government datasets:,

S. Garfinkel, J. Near, A. Dajani, P. Singer, and B. Guttman, “De- identifying government datasets:,” 2023. doi: 10.6028/NIST.SP.800-188

doi:10.6028/nist.sp.800-188 2023

[7] [6]

Government of India, Digital Personal Data Protection Act 2023, no. Dl. New Delhi: Ministry of Law and Justice, 2023, p. 21. [Online]. Available: https://www.meity.gov.in/writereaddata/files/Digital Personal Data Protection Act 2023.pdf

work page 2023

[8] [7]

No free lunch in data privacy,

D. Kifer and A. Machanavajjhala, “No free lunch in data privacy,” Proc. ACM SIGMOD Int. Conf. Manag. Data, pp. 193–204, 2011, doi: 10.1145/1989323.1989345

arXiv 2011