Safety Without Surveillance: Engineering Alternatives to Cognitive Monitoring

Full report

On this page

When a safety objective can be achieved without retaining identity-linked inquiry data, what legitimate justification remains for collecting that data? For decades, the digital economy and enterprise security infrastructures have operated under a foundational assumption: the mitigation of fraud, abuse, and security threats requires continuous, centralized surveillance of user behavior. This paradigm, which can be summarized as "collect everything, promise restraint," insists that safeguarding platforms necessitates the perpetual retention of identity-linked behavioral data. The resulting accumulation of cognitive monitoring data—records detailing what individuals read, search, ask, write, and believe—creates profound vulnerabilities. The premise that surveillance is a strict technical prerequisite for safety is demonstrably false. Through the application of cryptographic protocols, distributed computing, and hardware-enforced isolation, the architecture of the internet can be fundamentally redesigned. It is entirely feasible to decouple platform safety from user surveillance, creating environments that protect users from genuine harm without centralized tracking.

Part 1: The Threat Model of Cognitive Surveillance

The "collect everything, promise restraint" design pattern treats data accumulation as a neutral act, protected by privacy policies and access controls. However, centralized data repositories invariably become toxic assets. When a system retains plaintext, identity-linked data, it faces a multi-dimensional threat landscape that cannot be mitigated by policy alone. Architectures must instead rely on technical prevention, ensuring that data is mathematically or physically inaccessible. The threat of hostile governments and subpoena pressure is perhaps the most immediate risk to centralized data. Under the third-party doctrine, as challenged but largely preserved in legal precedents such as Carpenter v. United States, data voluntarily surrendered to third-party service providers generally loses strict constitutional privacy protections, leaving it vulnerable to warrantless extraction or loosely supervised state surveillance1. Authoritarian regimes frequently weaponize centralized records of search queries, reading habits, and geolocation data to identify and suppress dissidents, journalists, and marginalized groups. Conversely, systems designed with cryptographic non-possession—where providers hold "no logs" of user activity—render subpoenas mathematically ineffective, as demonstrated by platforms relying on end-to-end encryption (E2EE) which issue non-possession affidavits in response to legal demands4. Malicious insiders and data breaches represent persistent operational threats. Massive databases of queries and behavioral biometrics are prime targets for external exfiltration, but they are equally vulnerable to employees with administrative access. Insider threats have repeatedly abused centralized databases for corporate espionage, unauthorized tracking, and personal stalking. When identity and content are stored together in plaintext, a single point of failure compromises millions of users. Furthermore, data collected under the guise of security is routinely subjected to corporate acquisition and future policy expansion. A dataset generated for diagnostic telemetry or fraud prevention is frequently repurposed following mergers, acquisitions, or shifts in executive strategy. This function creep often transforms localized security telemetry into expansive behavioral advertising profiles or training corpuses for machine learning models, violating the initial context of the data collection. Technical prevention architectures solve these threat models by relying on mathematics rather than organizational promises.

Part 2: Technologies for Decoupling Safety from Surveillance

Achieving safety without cognitive monitoring requires an orchestrated combination of network protocols, cryptographic proofs, and hardware isolation. These mechanisms separate the identity of the user from the content of their request, and decouple the verification of an attribute from the disclosure of the underlying data.

Network and Routing Architectures

Standard network protocols inherently link identity and content. In a traditional HTTPS request, the encryption protects the payload from network observers, but the destination server receives both the plaintext request and the client's IP address (identity metadata)6. Oblivious HTTP (OHTTP), standardized as RFC 9458, severs this link by routing traffic through two independent, non-colluding nodes: an Oblivious Relay and an Oblivious Gateway6. The client utilizes Hybrid Public Key Encryption (HPKE), such as the DHKEM(X25519, HKDF-SHA256) cipher suite, to seal the HTTP request so that only the Gateway possesses the private key required to decrypt it9. The client sends this encrypted payload to the Relay. The Relay observes the client's IP address but cannot read the encrypted payload, forwarding it opaquely to the Gateway6. The Gateway decrypts the payload and processes the request (or forwards it to a target resource), but it only observes the IP address of the Relay, possessing no knowledge of the end-user's identity8. This split-trust architecture guarantees metadata privacy, provided the Relay and Gateway operators do not collude to cross-correlate IP addresses with decrypted requests8. End-to-End Encryption (E2EE) serves as the baseline for preventing network and service-provider surveillance, limiting access to communications content strictly to the communicating parties14. In environments where E2EE is deployed, ephemeral request handling ensures that intermediate routing servers process message metadata statelessly. Once a query is processed, all associated memory states are purged. This involves configuring microservices to operate statelessly, often utilizing secure memory enclaves that cryptographically guarantee memory is wiped upon thread termination, preventing forensic recovery of transient data by advanced persistent threats.

