▸ Core

Privacy Model

Overview

The INCOG AI privacy model is a formal characterization of the privacy guarantees the protocol provides, the conditions under which those guarantees hold, and the threat vectors that remain outside the system's protection boundary. A precise privacy model is a prerequisite for honest security claims — without it, privacy "guarantees" are marketing assertions rather than architectural properties.

This document defines:

The information-theoretic properties the system provides
The adversary classes the system is designed to resist
The privacy guarantees in quantitative terms where possible
The conditions under which guarantees degrade
The explicit limitations of the privacy model

Privacy Properties

Unlinkability

Definition: An adversary cannot link two interactions performed by the same user across different sessions, origins, or time periods.

How it is achieved:

Per-session, per-origin fingerprint normalization seed rotation prevents fingerprint-based linkability
Storage partitioning prevents state-based linkability across origins
Relay path diversity and per-session path reconstruction prevents traffic-based linkability across sessions
Address rotation in the wallet module prevents on-chain transaction linkability

Conditions for property to hold:

The user does not authenticate with a real identity (login) at both ends of the link attempt
The adversary does not control both the user's entry relay node and the exit relay node
The user does not carry persistent behavioral patterns that survive normalization

Unobservability

Definition: An adversary cannot determine whether a specific user has accessed a specific resource or service.

How it is achieved:

Network-layer routing through the relay network prevents IP-based attribution of destination access
Encrypted DNS prevents domain-level access observation by ISPs
Relay network padding and timing normalization reduces traffic analysis correlation

Conditions for property to hold:

The relay network has sufficient concurrent users to provide a meaningful anonymity set
The adversary does not control both entry and exit relay nodes
The destination does not use advanced cross-site tracking (e.g., login-based tracking) that bypasses routing-layer anonymization

Pseudonymity

Definition: A user can establish a consistent identity within a specific context (e.g., a logged-in application session) without that identity being linkable to their real-world identity or to their identity in other contexts.

How it is achieved:

Context-scoped storage isolation allows per-site pseudonymous identities
Wallet address rotation allows pseudonymous on-chain interaction
Relay routing prevents IP-based attribution to the pseudonymous identity

Conditions for property to hold:

The user does not voluntarily disclose real-world identity to the service
The pseudonymous identity is not linked to a real-world identity through behavioral patterns observable by the service

Adversary Classes

The privacy model is defined against four adversary classes of increasing capability:

Class 1: Passive Network Observer

Capability: Can observe network traffic between any two specific network points. Cannot observe encrypted content. Examples: ISP, CDN, network-level traffic analysis.

Defenses:

Encrypted relay routing prevents destination attribution from network observation
Encrypted DNS prevents domain-level observation
Traffic padding reduces metadata leakage from packet analysis

Limitations: This adversary class is the primary target of the relay network. The relay network provides strong protection against Class 1 adversaries with a sufficient anonymity set.

Class 2: Active Site Fingerprinter

Capability: Can execute arbitrary JavaScript in the user's browser context, access browser APIs, set and read cookies, and attempt to correlate visits across time through fingerprinting. Examples: first-party tracking scripts, analytics platforms, advertising infrastructure.

Defenses:

API surface normalization reduces fingerprint entropy
Storage partitioning prevents cross-session cookie and storage-based tracking
Telemetry blocking prevents behavioral data transmission
Referrer and header normalization reduces passive fingerprinting signal

Limitations: The browser layer provides strong protection against Class 2 adversaries. A sophisticated fingerprinter employing novel API combinations may detect normalization artifacts; the browser's normalization strategy must evolve to address novel fingerprinting techniques.

Class 3: Compromised Relay Node Operator

Capability: Controls one or more relay nodes in the network. Can observe traffic metadata at controlled nodes — IP addresses of adjacent hops, timing, volume. Cannot decrypt traffic content (protected by layered encryption). Cannot observe traffic at non-controlled nodes.

Defenses:

Multi-hop routing ensures no single compromised node gains full routing visibility
Path construction policies (operator diversity, jurisdictional diversity) minimize the probability that an adversary's nodes appear in multiple positions in the same path
Guard node pinning for entry nodes limits the probability of a malicious entry node

