Safety Without Surveillance: Architectures for Privacy-Preserving Security

Report body

Safety Without Surveillance: Architectures for Privacy-Preserving Security

Introduction

The digital era has been defined by a pervasive and largely unquestioned assumption: that the provision of safety, security, and customized services inherently requires the centralized collection and analysis of user data. This paradigm has driven the construction of vast architectural frameworks dedicated to mass surveillance, a practice characterized by the indiscriminate acquisition and processing of data encompassing communications, locations, and behavioral metadata from broad populations1. However, the debate between privacy and security has long been framed incorrectly as a zero-sum game, relying on the fallacious "nothing to hide" argument to justify the systemic monitoring of lawful intellectual activity2.
Intellectual privacy—the capacity for independent thought, unburdened by state or corporate intrusion—is a fundamental prerequisite for a functioning democratic society1. The ability to read, search, and communicate without the chilling effect of a centralized observer is a core civil liberty1. Yet, society simultaneously faces legitimate and severe harms. The proliferation of child sexual abuse material (CSAM), sophisticated malware, state-sponsored disinformation, and network abuse are undeniable threats that require robust technological countermeasures. Safeguards against these threats are necessary, but the architectural implementation of these safeguards demands intense scrutiny.
The research objective of this report is not to eliminate safety mechanisms, but to rigorously examine whether the exact same protective outcomes can be achieved while collecting exponentially less information about a population's thoughts, searches, reading habits, and questions. This inquiry leads to a critical, foundational question: If a safety objective can be achieved without retaining a person's inquiry history, what legitimate reason exists to retain that history? By synthesizing advanced cryptography, distributed systems, federated analytics, and localized artificial intelligence, this report explores technological and institutional methods for achieving legitimate safety goals without constructing centralized records. The analysis investigates privacy-preserving architectures, including private information retrieval, oblivious network protocols, on-device AI moderation, and differential privacy, culminating in concrete architectural patterns for "Safety Without Surveillance."

The Architecture of Mass Surveillance and the Erosion of Intellectual Privacy

To understand the necessity of privacy-preserving architectures, one must first understand the legal and technical vulnerabilities of the current centralized model. Historically, Fourth Amendment jurisprudence in the United States protected the contents of physical spaces and private papers, operating on the assumption that surveillance required physical trespass3. However, the advent of digital communications led to the expansion of the "third-party doctrine," which posits that individuals forfeit reasonable expectations of privacy for information voluntarily turned over to third parties, such as internet service providers or telecommunications companies3.
The landmark Supreme Court case Carpenter v. United States, 585 U.S. 296 (2018), signaled a vital shift, recognizing that individuals can retain privacy interests in exhaustive digital records, such as historical cell-site location information (CSLI)5. The Court acknowledged that the pervasive tracking of a mobile device generates a comprehensive record of a person's movements, which is fundamentally different from traditional, limited surveillance5. Despite this judicial evolution, the routing of data through corporate infrastructure continues to expose the "record of the mind"—search queries, reading habits, and private associations—to unwarranted access3. The devices within a modern home generate multiple streams of evidence that bypass traditional warrant requirements, effectively allowing data brokers to commodify and sell location data and behavioral metadata directly to intelligence agencies without judicial oversight3.
The aggregation of this data creates systemic risks, as tracing authorities initially designed for serious crimes inevitably suffer from function creep, expanding to routine surveillance and administrative infractions2. Centralized repositories of lawful intellectual activity represent massive cybersecurity liabilities. When a centralized platform retains the inquiry history of billions of users to facilitate "safety filtering" or "opt-in personalization," that database becomes an irresistible target for advanced persistent threats, hostile state actors, and insider abuse. True data minimization requires architectural guarantees that the data is never collected in the first place, enforcing short retention periods by relying on ephemeral cryptographic states rather than institutional promises.

The Fallacy of Client-Side Scanning