Information Retrieval and Intersection

To conduct threat detection without revealing user data to a central authority, systems utilize advanced querying protocols. Private Information Retrieval (PIR) enables a client to retrieve a specific record from a server's database without the server learning which record was requested. Advanced PIR implementations, such as Spiral and FastPIR, utilize homomorphic encryption to achieve this ambiguity15. The server mathematically processes the query against the entire database, returning an encrypted result that only the client can decrypt. While PIR provides exceptional privacy, it often entails significant computational and bandwidth overhead, though recent optimizations are lowering these barriers15. Private Set Intersection (PSI) offers a secure multi-party computation technique allowing two parties to compute the intersection of their data sets without revealing any elements outside the intersection18. PSI is highly effective for checking local data against a server-side blacklist—such as breached passwords or malware signatures—without exposing the user's uncompromised data to the server, or exposing the server's proprietary blacklist to the user19. Fuzzy PSI extends this logic to perceptual hashes, allowing for approximate matching of media files to account for compression or minor alterations, an essential tool for detecting illegal content without scanning non-matching personal files20.

Verification, Credentials, and Identity

Modern credential architectures allow users to prove necessary attributes without persistent identity tracking. Selective disclosure protocols permit an individual to hold a rich digital credential but reveal only specific, necessary attributes to a verifier. Selective Disclosure for JSON Web Tokens (SD-JWT), defined in RFC 9901, achieves this by allowing an issuer to hash individual JSON claims with unique, cryptographically secure random salts22. The holder presents the signed JWT to a verifier alongside only the specific salts and claims they wish to disclose, while all other claims remain hidden as unrecognizable hashes22. For stronger privacy guarantees, architectures employ Zero-Knowledge Proofs (ZKPs) via BBS+ signatures. The W3C Verifiable Credentials Data Integrity BBS Cryptosuite (VC-DI-BBS) utilizes pairing-based elliptic-curve cryptography to enable multi-show unlinkability25. Unlike SD-JWT, where repeated disclosures of the same credential might be correlated by colluding verifiers, BBS+ allows the holder to generate unique, randomized cryptographic proofs for each presentation28. A user can prove the predicate "Age \> 18" without revealing their birthdate, and can do so across fifty different websites without those websites being able to link the cryptographic signatures back to a single user25. To prevent volumetric abuse such as bot floods or DDoS attacks without tracking user identities, platforms deploy anonymous credentials. Protocols like Privacy Pass (RFC 9576\) and Anonymous Rate Limit Credentials (ARC) decouple the attestation of humanity from the execution of a request31. Using Blind RSA or Verifiable Oblivious Pseudorandom Functions (VOPRF), a trusted attester provides a blind signature to a client that proves they passed an anti-abuse check33. The client can later redeem these Private Access Tokens to bypass rate limits or CAPTCHAs on other services, completely anonymously34. For scenarios requiring a deterrence against severe abuse in anonymous networks, abuse-resistant pseudonymity mechanisms like Traceable Ring Signatures are utilized. These signatures provide unconditional anonymity that can only be pierced by a decentralized, threshold-based quorum of auditors if a cryptographic abuse threshold is definitively breached36.

Telemetry, Analytics, and Distributed Aggregation

