▸ Core

Browser Layer

Overview

The INCOG Privacy Browser is a hardened browsing client built on the principle that privacy cannot be achieved by layering restrictions onto a surveillance-optimized foundation. The browser is designed from the execution model upward, treating every API surface as a potential leakage vector until proven otherwise.

The browser layer addresses three distinct categories of privacy degradation:

Active fingerprinting — deliberate enumeration of browser characteristics by tracking scripts
Passive fingerprinting — extraction of identifying information from standard browser behaviors
Session and cross-origin linkability — the accumulation and correlation of behavioral state across sites and sessions

Fingerprint Entropy Reduction

The Fingerprinting Surface

Modern browsers expose a composite fingerprint assembled from dozens of individually low-entropy signals that combine into a highly unique identifier. The EFF's Panopticlick research demonstrated that over 80% of browsers carry a fingerprint unique within a dataset of millions. Contemporary fingerprinting techniques have only grown more sophisticated.

Primary fingerprinting vectors include:

Rendering-based signals

HTMLCanvasElement.toDataURL() — renders text and shapes to a canvas; GPU driver variations, font rendering differences, and anti-aliasing implementations produce pixel-level variations unique to hardware/OS combinations
WebGL getParameter(), getShaderPrecisionFormat() — GPU vendor, renderer string, and precision values expose hardware identity
CSS rendering behaviors — overflow handling, sub-pixel rendering, and compositing differ across platforms

Hardware and system signals

navigator.hardwareConcurrency — logical processor count
navigator.deviceMemory — approximate RAM in GB
screen.width, screen.height, screen.colorDepth, window.devicePixelRatio — display configuration
navigator.platform, navigator.userAgent, navigator.appVersion — OS and browser identity

API availability signals

Feature detection for APIs (e.g., WebAuthn, WebBluetooth, WebUSB) creates a distinct capability fingerprint
Font enumeration via canvas rendering or @font-face probing
Battery status API (where available)

Behavioral signals

performance.now() resolution — OS and browser-specific timer precision
AudioContext timing — hardware audio stack variations
WebRTC RTCPeerConnection — can expose local IP addresses and NAT topology

Normalization Strategy

The INCOG Browser does not simply block fingerprinting APIs, which itself creates a detectable signal ("this browser blocks canvas fingerprinting"). Instead, the browser applies systematic normalization: API responses are modified to return values consistent with a large population of legitimate browsers, making the INCOG Browser fingerprint statistically indistinguishable from the general population.

Normalization is applied at the browser engine level, not through JavaScript injection or extension-based overrides, which are themselves detectable. Engine-level normalization means:

Canvas API responses return deterministic, session-stable values derived from a randomized seed established at session initialization, not from actual hardware rendering
WebGL parameters return values from a curated table of common GPU/driver combinations
navigator.* attributes are normalized to a set of common values representing the largest browser populations
screen.* properties are adjusted to common display configurations
performance.now() precision is clamped to reduce timing attack viability

The normalization seed changes per session and per origin, preventing cross-session and cross-origin fingerprint correlation even if an observer controls multiple sites.

Telemetry Blocking

The Telemetry Pipeline

Modern web properties embed multiple layers of telemetry infrastructure:

First-party analytics: Session duration, navigation paths, click coordinates, scroll depth, form interaction patterns
Third-party analytics platforms: Google Analytics, Segment, Amplitude, Mixpanel — behavioral event streams transmitted to external processors
Advertising infrastructure: Demand-side platforms, retargeting pixels, conversion tracking endpoints
Error monitoring: Sentry, Datadog RUM, Bugsnag — JavaScript error context including URL, user agent, and session identifiers
Session recording: FullStory, Hotjar, LogRocket — pixel-accurate reconstructions of user sessions including keystrokes, mouse movements, and DOM state

Each of these systems constitutes a distinct data extraction pipeline operating on user behavioral data without meaningful consent or transparency.

Request-Layer Interception

The INCOG Browser implements telemetry blocking at the network request layer, prior to any JavaScript execution. This approach is more robust than content-script-based blocking because:

Blocking at the request level prevents any data from leaving the browser
It is not susceptible to circumvention via dynamically constructed request URLs
It does not depend on maintaining lists of tracking domain signatures, though such lists are incorporated as one signal

The blocking engine operates on:

Request URL patterns matched against known telemetry endpoint signatures
Request destination analysis (third-party requests carrying session identifiers)
Request payload inspection for known analytics event schemas
Response header analysis for tracking pixel patterns

First-Party Telemetry Containment

Third-party telemetry is relatively straightforward to block by origin. First-party telemetry — analytics endpoints operated by the same domain as the visited site — requires a different approach.