In response to the widespread adoption of end-to-end encryption (E2EE), law enforcement and national security agencies have argued that cryptography hinders access to vital evidence4. To bypass E2EE without officially requesting encryption backdoors, intelligence communities and technology companies proposed Client-Side Scanning (CSS). CSS architectures relocate the surveillance apparatus directly onto the user's device, scanning private files and messages against a database of targeted content (such as CSAM) before the data is encrypted and transmitted4.
In 2021, Apple announced controversial plans to implement a proprietary CSAM detection algorithm known as NeuralHash9. The system was designed to perform on-device scanning of user images destined for iCloud Photos, utilizing threshold secret sharing to alert reviewers only if a specific number of matches occurred9. While the objective of combating CSAM is universally recognized as critical, privacy advocates and cryptographers raised severe alarms regarding the mechanism. The resulting public backlash eventually forced Apple to abandon the NeuralHash feature for iCloud in late 20229.
A coalition of leading cryptographers, including Harold Abelson, Ross Anderson, and Susan Landau, definitively dismantled the safety claims of CSS in the seminal report Bugs in our Pockets: The Risks of Client-Side Scanning4. Their analysis demonstrated that CSS does not resolve the encryption debate; rather, it introduces catastrophic vulnerabilities and fundamentally alters the relationship between citizens and their personal devices.
The security and privacy failures of CSS are multifaceted. First, CSS constitutes automated, distributed bulk intercept by design. Because it requires access to unencrypted content to perform matches, it is functionally equivalent to indiscriminate wiretapping, transforming E2EE from a guarantee of secrecy into a conditional privilege of use4. Second, the opacity of mobile operating systems combined with the introduction of invasive scanning mechanisms creates new attack vectors. If a device is engineered to scan its own contents and report findings, malicious actors—ranging from state intelligence services to intimate partner abusers—can exploit these pathways to search for unauthorized content4.
Furthermore, CSS mechanisms utilizing perceptual hashing are remarkably brittle. Research indicates that systems like NeuralHash are highly vulnerable to detection avoidance; adversaries can apply minor, imperceptible perturbations to illicit images to evade the hash matching, rendering the system ineffective against sophisticated criminals while simultaneously subjecting average, law-abiding citizens to continuous monitoring10. Finally, the risk of function creep is absolute. If a global infrastructure is constructed to scan all user devices for one specific type of illicit material, the technical mechanism can be seamlessly repurposed by authoritarian regimes to scan for political dissent, religious texts, or unauthorized journalism4. CSS represents a failure of architectural imagination, relying on the flawed premise that discovering harmful content necessitates the indiscriminate observation of all content.

Privacy Partitioning: Decoupling Identity from Content Requests

The most foundational step in achieving safety without surveillance is the implementation of privacy partitioning. This paradigm selectively spreads data and network communication across multiple, mutually distrustful parties to enforce the separation of user identity from user data14. By applying the principle of least privilege to network routing, privacy partitioning ensures that no single entity in a system possesses both the metadata of who is asking a question and the plaintext of what is being asked14.

Oblivious HTTP (RFC 9458)

Standard HTTPS protocols encrypt the payload of a request, securing it from network observers, but they inherently expose the client's IP address and connection metadata to the destination server15. This allows the server to compile detailed profiles of client behavior over time, linking sensitive search queries or safety checks directly to a physical location or account15. Oblivious HTTP (OHTTP), standardized by the IETF in RFC 9458, resolves this vulnerability through a decoupled architecture15.
OHTTP introduces a strictly defined separation of privileges involving three primary operational entities. The Client initiates the process by encapsulating the HTTP request using Hybrid Public Key Encryption (HPKE). This payload is encrypted specifically for the destination Gateway's public key15. The Client then transmits this encrypted payload to an intermediate Oblivious Relay. The Relay receives the transmission, meaning it can observe the Client's IP address and timing metadata, but because it lacks the Gateway's private key, the Relay cannot decrypt the request content16. The Relay subsequently strips all client-identifying metadata and forwards the opaque ciphertext to the Oblivious Gateway. The Gateway decrypts the payload, processes the underlying HTTP request, and returns an encrypted response through the Relay back to the Client. The Gateway sees the plaintext content of the query but possesses no knowledge of the Client's IP address, network origin, or identity16.
This separation relies on a non-collusion assumption: provided the Relay and the Gateway are operated by independent administrative entities, user privacy is mathematically preserved17. To ensure requests remain unlinkable, the HPKE standard mandates the use of a Key Encapsulation Mechanism (KEM) combined with a Key Derivation Function (KDF) and Authenticated Encryption with Associated Data (AEAD), generating a fresh cryptographic context for every single request16.
The practical applications of OHTTP in safety architectures are already being deployed at scale. Google's Safe Browsing API utilizes an OHTTP Gateway to allow client applications, such as web browsers, to check whether a URL is present on Google's list of unsafe websites. By routing the request through a third-party Relay operated by Fastly, the client device can verify the safety of a web resource without Google ever logging which user is visiting which website17. Similarly, Meta utilizes OHTTP for "Private Processing" in generative AI tools, allowing WhatsApp users to query AI models without linking the sensitive prompts to their personal accounts or phone numbers16.
While OHTTP provides robust metadata privacy, it is not a panacea for anonymity. If a user's plaintext query contains uniquely identifying semantic information, the Gateway may still infer identity from the payload18. Therefore, OHTTP is best deployed as a foundational transport layer in a defense-in-depth architecture alongside other cryptographic primitives that obscure the payload itself.