Software vendors legitimately require telemetry to evaluate system health, yet centralized telemetry collection invariably creates surveillance histories. The Distributed Aggregation Protocol (DAP) and Verifiable Distributed Aggregation Functions (VDAFs) allow vendors to collect rich analytics without ever seeing an individual user's data38. Under VDAF systems like Prio3 (for counts and sums) and Poplar1 (for heavy-hitters), a client's telemetry payload is secret-shared into multiple cryptographic pieces38. These shares are distributed to distinct, non-colluding Aggregator servers. Crucially, VDAFs incorporate zero-knowledge proofs (FLPs) allowing Aggregators to verify that the secret-shared data is well-formed (e.g., that a client is not submitting a maliciously large number to skew the sum) without revealing the data itself38. Each Aggregator sums its shares independently. Only when the Aggregators combine their macroscopic results can the final telemetry be decrypted. No single party ever holds the plaintext of an individual user's telemetry38. Differential Privacy (DP) provides a rigorous mathematical guarantee against re-identification by adding calibrated statistical noise to datasets. In Local Differential Privacy (LDP), the noise is injected directly on the user's device before transmission, governed by a privacy budget (epsilon, [Figure omitted from source export])44. While LDP offers the strongest guarantee against individual identification, it inherently damages the data's utility, requiring vast sample sizes to extract meaningful signal from the noise46. Central Differential Privacy, which relies on a trusted curator to add noise post-collection, violates the strict non-collection mandate of cognitive privacy and is therefore rejected in this blueprint44. Federated learning redefines machine learning by pushing model training down to the local device. The device trains a localized model on local data, and only the mathematically abstracted model weights (gradients) are uploaded to a central server. When combined with Secure Aggregation, the server averages the gradients from thousands of devices simultaneously, ensuring the server cannot reverse-engineer individual training data from the uploaded weights, facilitating recommendation quality and search personalization without cognitive monitoring.

Hardware Enforcement and Verifiable Deletion

Software guarantees are only as reliable as the hardware executing them. Local and on-device processing via neural processing units (NPUs) enables local threat detection and user-controlled filtering without any data leaving the device. For workloads that exceed edge computing capacities, architectures like Apple's Private Cloud Compute (PCC) extend device-level hardware isolation to the cloud47. PCC utilizes custom silicon featuring a Secure Enclave to execute stateless AI inference. It enforces "verifiable transparency" by maintaining a cryptographically verifiable, append-only ledger (transparency log) of all software running on the cloud nodes49. Client devices cryptographically verify node attestations and refuse to send data unless the cloud node is running software published in this log, allowing independent security researchers to audit the code and confirm that data is never retained, logged, or made accessible to privileged data center administrators49. When data must be temporarily stored and subsequently deleted, traditional file deletion is fundamentally inadequate. On modern Solid State Drives (SSDs), standard overwrite commands fail due to the Flash Translation Layer (FTL), a controller that constantly remaps logical blocks to new physical cells for wear-leveling, leaving old data intact in over-provisioned sectors54. To achieve verifiable deletion, systems must rely on self-encrypting drives where all data is transparently encrypted by a Media Encryption Key (MEK) stored in a hardware secure enclave54. According to NIST SP 800-88 guidelines, executing a "Cryptographic Erase" shreds this key, instantly rendering all data physically present on the flash memory cryptographically inaccessible and fulfilling the requirement for verifiable deletion55.

Part 3: Architectural Documentation and Comparative Analysis

To rigorously evaluate these architectures against the "collect everything, promise restraint" model, we must document their operational parameters across ten critical dimensions. The tables below dissect how these technical mechanisms isolate identity from content, balance trust assumptions, and mitigate residual risks.

Table 1: Network, Routing, and Query Architectures

Table 2: Analytics, Telemetry, and Machine Learning Architectures

Table 3: Identity, Authentication, and Threat Detection Architectures

Part 4: Application to Specific Safety Objectives

The integration of these privacy-enhancing technologies enables the replacement of surveillance-heavy safety mechanisms across all major digital domains.

1. CSAM Detection, Malware Warnings, and User-Controlled Filtering

The debate surrounding Child Sexual Abuse Material (CSAM) detection perfectly encapsulates the tension between safety and cognitive privacy. In 2021, Apple proposed a Client-Side Scanning (CSS) system using fuzzy Private Set Intersection (PSI) to compare local iCloud photos against a database of known CSAM perceptual hashes18. Although cryptographically designed so the server learned nothing unless a high threshold of matches was met, the system faced immense backlash. The landmark paper "Bugs in our Pockets" argued that CSS fundamentally breaches the end-to-end (E2E) trust model, transforming a device into an agent of the state. The authors proved that such systems could easily be repurposed by authoritarian governments to scan for political dissent, establishing a dangerous precedent for scope creep60. Following this consensus, Apple abandoned the PSI scanning approach, pivoting to "Communication Safety"—a paradigm relying entirely on local threat detection and user-controlled filtering63. This system uses on-device machine learning to detect and blur explicit images in iMessage. Crucially, it processes entirely locally, does not report to Apple or law enforcement, and empowers the user (or their guardians) to make filtering decisions locally63. For malware warnings and phishing protection, instead of sending every URL a user visits to a cloud provider for analysis, browsers utilize OHTTP. The browser encapsulates a request to check a URL against Google Safe Browsing, routing it through an independent relay6. The Safe Browsing server evaluates the URL and returns the risk assessment without ever learning the IP address of the user making the request6.

