Threat Model
Overview
The INCOG AI threat model is a systematic analysis of the adversaries the protocol is designed to resist, the attack vectors each adversary might employ, the protocol's mitigations for each vector, and the explicit limitations of those mitigations. A rigorous threat model is the foundation of any honest privacy claim — without specifying the adversary and the attack, "privacy protection" is a meaningless assertion.
This document follows the structure: adversary → capability → attack vector → mitigation → residual risk. It covers all major attack categories against the protocol's privacy properties and addresses both current mitigations and areas where the protocol's protections are incomplete.
Threat Category 1: Network Surveillance
Adversary Profile: Passive Network Observer
Capabilities:
- Observe all traffic on monitored network links
- Log IP addresses, packet sizes, timing, volume
- Perform statistical analysis on traffic streams
- Cannot decrypt encrypted traffic content
- Cannot actively modify traffic (passive only)
Attack Vector 1.1: IP-Destination Correlation
Description: By observing traffic between a user's device and network destinations, a passive observer can directly learn which servers the user is communicating with, even without decryption.
Mitigation: Relay routing prevents direct IP-destination association. The observer sees traffic from the user's IP to the entry relay node's IP only. The destination is not observable at this network boundary.
Residual risk: The entry relay node IP is observable. An adversary correlating entry relay node IP with knowledge that this IP is an INCOG relay node learns that the user is using an anonymization network — a weaker disclosure than the actual destination but potentially meaningful in high-censorship environments.
Attack Vector 1.2: Traffic Volume and Timing Correlation
Description: A global passive adversary observing both the link between the user and the entry node, and the link between the exit node and the destination, can attempt to correlate traffic patterns — matching volume, timing, and packet rate fingerprints across both links to identify the user despite relay routing.
Mitigation:
- Fixed-size cell padding prevents size-based correlation
- Configurable timing jitter disrupts timing correlation
- Multiple active streams multiplexed on single circuit create noise
Residual risk: Against a true global passive adversary with high link coverage, timing correlation remains a viable (though statistically demanding) attack. The protocol provides probabilistic resistance proportional to the timing jitter budget. High-sensitivity users should use maximum jitter settings, accepting the latency cost.
Attack Vector 1.3: DNS Leakage
Description: Unencrypted DNS queries expose destination domains to ISPs and network observers, even when traffic is otherwise encrypted. DNS leakage can reveal browsing intent without packet content.
Mitigation: All DNS resolution is performed via DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT). DNS queries are encrypted and cannot be read by ISP-level observers.
Residual risk: The DoH resolver observes all DNS queries. Users should select a resolver with verifiable no-logging policies. The protocol's default resolver selection prioritizes privacy-committed resolvers, but users with high threat models should audit the resolver choice.
Attack Vector 1.4: Connection Timing Fingerprinting
Description: The timing pattern of connection establishments — when a user initiates connections, how long they last, how frequently they connect — can serve as a behavioral fingerprint that persists even with relay routing.
Mitigation: Circuit pre-building masks individual connection establishment events. Session timing randomization disrupts temporal pattern analysis.
Residual risk: Distinctive connection timing patterns (e.g., highly regular or distinctive intervals) can survive current mitigation at sufficient traffic analysis depth. Cover traffic is the most effective countermeasure; it is planned for implementation at sufficient network scale.
Threat Category 2: Browser Fingerprinting
Adversary Profile: Active Web Fingerprinter
Capabilities:
- Execute arbitrary JavaScript in the user's browser context
- Access all standard browser APIs
- Set and read cookies and other storage
- Communicate fingerprint data to external collection servers
- Correlate fingerprints across sessions and origins
Attack Vector 2.1: Canvas Fingerprinting
Description: The HTMLCanvasElement.toDataURL() API renders a scene whose output varies subtly based on GPU driver, font rendering engine, and OS-level compositing differences. The resulting pixel data is highly unique to specific hardware/software combinations.
Mitigation: Canvas API output is intercepted at the engine level and a deterministically randomized value is returned, derived from a session-scoped normalization seed. The returned value is consistent within a session (to avoid breaking legitimate canvas uses) but varies across sessions.
Residual risk: The normalization approach is detectable if an observer attempts to detect the presence of normalization (by testing whether the canvas output matches known rendering baselines for claimed browser/OS). The protocol's defense is population-based indistinguishability: the normalized values should be indistinguishable from a real browser's output on some real hardware configuration.
Attack Vector 2.2: WebGL Fingerprinting
Description: WebGL API calls expose GPU vendor strings, renderer strings, and shader precision values that are highly hardware-specific and stable across sessions.
Mitigation: WebGL parameters are normalized to values from a curated table of real GPU/driver combinations. The browser returns real-looking (but potentially non-matching) GPU parameters.
Residual risk: Cross-referencing claimed GPU parameters against observable rendering performance could reveal inconsistencies between claimed and actual hardware in some cases. This attack requires active behavioral testing beyond passive API observation.
Attack Vector 2.3: AudioContext Fingerprinting
Description: The Web Audio API's oscillator and analyser outputs vary based on the hardware audio stack implementation, producing consistent, hardware-unique numerical outputs.
Mitigation: AudioContext outputs are normalized by adding a controlled, session-stable noise value before returning results to JavaScript.
Residual risk: The normalization approach is effective against passive fingerprinting. Active detection of normalization artifacts through statistical analysis of multiple samples is a theoretical attack that would require significant sampling effort per target.
Attack Vector 2.4: Font Enumeration
Description: The presence or absence of specific fonts can be detected by measuring text rendering dimensions. The specific font set installed on a system is system-configuration-dependent and contributes to fingerprinting.
Mitigation: Text dimension measurements from the browser's layout engine are normalized. Generic font family fallbacks are returned for font metric queries.
Residual risk: Sophisticated font enumeration via CSS font-face loading behavior or timing of font loading can partially circumvent rendering-dimension normalization. The protocol addresses the most common font enumeration techniques; novel approaches require ongoing monitoring and countermeasure development.
Attack Vector 2.5: Storage-Based Persistent Tracking
Description: Cookies, localStorage, IndexedDB, and other browser storage can persist identifiers across sessions, providing explicit, stable cross-session tracking that survives fingerprint normalization.
Mitigation: All storage is partitioned per-origin and per-session. No storage state persists across session boundaries by default. Cross-origin storage access is blocked.
Residual risk: Explicitly authenticated sessions (where the user logs in) create explicit persistent identity linkage that the storage partitioning model does not address. Authenticated identity is a voluntary disclosure outside the protocol's privacy model.
Attack Vector 2.6: Cross-Origin Correlation via Shared Resources
Description: Third-party resources loaded from a common CDN origin across multiple sites can set and read cookies from that origin, linking visits across sites into a unified profile.
Mitigation: Storage partitioning isolates third-party storage by (top-level-origin, third-party-origin) pairs. A third-party CDN cannot link its storage across different top-level sites visited by the same user.
Residual risk: Performance timing of third-party resource loading can still reveal whether specific resources are cached, enabling cache-timing-based cross-origin linking. Cache partitioning addresses the most direct form of this attack but timing-based variants remain a partial concern.
Threat Category 3: Relay Network Attacks
Adversary Profile: Malicious Relay Operator
Capabilities:
- Operate one or more relay nodes in the INCOG network
- Observe traffic metadata at controlled nodes (adjacent IPs, timing, volume)
- Attempt to influence circuit routing through directory manipulation
- Cannot decrypt layered-encrypted traffic content at controlled nodes
Attack Vector 3.1: End-to-End Traffic Correlation
Description: An adversary controlling both the entry and exit nodes of a relay circuit observes the client's real IP (at entry) and the destination (at exit). By correlating traffic timing and volume across both endpoints, the adversary can link the client to the destination.
Mitigation:
- Path construction policies prevent selection of nodes operated by the same registered operator in entry and exit positions
- Jurisdictional diversity constraints reduce co-operation among geographically co-located operators
- Traffic padding and timing jitter reduce correlation accuracy
Residual risk: If the adversary can circumvent operator identity detection (Sybil attack with diverse-appearing registrations), or if the adversary controls nodes in both entry and exit positions through different legal entities, correlation remains possible. Timing jitter reduces but does not eliminate this risk.
Attack Vector 3.2: Selective Denial of Service
Description: A malicious node operator selectively drops or delays traffic for specific circuits, attempting to force circuit reconstruction through alternative paths that the adversary controls or observes.
Mitigation: Circuit health monitoring detects elevated failure rates for specific nodes. Nodes with elevated failure rates are removed from the relay directory, preventing future circuit construction through them.
Residual risk: A sophisticated adversary could selectively degrade only a subset of circuits (avoiding detection thresholds) to influence which circuits users reconstruct through. This attack requires significant operational sophistication.
Attack Vector 3.3: Directory Manipulation
Description: A compromised or malicious directory authority could publish false relay directory information — including malicious nodes, false capability information, or modified geographic metadata that undermines path diversity.
Mitigation: The threshold signature scheme for directory signing requires a majority of directory authorities to agree on a signed snapshot. A single compromised authority cannot publish a forged directory. Clients verify the threshold signature before trusting directory contents.
Residual risk: If a majority of directory authorities are compromised or colluding, the directory can be manipulated. The number and diversity of directory authorities is a critical security parameter — more authorities with diverse organizational affiliations reduce this risk.
Attack Vector 3.4: Sybil Attack on Relay Network
Description: An adversary registers a large number of relay nodes under different identities to gain control over a significant fraction of relay capacity, increasing the probability that their nodes appear in both entry and exit positions of a circuit.
Mitigation:
- Token holding requirement creates economic cost per node registration
- Cross-attestation throughput verification requires real bandwidth consumption
- Geographic diversity requirements limit single-region concentration
- AS diversity analysis detects nodes originating from a common infrastructure
Residual risk: A well-resourced adversary with sufficient token holdings and infrastructure can operate a significant number of relay nodes. The protocol mitigates but cannot eliminate Sybil risk without compromising accessibility.
Threat Category 4: Application-Layer Attacks
Adversary Profile: Malicious or Compromised Web Application
Capabilities:
- Execute JavaScript in the user's browser context
- Make network requests with the user's browser identity
- Attempt to exfiltrate information through available channels
Attack Vector 4.1: JavaScript-Based Fingerprinting
Description: Web application scripts attempt to enumerate browser API responses to construct a fingerprint, despite normalization mitigations.
Mitigation: API surface normalization at the engine level — not through content script injection — prevents web content from observing real API values.
Residual risk: Novel fingerprinting techniques exploiting previously unaddressed API surfaces require ongoing detection and mitigation. The protocol's normalization must evolve with the fingerprinting landscape.
Attack Vector 4.2: Behavioral Fingerprinting
Description: Beyond static API values, observable user behavior patterns — typing rhythm, mouse movement patterns, interaction timing — can potentially serve as identifying signals.
Mitigation: The INCOG Browser does not currently implement behavioral biometric normalization. This is an explicitly acknowledged limitation.
Residual risk: Users who interact with web applications in highly distinctive ways may be susceptible to behavioral fingerprinting that survives API normalization. This attack requires the adversary to have both historical behavioral samples and current session access — a more demanding requirement than passive fingerprinting.
Attack Vector 4.3: Cross-Context Leakage via Timing
Description: A malicious script can use high-resolution timing to probe whether specific resources are cached, inferring browsing history across contexts.
Mitigation: Cache partitioning prevents cross-context cache sharing. performance.now() resolution is clamped to reduce timing attack precision.
Residual risk: Sufficiently high-precision timing attacks against other system resources (e.g., CPU cache occupancy) can partially survive browser-level countermeasures. Microarchitectural timing attacks are a general class of browser security risk beyond the scope of privacy-specific mitigations.
Out-of-Scope Threats
The following threat categories are explicitly outside the INCOG protocol's protection boundary:
Physical device compromise: An adversary with physical access to the user's device can extract session keys, wallet keys, and browsing history from memory or persistent storage. The protocol does not protect against physical device attacks.
Endpoint malware: Malware running on the user's device can observe all activity before encryption is applied. The relay network and browser isolation model assume a non-compromised client device.
Global passive adversary: A theoretical adversary observing all network traffic simultaneously can perform traffic correlation attacks that no relay network with finite timing jitter can fully resist.
Voluntary identity disclosure: If a user logs into a service with their real identity while using INCOG tools, the service gains a binding between their real identity and their current session's activity. The protocol cannot protect against voluntary identity disclosure.
Legal compulsion: A relay node operator who receives a valid legal demand for traffic logs faces the same compliance obligation as any other infrastructure operator. The protocol mitigates the impact of such demands by ensuring that relay node operators genuinely have no traffic content or origin-destination metadata to disclose, but cannot prevent legal demands from being issued.
Security Review and Ongoing Assessment
The threat model is a living document. As the protocol is deployed, new attack techniques emerge, and the threat landscape evolves, the threat model will be updated to reflect new adversary capabilities and new protocol mitigations.
The protocol team conducts:
- Periodic internal threat model reviews
- Independent external security audits of the relay protocol and browser modifications
- Public bug bounty programs for novel attack disclosures
Responsible disclosure of novel attacks against the INCOG protocol is strongly encouraged. Researchers who identify previously undocumented attack vectors should contact the protocol security team directly before public disclosure.