Private Information Retrieval and Cryptographic Proofs

While OHTTP successfully conceals who is asking a question, Private Information Retrieval (PIR) operates at a higher cryptographic tier to conceal what is being asked. PIR is a protocol that allows a client to fetch a specific record from a remote database without revealing to the server which record was fetched, effectively allowing safety checks against remote databases without leaking the subject of the inquiry20.

The Evolution of High-Throughput PIR

Historically, PIR was considered theoretically elegant but computationally prohibitive. Early implementations required the server to perform heavy homomorphic encryption operations over every single bit of the database for every query, resulting in throughputs measured in mere kilobytes per second22. However, recent breakthroughs based on Ring Learning with Errors (RLWE) have propelled single-server PIR into practical viability. Single-server architectures are highly desirable because they do not require the complex operational overhead of maintaining synchronized, non-colluding servers23. Modern protocols achieve efficiency by pushing the computational burden into an "offline" preprocessing phase, allowing the online query to be resolved with highly parallelizable matrix-vector multiplications23.
To understand the current state of PIR technology, a comparative analysis of leading protocols highlights the technical trade-offs between server throughput, communication overhead, and client storage constraints.

The integration of PIR allows platforms to offer isolated safety classifiers. For instance, a client can check a file hash against a massive database of known malware using Keyword PIR (which maps arbitrary strings to database indices)28. When combined with OHTTP, the resulting system guarantees that the service provider knows neither the identity of the user requesting the safety check nor the specific content being verified, yet the user still receives accurate, real-time threat intelligence.

Private Set Intersection for Threat Verification

When safety mechanisms mandate that a client's local files be verified against a remote list of known threats (such as a CSAM hash database), standard lookups leak the client's data. Private Set Intersection (PSI) solves this by mathematically proving relationships between datasets without revealing the data outside of the intersection29.
Traditional PSI protocols are designed for balanced datasets. However, safety applications typically feature a highly unbalanced architecture: a client holds a single file or a small set of files, while the server maintains a database of millions of malicious hashes32. Unbalanced PSI protocols optimize this interaction by combining Oblivious Pseudorandom Functions (OPRF) with PIR32. The server performs an offline preprocessing step on its massive threat database. During the online phase, the client uses an OPRF to securely evaluate its single element against the server's preprocessed data32. This limits the client's storage requirements to mere megabytes while enabling intersection checks against gigabyte-sized databases32. If the file is benign, the protocol terminates, and the server learns nothing. If it is malicious, the protocol can trigger a local quarantine mechanism or generate a cryptographic proof of the match33.

Federated Approaches and Differential Privacy

The maintenance of digital safety—including the detection of broad security trends, software crashes, and aggregate malware encounters—requires telemetry. Historically, telemetry involved uploading raw, client-identified logs to a central server, violating the principle of data minimization and allowing platform operators to reconstruct individual user sessions14. To collect systemic safety metrics without observing individual behavior, architectures must utilize federated approaches, specifically the Distributed Aggregation Protocol (DAP)14.

The Prio Architecture and the Distributed Aggregation Protocol