2. Fraud Prevention, Bot Reduction, Rate Limiting, and Spam Control

Surveillance-based systems track user IP addresses, browser fingerprints, and cross-site cookies to generate behavioral "trust scores" to block bots and spam. This fundamentally degrades privacy. The alternative lies in the integration of Private Access Tokens (PATs) and Privacy Pass (RFC 9576\)34. A user's device utilizes a local hardware attestation (e.g., Apple App Attest) or solves a localized challenge to prove human presence to an Issuer. The Issuer provides a batch of anonymous, blind-signed tokens using VOPRF33. When the user visits a restricted site or attempts a high-volume API action, they present a token. The site validates the signature, proving the user is human, but learns absolutely nothing about their identity, IP, or browsing history66. For strict rate limiting without identity, Anonymous Rate Limit Credentials (ARC) allow a server to throttle a specific anonymous client to a predefined number of presentations without ever linking those presentations to a global identity32.

3. Age Eligibility

Currently, age gating requires users to upload government IDs to centralized platforms, creating massive honeypots for identity theft. The modern alternative utilizes W3C Verifiable Credentials secured by BBS+ signatures or SD-JWT24. A government issues a cryptographically signed digital credential to the user's mobile wallet. When a service requests age verification, the user's wallet generates a Zero-Knowledge Proof (ZKP) via BBS+ demonstrating the predicate "Age \> 18" is true. The service mathematically verifies the cryptographic signature without the user revealing their name, exact date of birth, or document number, and without the government issuer knowing which service the user is accessing25.

4. Abuse Reporting and Account Security

In End-to-End Encrypted (E2EE) messaging environments, platform operators cannot scan messages for abuse, leading to claims that E2EE harbors bad actors. The solution is "Message Franking." When a user sends a message, the app generates a cryptographic HMAC (Hash-based Message Authentication Code) binding the sender's identity to the message payload, delivered alongside the ciphertext69. The server cannot read the message. However, if the recipient chooses to report the sender for abuse, the recipient's client forwards the plaintext and the HMAC to the server. The server verifies the HMAC to ensure the message is authentic and untampered, enabling targeted moderation on verifiable evidence without requiring mass surveillance71. For account security, to prevent credential stuffing without exposing user passwords, platforms utilize Private Set Intersection (PSI). Protocols like Meta's PDL allow a client to check a new password against a vast database of breached passwords. The intersection occurs cryptographically; the user never sends their plaintext password to the server, and the server never sends its proprietary breach database to the client19.

5. AI Capability Safeguards and Model Evaluations

Cloud AI providers justify logging user prompts to evaluate model safety, improve recommendation quality, and detect jailbreaks, fundamentally compromising user privacy. Safety can be pushed to the edge via Local Guardrails. By deploying highly efficient, quantized language models (e.g., Llama-Guard 4 12B or Reflex-Guard) directly on the user's device, prompts are scanned for harmful intent (e.g., weapons manufacturing instructions) locally73. These models execute on local NPUs with latencies under 40ms, blocking malicious inputs before the prompt is ever transmitted to the cloud74. For complex model evaluations and AI workloads that require cloud compute, architectures like Apple's Private Cloud Compute ensure prompts are processed statelessly52. Prompts are sent via OHTTP, ensuring the cloud provider doesn't know the user's IP. The prompt is decrypted inside a Secure Enclave, processed, and the memory is cryptographically erased via hardware protocols immediately after inference, verified by public transparency logs47.

6. Analytics, Crash Reporting, and Search Personalization

Companies cite application diagnostics and search personalization to justify mass data collection. For Analytics and Crash Reporting, the Distributed Aggregation Protocol (DAP) provides a surveillance-free alternative. If a vendor wants to track application crash rates, the client device splits the crash telemetry into two cryptographic shares using Prio338. Share A goes to an aggregator run by the vendor; Share B goes to an independent third-party aggregator. The client attaches a zero-knowledge proof validating the shares. Only when both aggregators sum their millions of shares and combine the macroscopic totals can the vendor read the final crash rate39. For Search Personalization and Recommendation Quality, systems utilize Federated Learning combined with Local Differential Privacy (LDP). The client device maintains a private model of the user's preferences locally. It downloads the global search algorithm, refines it using local data, and only returns differentially private gradients to the server44. The server aggregates these gradients via Secure Aggregation to improve the global model for all users, completely blind to any individual's search history.