The INCOG Browser applies containment policies to first-party telemetry by:

Intercepting known analytics SDK request patterns regardless of domain
Blocking requests that match behavioral telemetry schemas (event payloads containing session identifiers, interaction coordinates, or navigation context)
Applying storage isolation to prevent first-party analytics from accumulating cross-session profiles

Referrer and Header Minimization

HTTP request headers constitute a significant metadata leakage vector. The Referer header exposes navigation history. Accept-Language and Accept-Encoding contribute to fingerprinting. Cookie headers carry persistent identifiers across requests.

The INCOG Browser applies:

Referrer stripping or normalization to origin-only for cross-origin navigation
Accept-Language normalization to reduce language-based fingerprinting
Strict cookie scoping and isolation per browsing context

Session-Level Isolation

The Linkability Problem

The fundamental privacy problem with persistent browser state is not any individual piece of data — it is the ability of observers to link interactions across time and across sites into a unified behavioral profile. Cookies, IndexedDB, localStorage, sessionStorage, cache entries, service workers, and HTTP authentication state all contribute to a persistent identity that survives browser restarts and accumulates across sites.

Per-Context Storage Partitioning

The INCOG Browser implements strict per-context storage partitioning. Each browsing context — defined as a combination of origin and session — operates with a completely isolated storage environment:

Cookies are scoped to the originating context and not shared across tabs or windows
localStorage and sessionStorage are partitioned per origin per session
IndexedDB namespaces are isolated per context
Cache entries are context-local
Service workers are not permitted to operate across contexts

This partitioning model means that even if a user visits the same site in two different tabs, those tabs cannot share state or be linked to a common user identity by the site's servers.

Session Lifecycle

Sessions in the INCOG Browser are explicitly bounded. A session begins at browser launch or explicit session initiation and terminates at browser close or explicit session termination. At session termination:

All volatile storage (cookies, sessionStorage, in-memory state) is cleared
Persistent storage modifications within the session are reviewed against retention policies
The fingerprint normalization seed is rotated for the subsequent session

Cross-Origin State Prevention

Beyond storage isolation, the INCOG Browser prevents cross-origin state leakage through:

Strict cross-origin resource policy enforcement
Prevention of cross-origin window references and message passing that could be used for synchronization
Cache partitioning that prevents cache-timing attacks for cross-origin resource detection
Strict CSP defaults applied to all browsing contexts

Execution Sandboxing

Isolation Architecture

Each browsing context in the INCOG Browser runs in an isolated execution environment. JavaScript execution within one context cannot observe or influence the execution environment of another context, even when both are operated by the same user in the same browser session.

This isolation is enforced at the process level where architecturally feasible, with each origin context mapped to an isolated process with its own memory space and JavaScript engine instance. The security boundary between contexts is enforced by the OS process isolation model rather than solely by language-level sandboxing.

Extension and Plugin Surface Reduction

Browser extensions represent a significant attack surface for both fingerprinting (extension presence is detectable via content script injection patterns) and privacy degradation (extensions can exfiltrate browsing data). The INCOG Browser:

Operates a hardened extension permission model that requires explicit justification for access to browsing data
Surfaces extension API calls that would access cross-origin data for user review
Does not permit extensions to modify request headers or content in ways that would degrade privacy properties

JavaScript API Hardening

Several JavaScript APIs that are not commonly used for legitimate application purposes but are frequently exploited for tracking and fingerprinting are restricted or virtualized:

Battery Status API: returns constant values to prevent hardware state fingerprinting
Network Information API: returns normalized values
Sensor APIs (ambient light, motion, orientation): access requires explicit user permission and is session-scoped
window.name: cleared on cross-origin navigation to prevent use as a cross-origin communication channel
document.referrer: normalized to prevent leakage of internal navigation history

DNS and Network Privacy

Encrypted DNS

All DNS resolution in the INCOG Browser is performed via DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT), preventing ISP-level visibility into destination resolution. The resolver endpoint is configurable, with a curated default that prioritizes resolver operators with strong privacy commitments and verifiable no-log policies.

WebRTC Isolation

WebRTC's ICE candidate gathering process can expose local network topology and real IP addresses even through a VPN or proxy. The INCOG Browser:

Disables WebRTC by default in relay-routed contexts
When WebRTC is permitted, applies ICE candidate filtering to prevent local IP exposure
Routes WebRTC relay candidates through the INCOG Mesh when the user is connected

Certificate Transparency and TLS Validation

The browser enforces strict TLS certificate validation with Certificate Transparency log checking, reducing susceptibility to man-in-the-middle attacks by fraudulent or compromised certificate authorities.

View original documentation