DAP, based on the Prio architecture, standardizes privacy-preserving measurement across the internet ecosystem35. In a DAP deployment, client measurements are cryptographically secret-shared and distributed between two non-colluding aggregators, typically designated as a Leader and a Helper37. A single share of the data is mathematically indistinguishable from random noise, ensuring neither aggregator can read the individual telemetry report37.
To prevent malicious clients from poisoning the aggregate data (e.g., submitting impossible values to skew telemetry), the system utilizes Secret-Shared Non-Interactive Proofs (SNIPs) or Verifiable Distributed Aggregation Functions (VDAFs). These mechanisms allow the servers to cryptographically verify that the client's submitted data is well-formed without revealing the underlying value35. The aggregators independently compute partial sums, and only the final, aggregated result is revealed to the central Collector36.
This architecture extends naturally to Federated Learning in multi-tenant agent systems. By separating agent communication from learning coordination, federated privacy architectures allow models to learn from distributed operational data (such as identifying novel spam patterns) without centralizing the raw tenant data38. The models are trained locally on user devices or edge nodes, and only the encrypted model updates are transmitted to the aggregators38.

Enhancing DAP with Differential Privacy

While DAP hides the payload, the submission process can still leak metadata. To counter this, DAP is layered over Oblivious HTTP, ensuring the aggregators cannot associate the telemetry with a specific network identity or correlate multiple submissions from the same user16. Furthermore, to prevent statistical inference attacks—where an adversary might attempt to isolate an individual's contribution by comparing aggregates of [Source figure not loaded here; retained in the source-text copy.] and [Source figure not loaded here; retained in the source-text copy.] populations—Differential Privacy (DP) is injected into the VDAF37. By adding carefully calibrated mathematical noise to the final aggregate, the system provides a formal, quantifiable guarantee that the output does not definitively confirm the presence or absence of any individual's data, balancing the need for actionable threat intelligence with absolute individual privacy37.

On-Device Processing and Isolated Safety Classifiers

Historically, content moderation and safety filtering necessitated uploading text, images, and audio to the cloud for analysis by massive neural networks. This centralized AI processing inherently violates intellectual privacy, exposing user prompts, drafted communications, and unpolished thoughts to corporate servers40. The advent of highly optimized, Small Language Models (SLMs) has fundamentally shifted the safety boundary from the cloud to the edge, enabling completely isolated safety classifiers. By running safety models locally on the user's device, harmful content, prompt injections, and policy violations can be detected and mitigated without transmitting raw data over the network40.

Llama Guard 3 1B INT4: Edge AI Moderation

Meta's release of the Llama Guard 3-1B-INT4 model exemplifies the state-of-the-art in local safety processing40. The model is designed to classify user inputs and generative outputs for violations across multiple safety categories, including self-harm, hate speech, and CSAM, without requiring cloud connectivity41.
To execute a 1-billion-parameter model on resource-constrained mobile devices where memory bandwidth and DRAM allocation are primary bottlenecks, engineers applied aggressive model compression techniques:

1. Quantization Aware Training (QAT): The model weights were reduced from 16-bit precision to 4-bit per-channel groupwise quantization, and activations were reduced to 8-bit dynamic quantization. This compressed the model size by a factor of 7, reducing it to a mere 440 MB40.
2. Structural Pruning: Utilizing block-level and neuron-level sensitivity analysis, the decoder blocks and MLP dimensions were pruned. Crucially, the output unembedding layer was drastically reduced. While a standard LLM requires a vocabulary of 128,000 tokens, a safety model only requires a limited vocabulary to output specific hazard categories. This layer's output shape was reduced from 128k to 20, eliminating vast amounts of unnecessary parameters40.
3. ExecuTorch Integration: Executed via the PyTorch ExecuTorch framework and the XNNPACK backend, the model minimizes DRAM allocation and leverages optimized scaled dot product attention (SDPA) and KV-cache quantization to prevent mobile operating system throttling40.

The result is a safety classifier capable of running entirely locally on a commodity Android CPU, achieving a time-to-first-token of under 2.5 seconds and a throughput of at least 30 tokens per second40.

User-Controlled Filtering and Opt-In Personalization