Part 5: Reference Patterns for Privacy-Preserving Safety

To facilitate industry-wide adoption, organizations should standardize around the following architectural blueprints:

1. Anonymous Safety Lookup

Use Case: Malware warnings, phishing protection, compromised credential checks. Pattern: The client encapsulates a safety query using HPKE and routes it through an Oblivious HTTP (OHTTP) Relay to a Gateway6. The Gateway decapsulates the query and performs a Private Information Retrieval (PIR) or Private Set Intersection (PSI) against a centralized threat database17. The result is encapsulated and returned through the Relay. Result: The platform secures the user from threats without knowing who the user is, where they are located, or what specific threat they were checking against.

2. Local Classification with No Reporting by Default

Use Case: CSAM detection, AI prompt safety, local spam filtering, user-controlled filtering. Pattern: The platform pushes a lightweight, heavily quantized classification model (e.g., Llama-Guard 1B) to the client device73. Inference occurs entirely on the local NPU. If a threat is detected, the action is taken locally (e.g., blurring an image, blocking an outbound prompt)63. No telemetry or flag is sent to the cloud provider unless explicitly escalated by the user. Result: Eradicates the "Bugs in our Pockets" risk of Client-Side Scanning by entirely eliminating the reporting channel, preserving the sanctity and absolute privacy of the endpoint60.

3. Split-Trust Age Proof

Use Case: Age eligibility for restricted content or services. Pattern: A trusted Issuer provides a Verifiable Credential to a digital wallet. The user visits a restricted site. The wallet generates a Zero-Knowledge Proof via BBS+ signatures demonstrating the user is over 18 without revealing their birthdate25. Simultaneously, the user redeems an anonymous Private Access Token (PAT) via the Privacy Pass protocol to prove device integrity and human presence65. Result: The site mathematically verifies the user's age and device authenticity without collecting their name, date of birth, or creating a correlatable tracking identifier.

4. Aggregate Telemetry Without User Histories

Use Case: Application analytics, feature usage tracking, crash reporting, model evaluations. Pattern: The client device utilizes the Distributed Aggregation Protocol (DAP)39. Telemetry data is validated via a Zero-Knowledge Proof (to prevent data poisoning) and secret-shared via Prio338. The shares are transmitted over OHTTP to two distinct, legally separated Aggregators6. The Aggregators perform Secure Multi-Party Computation to sum the shares and release only the final aggregate to the Collector. Result: The software vendor gains high-fidelity operational analytics and model evaluation metrics while mathematically eliminating the existence of user-specific behavioral histories.

5. Capability Gating Without Persistent Identity

Use Case: Limiting free-tier API usage, bot mitigation, spam reduction in decentralized environments. Pattern: Instead of requiring users to create accounts to track API limits, the platform issues Anonymous Rate Limit Credentials (ARC)32. The client authenticates once, receives a cryptographic credential, and derives multiple unlinkable presentation tokens. For environments requiring severe moderation deterrence, Traceable Ring Signatures are employed, providing unconditional anonymity that can only be pierced by a decentralized quorum of auditors if a cryptographic abuse threshold is met36. Result: Frictionless, account-free user experiences that resist Sybil attacks and automated abuse while maintaining absolute pseudonymity.

Part 6: Conclusion and Procurement Requirements

The assertion that centralized surveillance is a strict technical prerequisite for digital safety is a relic of outdated engineering paradigms. The technologies outlined in this report—from Oblivious HTTP and Verifiable Distributed Aggregation Functions to Zero-Knowledge Proofs and Hardware Enclaves—prove that cognitive privacy and platform integrity can successfully coexist. When a safety objective can be achieved without retaining identity-linked data, collecting that data transitions from a security necessity to an intentional surveillance choice. To enforce this transition and protect users from data breaches, insider threats, and transnational repression, governments, enterprise procurement officers, and regulatory bodies must adopt strict frameworks demanding "Privacy by Design." Organizations claiming that continuous data collection is necessary for safety must be subjected to intense technical scrutiny.

Procurement and Regulatory Requirements

Before authorizing the collection of identity-linked inquiry data, or before procuring systems that do so, entities must satisfy the following technical requirements:

1. Exhaustion of Edge Computing: The vendor must mathematically and computationally demonstrate why the safety classification cannot be performed via on-device machine learning (e.g., local threat detection via Llama-Guard) without cloud reporting.

2. Cryptographic Decoupling Verification: If cloud processing is required due to compute constraints, the vendor must prove why metadata decoupling architectures (such as OHTTP or Privacy Pass) cannot be utilized to separate the user's network identity from the request payload.

3. Mandatory Secret Sharing for Analytics: Any telemetry, crash reporting, or diagnostic data collection must utilize a standardized Secure Aggregation framework (such as DAP/VDAF), utilizing at least two non-colluding aggregation nodes to guarantee non-possession of individual records.

4. Hardware-Enforced Statelessness: If remote processing of plaintext data is unavoidable, the vendor must execute the workload inside a hardware-isolated environment (such as an attestation-backed Secure Enclave). The vendor must provide verifiable transparency logs proving that the enclave software is stateless and immediately zeroes memory upon thread completion.

5. Verifiable Deletion Protocols: The vendor must abandon "logical deletion" (e.g., overwriting) on solid-state storage. Compliance requires hardware-based Cryptographic Erase (destroying the Media Encryption Key) in accordance with NIST SP 800-88 Purge standards, backed by third-party auditability.

6. Zero-Knowledge Disclosure Defaults: All identity and entitlement verifications (e.g., age checks, geographic gating) must support selective disclosure (SD-JWT) or zero-knowledge protocols (BBS+). The system must be capable of verifying predicates without ingesting underlying sensitive attributes.

The blueprint for a surveillance-free digital infrastructure is fully realized. By replacing policy-based promises of restraint with mathematically enforced guarantees of non-possession, we can build digital environments that are inherently hostile to malicious actors, immune to state overreach, and fundamentally respectful of cognitive privacy.

Works cited

1. Carpenter v. United States \- Epic.org, https://epic.org/documents/carpenter-v-united-states-2/

2. Carpenter v. United States | 585 U.S. \_\_\_ (2018), https://supreme.justia.com/cases/federal/us/585/16-402/

3. Carpenter v. United States: CSLI, Third-Party Doctrine, and Privacy, https://digitalcommons.liberty.edu/cgi/viewcontent.cgi?article=1280\&context=lu\_law\_review

4. Congressional Investigations of the Department of Justice, 1920-2007, https://www.everycrsreport.com/reports/RL34197.html

5. Protonmail provides FBI with information to identify account owner, https://www.reddit.com/r/BuyFromEU/comments/1rlt3eo/protonmail\_provides\_fbi\_with\_information\_to/

6. Oblivious HTTP explained \- HTTP.DEV, https://http.dev/ohttp

7. Oblivious HTTP \- when the server does not want to see your IP, https://cfp.pass-the-salt.org/pts2026/talk/B8AN9M/

8. Oblivious HTTP \- Wikipedia, https://en.wikipedia.org/wiki/Oblivious\_HTTP

9. draft-ietf-hpke-hpke-04 \- Hybrid Public Key Encryption, https://datatracker.ietf.org/doc/draft-ietf-hpke-hpke/

10. Hybrid Public Key Encryption \- IETF, https://www.ietf.org/archive/id/draft-ietf-hpke-hpke-03.html

11. Distributed Aggregation Protocol for Privacy Preserving Measurement, https://ietf-wg-ppm.github.io/draft-ietf-ppm-dap/draft-ietf-ppm-dap.html

12. Azure Confidential Inferencing with Oblivious HTTP, https://thomasvanlaere.com/posts/2026/06/azure-confidential-inferencing-with-oblivious-http/

13. RFC 9614: Partitioning as an Architecture for Privacy, https://www.rfc-editor.org/info/rfc9614/

14. Identifying Harmful Media in End-to-End Encrypted Communication, https://www.usenix.org/system/files/sec21summer\_kulshrestha.pdf

15. Spiral: Fast, High-Rate Single-Server PIR via FHE Composition, https://par.nsf.gov/servlets/purl/10332077

16. OnionPIR: Response Efficient Single-Server PIR \- Semantic Scholar, https://www.semanticscholar.org/paper/OnionPIR%3A-Response-Efficient-Single-Server-PIR-Mughees-Chen/ae22d1db35a6f8b8463a1fc2a61b839ccadc7c9f