Limitations: The relay network provides probabilistic protection against Class 3 adversaries proportional to the fraction of the network they control. An adversary controlling more than approximately 33% of relay capacity in a specific network region can perform statistical deanonymization attacks with significant probability. This is an inherent limitation of the relay model that is mitigated but not eliminated by protocol design.

Class 4: Global Passive Adversary

Capability: Can observe all network traffic globally simultaneously. This is a theoretical adversary class approximated by nation-state surveillance programs with access to multiple backbone providers.

Defenses: The relay network does not provide strong anonymity against a true global passive adversary. Traffic volume correlation across sufficient network observation points can identify relay flows with non-negligible probability.

Limitations: This is an explicit out-of-scope threat. The protocol does not claim to protect against global passive adversaries. Users facing surveillance from adversaries with these capabilities require additional countermeasures (e.g., bridge relays, additional hop counts, significantly higher timing jitter budgets) beyond the default INCOG configuration.

Anonymity Set Analysis

The privacy guarantees of the relay network are inherently set-theoretic: a user's privacy is a function of the size of the set of users they are indistinguishable from. A network with 10 users provides significantly weaker anonymity than a network with 100,000 users, even if the routing protocol is identical.

Current Anonymity Set Limitations

In the early deployment phase, the INCOG relay network will have a limited user base. This creates a privacy bootstrapping problem: the privacy guarantees are weakest precisely when the network is smallest. The protocol acknowledges this limitation and recommends:

Users with high threat models (journalists, activists, whistleblowers) should supplement INCOG with established larger-anonymity-set networks during the early deployment phase
INCOG's primary early-phase value proposition is fingerprint resistance and telemetry blocking (browser layer), which does not depend on network size
The relay layer's privacy properties improve monotonically as the user base grows

Anonymity Set Growth

The relay network's anonymity set grows with:

Increasing numbers of simultaneous relay users
Increasing geographic and topological diversity of relay paths
Increasing cover traffic density (where implemented)

The $INCOG token incentive model is designed in part to accelerate this growth by making node operation economically attractive, thereby expanding the network faster than a volunteer-only model would achieve.

Metadata Leakage Vectors (Residual)

Even within the scope of the system's protection boundary, certain metadata leakage vectors remain. Users should be aware of these residual vectors:

Application-Layer Correlation

If a user logs into a service using their real identity while using the INCOG Browser with relay routing, the service operator gains a direct link between the user's application-layer identity and their browsing behavior on that service, regardless of routing protection. The protocol does not protect against voluntary identity disclosure.

Behavioral Analysis

A sufficiently sophisticated observer with access to multiple data points — including the content of interactions, not just metadata — can potentially identify users through behavioral patterns that survive fingerprint normalization. Highly distinctive writing styles, search query patterns, or application behavior may constitute a de-anonymizing signal in some threat models.

Exit Node Traffic Inspection

For non-HTTPS destinations, the exit node can observe traffic content. The protocol strongly recommends using INCOG routing only with HTTPS destinations. The browser will warn when relay routing is active and a non-HTTPS destination is accessed.

Relay Directory Queries

Clients querying the relay directory to obtain routing information expose their IP address to the directory service. Directory queries are performed through a separate privacy-preserving channel to mitigate this, but the directory query channel itself has privacy limitations in the current protocol version.

Forward-Looking Privacy Extensions

The INCOG privacy model is designed with extensibility toward stronger privacy-preserving techniques as they mature:

Zero-Knowledge Relay Verification

Current relay verification relies on cryptographic attestations that reveal relay participation metadata. Future protocol versions will explore zk-SNARK-based attestations that allow verification of relay participation without disclosing the underlying participation metrics, further reducing the information footprint of the reward verification system.

Private Information Retrieval for Directory

The relay directory currently requires IP-observable queries. Future versions will implement private information retrieval (PIR) schemes for directory access, allowing clients to obtain relay node information without revealing which nodes they are querying.

Mixnet-Compatible Architecture

The current relay protocol is designed to be compatible with mixnet-style routing in a future protocol upgrade. Mixnets provide significantly stronger anonymity than onion routing by introducing batching and reordering of messages, at the cost of additional latency. The protocol architecture is designed to support this upgrade without requiring a complete relay infrastructure redesign.

View original documentation