The deployment of edge AI safety models facilitates user-controlled filtering and opt-in personalization. Rather than a centralized platform dictating a universal moderation standard, users can download specific policy weights or fine-tune local models to align with their personal tolerances or cultural contexts. Because the moderation occurs on-device, the user's specific filtering preferences and the instances where their inputs trigger a flag are never transmitted to the central server. The moderation is strict, but the enforcement is entirely localized, eliminating the need for the platform to retain a record of rejected prompts or private mistakes.
In a comprehensive production environment, this manifests as a layered defense system. An input filter assesses the prompt locally. If benign, local instances of entity-recognition models (e.g., Presidio) sanitize the prompt, redacting Personally Identifiable Information (PII) before any data is transmitted to a cloud LLM41. Finally, an output filter evaluates the generated response locally before rendering it to the user, acting as a fail-safe catch-all for jailbreaks without exposing the interaction log to centralized auditing41.

Anonymous Credentials and Client-Side Age Controls

Often, the safety objective is not to verify the content of a message, but to verify the status of a user—such as ensuring they are human (anti-bot protection) or of legal age to access restricted content. Traditional age verification and anti-abuse systems rely on tracking cookies, IP address profiling, or the submission of government identification to the platform, creating massive databases of sensitive user attributes44.
Privacy Pass is an IETF-standardized protocol that replaces this surveillance with anonymous credentials. It employs blind signatures and zero-knowledge proofs to decouple the attestation of a credential from its presentation31. The architecture operates through three distinct roles:

1. The Attester: A trusted entity (such as a device's secure enclave or a government ID portal) verifies the user's attribute, such as their age or humanity.
2. The Issuer: Upon confirmation from the Attester, the Issuer blindly signs a cryptographic token generated by the client. Because the token is blinded, the Issuer cannot read its contents and cannot link the token to the specific user44.
3. The Origin: The target service accepts the unblinded token from the client as mathematical proof of the attribute44.

Apple's Private Access Tokens (PAT) and Cloudflare's Bot Management heavily rely on this architecture44. By substituting tracking mechanisms with mathematically verified anonymous tokens, platforms can enforce strict client-side age controls and mitigate DDoS attacks without ever learning the user's identity or profiling their browsing history. The Origin knows the user is verified, but learns nothing about who they are; the Attester knows who the user is, but learns nothing about which Origin they are visiting44.

Concrete Architecture Patterns for Safety Without Surveillance

To transition from theoretical cryptography to practical engineering, this section details three concrete architectural patterns that achieve legitimate safety objectives without retaining inquiry histories.

Pattern 1: Privacy-Preserving Threat Intelligence

Objective: Allow a web browser or operating system to check if a requested URL or downloaded file is malicious, without revealing the user's browsing history to the threat intelligence provider.

Pattern 2: Verifiable Content Moderation and Analytics

Objective: Enforce community guidelines in an end-to-end encrypted messaging or generative AI application, and gather telemetry on emerging threats, without the platform reading user communications.

Centralized Versus Decentralized Safety Architectures

A rigorous comparison reveals that decentralized, privacy-preserving architectures offer superior cybersecurity profiles while fulfilling the same fundamental safety mandates as traditional centralized systems.

Law Enforcement, Cybersecurity, and Institutional Challenges

While the technical mechanisms for safety without surveillance are viable, they introduce complex socio-technical trade-offs, particularly regarding institutional friction and technical overhead.
Transitioning to privacy-preserving architectures imposes computational and financial costs. OHTTP introduces network latency due to multi-hop routing and HPKE overhead17. PIR, while highly optimized via protocols like SimplePIR and ZipPIR, still requires substantial server-side memory bandwidth and CPU cycles compared to a simple plaintext database lookup23. For edge devices, running local safety models consumes battery power and limits functionality on older hardware that lacks neural processing units42. Consequently, there is an ongoing engineering tension between maximizing privacy and ensuring seamless user experiences in resource-constrained environments.
However, the most significant friction point is the interaction with law enforcement and the state. Intelligence and policing agencies argue that the eradication of centralized inquiry logs hinders their ability to retroactively investigate crimes4. If a platform does not log metadata or search histories, it cannot comply with a subpoena for a suspect's digital footprint.
This tension necessitates addressing the core question of this report: If a safety objective can be achieved without retaining a person's inquiry history, what legitimate reason exists to retain that history?
The technical evidence indicates that the retention of search histories, reading habits, and behavioral metadata is not a prerequisite for safety. Malware can be blocked via PIR and OHTTP; CSAM can be detected via Unbalanced PSI; abuse telemetry can be gathered via DAP and differential privacy; and local harms can be filtered via quantized edge AI. If all these protective outcomes are achieved, the centralized log ceases to serve a protective function for the platform or the user. Instead, the retention of that history serves only two purposes: the commercial commodification of behavioral data by data brokers, and the facilitation of retroactive dragnet surveillance by the state. Neither of these constitutes a legitimate safety objective.
Operating systems and platforms utilizing privacy partitioning and decentralized architectures effectively force law enforcement to return to targeted surveillance models. Rather than relying on corporate bulk intercept or purchasing warrantless data from commercial brokers, agencies must obtain traditional, particularized warrants to compromise specific endpoints or conduct targeted forensic investigations1. While this undeniably increases the friction of investigations, it realigns digital policing with the foundational tenets of civil liberties, eliminating the disproportionate societal and cybersecurity risks posed by mass surveillance2.

Conclusion

The false dichotomy that demands the sacrifice of intellectual privacy in exchange for digital safety is obsolete. The assumption that discovering harm requires watching everything a population thinks, searches, and reads is a failure of architectural imagination, rooted in legacy centralized computing models. As demonstrated by the robust synthesis of Oblivious HTTP, Private Information Retrieval, Distributed Aggregation Protocols, Unbalanced Private Set Intersection, and highly quantized edge AI models like Llama Guard, it is entirely technically feasible to protect users without subjecting them to systemic surveillance.
By systematically decoupling identity from inquiry, enforcing extreme data minimization, and utilizing zero-knowledge cryptographic proofs, platforms can deliver world-class threat intelligence, enforce rigorous community standards, and detect systemic abuse without ever constructing a centralized database of lawful behavior. When harms are intercepted at the edge, and telemetry is cryptographically blinded, the retention of a user's search history is stripped of its safety justification. Moving forward, the adoption of Safety Without Surveillance is no longer constrained by technological limitations, but by the institutional will to relinquish the unwarranted power of the panopticon.

Works cited

1. Mass surveillance - Grokipedia, https://grokipedia.com/page/Mass_surveillance
2. Nothing to Hide: The False Tradeoff Between Privacy and Security, https://www.researchgate.net/publication/228139465_Nothing_to_Hide_The_False_Tradeoff_Between_Privacy_and_Security
3. Orion Private LLC - Privacy Consulting, https://orionprivate.com/
4. (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
5. Carpenter v. United States | 585 U.S. ___ (2018), https://supreme.justia.com/cases/federal/us/585/16-402/
6. The Aftermath of Carpenter: An Empirical Study of Fourth, https://harvardlawreview.org/print/vol-135/the-aftermath-of-carpenter/
7. Carpenter v. United States - Wikipedia, https://en.wikipedia.org/wiki/Carpenter_v._United_States
8. [2110.07450] Bugs in our Pockets: The Risks of Client-Side Scanning, https://arxiv.org/abs/2110.07450
9. Walling Off Privacy: Apple's NeuralHash Controversy, the ECPA, the, https://scholar.law.colorado.edu/cgi/viewcontent.cgi?article=1033&context=ctlj
10. NeuralHash Collisions: The Limits of Apple's Image Hashing, https://blog.roboflow.com/neuralhash-collision/
11. Bugs in our Pockets: The Risks of Client-Side Scanning, https://www.semanticscholar.org/paper/Bugs-in-our-Pockets%3A-The-Risks-of-Client-Side-Abelson-Anderson/29c2bd88f7c7c83c94fb015b7397755182ee63de
12. Bugs in our pockets: the risks of client-side scanning, https://academic.oup.com/cybersecurity/article/10/1/tyad020/7590463
13. Bugs in our pockets: the risks of client-side scanning, https://academic.oup.com/cybersecurity/article-abstract/10/1/tyad020/7590463
14. RFC 9614: Partitioning as an Architecture for Privacy, https://www.rfc-editor.org/info/rfc9614/
15. RFC 9458: Oblivious HTTP, https://www.rfc-editor.org/info/rfc9458/
16. Oblivious HTTP explained - HTTP.DEV, https://http.dev/ohttp
17. Oblivious HTTP - Wikipedia, https://en.wikipedia.org/wiki/Oblivious_HTTP
18. Azure Confidential Inferencing with Oblivious HTTP, https://thomasvanlaere.com/posts/2026/06/azure-confidential-inferencing-with-oblivious-http/
19. Safe Browsing Oblivious HTTP Gateway API - Google for Developers, https://developers.google.com/safe-browsing/ohttp/reference
20. Distributional Private Information Retrieval - USENIX, https://www.usenix.org/system/files/usenixsecurity25-lehmkuhl.pdf
21. Faster FHE-Based Single-Server Private Information Retrieval, https://www.researchgate.net/publication/386575093_Faster_FHE-Based_Single-Server_Private_Information_Retrieval
22. A Brief Guide to Fully Homomorphic Encryption for Computer, https://www.sigarch.org/a-brief-guide-to-fully-homomorphic-encryption-for-computer-architects-part-i/
23. ZipPIR: High-throughput Single-server PIR without Client-side Storage, https://arxiv.org/html/2603.09190v1
24. Authenticated private information retrieval - NSF PAR, https://par.nsf.gov/servlets/purl/10421476
25. Simple and Fast Single-Server Private Information Retrieval, https://par.nsf.gov/servlets/purl/10428087
26. Peer2PIR: Private Queries for IPFS - arXiv, https://arxiv.org/html/2405.17307v2
27. Piano: Extremely Simple, Single-Server Private Information Retrieval, https://www.cs.cmu.edu/~csd-phd-blog/2024/piano-private-information-retrieval/
28. Practical keyword private information retrieval from key-to-index, https://ink.library.smu.edu.sg/cgi/viewcontent.cgi?article=11486&context=sis_research
29. USENIX Security '23 Technical Sessions, https://www.usenix.org/conference/usenixsecurity23/technical-sessions
30. NDSS Symposium 2026 Program, https://www.ndss-symposium.org/ndss-program/symposium-2026/
31. Cryptography as the Means to Protect Fundamental Human Rights, https://www.mdpi.com/2410-387X/5/4/34
32. Private Set Intersection in Two Extended Settings - Brown CS, https://cs.brown.edu/media/filer_public/32/f1/32f1278e-e603-43ba-9097-3f9ae39ea09d/maxtromanhauser.pdf
33. Identifying Harmful Media in End-to-End Encrypted Communication, https://www.usenix.org/system/files/sec21summer_kulshrestha.pdf
34. Deln0r/dap-go: Go-language implementation of the IETF ... - GitHub, https://github.com/Deln0r/dap-go
35. Prio | Stanford Applied Crypto Group, https://crypto.stanford.edu/prio/
36. Task Binding and In-Band Provisioning for DAP - IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-ietf-ppm-dap-taskprov-03
37. Oblivious HTTP now available on Divvi Up, https://divviup.org/blog/ohttp-now-available/
38. Privacy-Preserving Federated Learning Architecture for Multi-Tenant, https://datatracker.ietf.org/doc/draft-kale-agntcy-federated-privacy/02/
39. USENIX Security '25 Cycle 1 Accepted Papers, https://www.usenix.org/conference/usenixsecurity25/cycle1-accepted-papers
40. Llama Guard 3-1B-INT4: Compact and Efficient Safeguard for ... - arXiv, https://arxiv.org/html/2411.17713v1
41. Production AI Safety Guardrails: The Complete Guide - Blog, https://blog.prompt20.com/posts/production-safety-guardrails/
42. (PDF) Llama Guard 3-1B-INT4: Compact and Efficient Safeguard for, https://www.researchgate.net/publication/386210883_Llama_Guard_3-1B-INT4_Compact_and_Efficient_Safeguard_for_Human-AI_Conversations
43. Llama Guard 3-1B-INT4 - arXiv, https://arxiv.org/pdf/2411.17713
44. Privacy Pass: upgrading to the latest protocol version - Cloudflare Blog, https://blog.cloudflare.com/privacy-pass-standard/
45. Building a Multimodal Edge Application with Llama 3.2 ... - Lablab.ai, https://lablab.ai/ai-tutorials/building-a-multimodal-edge-application-with-llama-32-and-llama-guard