17. How Practical is Single-Server Private Information Retrieval?, https://ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/appliedcrypto/education/theses/semester-project\_sophia-artioli.pdf

18. Federated Analytics: A Survey \- Emerald Publishing, https://www.emerald.com/atsip/article/12/1/1/1331466/Federated-Analytics-A-Survey

19. How Meta is improving password security and preserving privacy, https://engineering.fb.com/2023/08/08/security/how-meta-is-improving-password-security-and-preserving-privacy/

20. A Survey on Fuzzy Private Set Intersection Protocols \- Cloudfront.net, https://d2j16w31g89z0j.cloudfront.net/site/ictc2025/abs/D10-1.pdf

21. The Broken Promise of Apple's Announced Forbidden-photo, https://www.bu.edu/riscs/2021/08/10/apple-csam/

22. draft-ietf-oauth-selective-disclosure-jwt-22, https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt

23. Selective Disclosure for JWTs (SD-JWT) \- IETF, https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-08.html

24. Your JWTs Are Now Outdated — Meet Selective Disclosure (RFC, https://mojoauth.com/blog/jwts-are-now-outdated-meet-selective-disclosure-rfc-9901

25. Zero Knowledge Proof (ZKP) and Selective Disclosure | Gataca, https://www.gataca.io/resources/blog/ssi-essentials-which-selective-disclosure-protocol-will-succeed/

26. Privacy-preserving Solution Using BBS+ for Digital Identity and Wallet, https://blog.worldline.tech/2024/05/14/bbs-plus-credentials.html

27. Cryptographers' Feedback on the EU Digital Identity's ARF \#211, https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/211

28. RDF-based Semantics for Selective Disclosure and Zero-knowledge, https://publikationen.bibliothek.kit.edu/1000182104/160651221

29. A Systematic Review and Layered Framework for Privacy-by-Design, https://arxiv.org/html/2502.02520v2

30. Post-Quantum Cryptography for Verifiable Credentials \- TechRxiv, https://www.techrxiv.org/doi/pdf/10.36227/techrxiv.176118722.22701360

31. RFC 9576: The Privacy Pass Architecture, https://www.rfc-editor.org/info/rfc9576/

32. draft-ietf-privacypass-arc-crypto-01 \- Anonymous Rate-Limited, https://datatracker.ietf.org/doc/draft-ietf-privacypass-arc-crypto/

33. Privacy Pass Authentication for Media over QUIC (MoQ), https://moq-wg.github.io/privacy-pass/draft-ietf-moq-privacy-pass-auth.html

34. FAQ \- Privacy Pass, https://privacypass.github.io/faq/

35. Privacy Pass \- Cloudflare Developer Docs, https://developers.cloudflare.com/privacy-pass/

36. PA-CRT: Chinese Remainder Theorem Based Conditional Privacy, https://www.researchgate.net/publication/331656530\_PA-CRT\_Chinese\_Remainder\_Theorem\_Based\_Conditional\_Privacy-Preserving\_Authentication\_Scheme\_in\_Vehicular\_Ad-Hoc\_Networks

37. Traceable Monero: Anonymous Cryptocurrency with Enhanced, https://www.researchgate.net/publication/340691606\_Traceable\_Monero\_Anonymous\_Cryptocurrency\_with\_Enhanced\_Accountability

38. Verifiable Distributed Aggregation Functions \- IETF, https://www.ietf.org/archive/id/draft-irtf-cfrg-vdaf-05.html

39. draft-ietf-ppm-dap-19 \- Distributed Aggregation Protocol for Privacy, https://datatracker.ietf.org/doc/draft-ietf-ppm-dap/

40. The Mastic VDAF \- IETF, https://www.ietf.org/archive/id/draft-mouris-cfrg-mastic-01.html

41. draft-ietf-ppm-dap-19, https://datatracker.ietf.org/doc/html/draft-ietf-ppm-dap-19

42. (PDF) Verifiable Distributed Aggregation Functions \- ResearchGate, https://www.researchgate.net/publication/374355802\_Verifiable\_Distributed\_Aggregation\_Functions

43. The Distributed Aggregation Protocol: A First-Time Editor's ... \- Divvi Up, https://divviup.org/blog/writing-dap-standards/

44. What is Differential Privacy?, https://www.privacyguides.org/articles/2025/09/30/differential-privacy/

45. Differential Privacy: A Complete Guide for Data Scientists \- upGrad, https://www.upgrad.com/blog/what-is-differential-privacy/

46. Local Differential Privacy (Randomized Response) \- MetricGate, https://metricgate.com/docs/local-differential-privacy-mechanism/

47. Private Cloud Compute: A new frontier for AI privacy in the cloud, https://security.apple.com/blog/private-cloud-compute/

48. Security research on Private Cloud Compute, https://security.apple.com/blog/pcc-security-research/

49. Hardware Root of Trust | Documentation \- Apple Security Research, https://security.apple.com/documentation/private-cloud-compute/hardwarerootoftrust

50. Confidential Computing Transparency \- arXiv, https://arxiv.org/html/2409.03720v1

51. May | 2026 \- UNMITIGATED RISK, https://unmitigatedrisk.com/?m=202605

52. Private Cloud Compute Security Guide | Documentation, https://security.apple.com/documentation/private-cloud-compute

53. Apple Private Cloud Compute Security Guide | PDF \- Scribd, https://www.scribd.com/document/788492740/Blog-Security-Research-on-Private-Cloud-Compute-Apple-Security-Research

54. SSD Architecture And NAND Flash: Why Erasing An SSD Is Not Like, https://datadestruction.com/learn/ssd-architecture-and-nand-flash-why-erasing-an-ssd-is-not-like-erasing-a-hard-drive/

55. NIST 800-88 Media Sanitization Complete Guide \- Inventive HQ, https://inventivehq.com/blog/nist-800-88-media-sanitization-complete-guide

56. How to Securely Erase an SSD Before Selling or Disposing \- Univik, https://univik.com/blog/securely-erase-ssd/

57. How to Erase iPhone Data \- Gazelle The Horn, https://www.gazelle.com/thehorn/2022/04/26/how-to-erase-iphone-data/

58. Can You Wipe an Encrypted Drive Securely? \- BitRaser, https://www.bitraser.com/article/securely-wipe-an-encrypted-drive.php

59. Apple's CSAM Detection Mechanism | PDF | Encryption \- Scribd, https://www.scribd.com/document/519121401/Apple-s-CSAM-detection-mechanism

60. (PDF) Bugs in our Pockets: The Risks of Client-Side Scanning, https://www.researchgate.net/publication/355233857\_Bugs\_in\_our\_Pockets\_The\_Risks\_of\_Client-Side\_Scanning

61. Bugs in our pockets: the risks of client-side scanning, https://academic.oup.com/cybersecurity/article/10/1/tyad020/7590463

62. Fact Sheet: Client-Side Scanning \- Internet Society, https://www.internetsociety.org/resources/doc/2020/fact-sheet-client-side-scanning/

63. Apple's Blind Spot — Abandoned CSAM Scanning \- GuardKids, https://guardkids.org/investigations/apple-blind-spot

64. Apple Sued Over Allegations of CSAM on iCloud \- CNET, https://www.cnet.com/tech/services-and-software/apple-sued-over-csam-icloud-allegations/

65. cloudflare/privacypass-ts: A TypeScript Library for the Privacy Pass, https://github.com/cloudflare/privacypass-ts

66. Age Verification in the Web \-- Holy Grail to Control Access to ... \- arXiv, https://arxiv.org/pdf/2605.05513

67. Age Verification in the Web \- Holy Grail to Control Access to ... \- arXiv, https://arxiv.org/html/2605.05513v1

68. Verifiable Credentials Data Model v2.0 \- W3C, https://www.w3.org/TR/vc-data-model-2.0/

69. Advancing Security Protocol Verification:, https://d-nb.info/1373598131/34

70. SoK: Content Moderation Schemes in End-to-End Encrypted Systems, https://arxiv.org/html/2208.11147v5

71. EFFICIENT ABUSE REPORTING FOR PRIVATE MESSAGING, https://cdr.lib.unc.edu/downloads/3f462n75k?locale=en

72. Hecate: Abuse Reporting in Secure Messengers with Sealed Sender, https://par.nsf.gov/servlets/purl/10358606

73. meta-llama/Llama-Guard-4-12B \- Hugging Face, https://huggingface.co/meta-llama/Llama-Guard-4-12B

74. A Low-Latency Guardrail for LLM Prompt Safety Using Dense ... \- arXiv, https://arxiv.org/html/2608.17556

75. Deploying Accelerated Llama 3.2 from the Edge to the Cloud, https://developer.nvidia.com/blog/deploying-accelerated-llama-3-2-from-the-edge-to-the-cloud/