Back to Blog
Identity

Why Incognito Mode Does Not Protect Against Fingerprinting

Incognito mode clears cookies but leaves your browser fingerprint unchanged. Learn why private browsing is not enough for real privacy.

Introduction

Most users assume that incognito mode (or "private browsing") makes them invisible online. In reality, incognito mode only prevents the browser from saving local data: history, cookies, and form entries are not stored. Your browser fingerprint, which includes Canvas rendering, WebGL characteristics, audio processing, font availability, screen dimensions, and dozens of other signals, remains completely unchanged. Worse, incognito mode changes certain browser behaviors in ways that make the incognito session itself identifiable.

BotBrowser takes a fundamentally different approach. Instead of running in a private browsing mode with detectable limitations, BotBrowser profiles present a complete, normal browser environment with controlled fingerprint signals. This article explains what incognito mode actually does (and does not do), why it can make you more visible, and how BotBrowser provides real identity control.

Privacy Impact

The gap between what users expect from incognito mode and what it actually provides is significant:

What incognito mode does:

  • Does not save browsing history
  • Does not persist cookies after the session closes
  • Does not save form data
  • Isolates the session from regular browsing data

What incognito mode does NOT do:

  • Does not change your browser fingerprint
  • Does not change your IP address
  • Does not protect against fingerprint-based tracking
  • Does not prevent websites from identifying you during the session
  • Does not change your User-Agent, screen size, or hardware characteristics

The false sense of security from incognito mode is itself a privacy risk. Users who believe they are protected may take fewer precautions, while their fingerprint is fully visible to tracking systems.

Additionally, incognito mode creates artifacts that distinguish it from normal browsing. Storage quota values, API availability, and certain browser behaviors differ in incognito sessions. These differences mean that being in incognito mode is itself a piece of identifying information.

Technical Background

How Incognito Mode Changes Browser Behavior

When a browser enters incognito mode, several internal behaviors change:

Storage quota: In incognito mode, browsers typically report reduced storage quota. navigator.storage.estimate() returns different values compared to a normal session. The specific quota values vary by browser version, but the reduction is a consistent signal.

FileSystem API: Historically, the window.requestFileSystem API (or window.webkitRequestFileSystem) behaved differently in incognito mode. While modern Chrome has addressed some of these differences, subtle behavioral variations remain.

Service workers: Incognito mode has a different service worker lifecycle. Service workers registered in incognito are not persisted. The registration behavior and storage persistence differ from normal mode.

IndexedDB and localStorage: While these APIs are available in incognito, their storage limits and error behavior may differ. Some browsers throttle IndexedDB operations in private mode.

Performance characteristics: Memory management and cache behavior differ in incognito mode. These differences can affect timing measurements and performance metrics.

The Fingerprint Remains Identical

Despite all the behavioral changes above, the core fingerprint signals remain the same in incognito mode:

  • Canvas rendering: The same hardware produces the same Canvas hash
  • WebGL: The same GPU reports the same vendor, renderer, and rendering output
  • Audio processing: The same audio hardware produces the same AudioContext fingerprint
  • Screen dimensions: The same monitor reports the same resolution
  • Navigator properties: CPU cores, memory, platform, and language are unchanged
  • Fonts: The same fonts are installed
  • Client Hints: The same User-Agent and Client Hints are sent

This means that a user who visits a site in normal mode and then visits in incognito mode produces the same fingerprint. The tracking system can correlate the two visits through fingerprint matching, regardless of the incognito session.

The "Incognito Signal"

The behavioral differences listed above create what can be called an "incognito signal." A tracking system that observes reduced storage quota, different FileSystem API behavior, or other incognito-specific artifacts knows the user is in private browsing mode.

This signal has two implications:

  1. Population segmentation: Users in incognito mode are a minority of all browser sessions. Being identified as an incognito user places you in a smaller population, which makes your fingerprint more distinctive.

  2. Intent signaling: Users who enable incognito mode are actively trying to protect their privacy. This intent itself is a behavioral signal that tracking systems can factor into their models.

Common Approaches and Their Limitations

Incognito Mode Alone

As described above, incognito mode does not change the fingerprint and creates detectable artifacts. It protects against local data persistence (useful for shared computers) but provides no protection against fingerprint-based tracking.

Incognito Mode with Extensions

Adding privacy extensions to incognito mode (like Canvas blockers or fingerprint randomizers) introduces additional detectable artifacts. Extension-based fingerprint modification is visible through prototype chain inspection, timing anomalies, and missing or altered API properties.

Incognito Mode with VPN

A VPN changes your IP address, which addresses one aspect of tracking. But the fingerprint, including the incognito-specific artifacts, remains unchanged. The combination protects IP-based tracking but not fingerprint-based tracking.

Tor Browser

Tor Browser takes a more aggressive approach by normalizing many fingerprint signals to match a common baseline. However, the Tor Browser fingerprint is itself distinctive. The specific combination of settings (letterboxing, disabled WebGL, NoScript, etc.) identifies the user as a Tor Browser user, which is a small population.

Profile-Based Approach (BotBrowser)

BotBrowser does not use incognito mode. Each session runs as a standard browser instance with full API access, normal storage quotas, and complete service worker support. The fingerprint is controlled through the profile, not through mode restrictions.

BotBrowser's Approach

Normal Browser Mode with Controlled Identity

BotBrowser sessions are regular (non-incognito) browser sessions. This is a deliberate design choice:

chrome --bot-profile="/path/to/profile.enc" \
       --user-data-dir="$(mktemp -d)"

The session has:

  • Normal storage quota: navigator.storage.estimate() returns values consistent with a regular browsing session
  • Full API availability: All browser APIs work as expected, including FileSystem, Service Workers, and IndexedDB
  • Standard behavior: No incognito-specific artifacts are present
  • Controlled fingerprint: Canvas, WebGL, audio, navigator, screen, and font signals are all defined by the profile

Profile-Defined Identity

BotBrowser profiles represent complete, real browser environments captured from actual devices. When you load a profile, the browser presents signals consistent with that device:

  • Canvas rendering produces the profile's expected hash
  • WebGL reports the profile's GPU vendor and renderer
  • Audio processing matches the profile's audio characteristics
  • Screen dimensions, color depth, and pixel ratio match the profile
  • Navigator properties (CPU cores, memory, platform) are consistent with the profile's device

This is fundamentally different from incognito mode, which exposes your real hardware through an unmodified fingerprint.

Session Isolation Without Incognito

BotBrowser achieves session isolation through --user-data-dir, not through incognito mode:

# Session 1 - isolated data directory
chrome --bot-profile="/profiles/profile-a.enc" \
       --user-data-dir="/data/session-1"

# Session 2 - separate data directory
chrome --bot-profile="/profiles/profile-b.enc" \
       --user-data-dir="/data/session-2"

Each session has its own cookies, localStorage, IndexedDB, and cache without the behavioral artifacts that incognito mode introduces.

For temporary sessions that should not persist data, use a temporary directory:

chrome --bot-profile="/path/to/profile.enc" \
       --user-data-dir="$(mktemp -d)"

The temporary directory is deleted when the system cleans up temp files, achieving the same data non-persistence as incognito mode without the detectable artifacts.

Configuration and Usage

Basic Non-Incognito Setup

chrome --bot-profile="/path/to/profile.enc" \
       --user-data-dir="$(mktemp -d)" \
       --proxy-server=socks5://user:pass@proxy:1080

Playwright Integration

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
      '--proxy-server=socks5://user:pass@proxy:1080',
    ],
    headless: true,
  });

  const context = await browser.newContext();
  const page = await context.newPage();
  await page.goto('https://example.com');

  // Verify normal (non-incognito) behavior
  const quota = await page.evaluate(async () => {
    const est = await navigator.storage.estimate();
    return est.quota;
  });
  console.log('Storage quota:', quota);
  // Returns a normal quota value, not the reduced incognito value

  await browser.close();
})();

Puppeteer Integration

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
    ],
    headless: true,
    defaultViewport: null,
  });

  const page = await browser.newPage();
  await page.goto('https://example.com');

  // All APIs work normally
  const swSupport = await page.evaluate(() => 'serviceWorker' in navigator);
  console.log('Service Worker support:', swSupport); // true

  const storageEstimate = await page.evaluate(async () => {
    const est = await navigator.storage.estimate();
    return { quota: est.quota, usage: est.usage };
  });
  console.log('Storage:', storageEstimate);

  await browser.close();
})();

Persistent Sessions

For sessions that need to persist data across restarts:

# First run - creates session data
chrome --bot-profile="/path/to/profile.enc" \
       --user-data-dir="/data/persistent-session"

# Second run - retains cookies, localStorage, etc.
chrome --bot-profile="/path/to/profile.enc" \
       --user-data-dir="/data/persistent-session"

BotBrowser's --bot-cookies flag provides cookie management without incognito mode:

chrome --bot-profile="/path/to/profile.enc" \
       --bot-cookies='[{"name":"session","value":"abc123","domain":".example.com"}]' \
       --user-data-dir="$(mktemp -d)"

This restores session state in a clean browser instance, without the artifacts of incognito mode.

Verification

After launching BotBrowser, verify that the session behaves as a normal (non-incognito) session:

const page = await context.newPage();

// 1. Check storage quota (should be normal, not reduced)
const quota = await page.evaluate(async () => {
  const est = await navigator.storage.estimate();
  return est.quota;
});
console.log('Storage quota:', quota);

// 2. Check Service Worker availability
const swAvailable = await page.evaluate(() => 'serviceWorker' in navigator);
console.log('Service Worker available:', swAvailable);

// 3. Check IndexedDB
const idbAvailable = await page.evaluate(() => {
  return new Promise((resolve) => {
    const req = indexedDB.open('test', 1);
    req.onsuccess = () => { req.result.close(); resolve(true); };
    req.onerror = () => resolve(false);
  });
});
console.log('IndexedDB available:', idbAvailable);

// 4. Verify fingerprint is controlled (not your real hardware)
const canvas = await page.evaluate(() => {
  const c = document.createElement('canvas');
  const ctx = c.getContext('2d');
  ctx.fillText('test', 10, 10);
  return c.toDataURL().slice(-20);
});
console.log('Canvas hash suffix:', canvas);

Confirm that:

  1. Storage quota is a normal value (not the reduced incognito value)
  2. All APIs are available and functional
  3. Canvas and other fingerprint signals come from the profile, not your real hardware
  4. No incognito-specific artifacts are present

Best Practices

  1. Never use incognito mode with BotBrowser. BotBrowser profiles are designed for normal browser sessions. Incognito mode adds unnecessary artifacts.

  2. Use --user-data-dir for session isolation. Separate user data directories provide clean isolation without behavioral artifacts.

  3. Use temporary directories for non-persistent sessions. mktemp -d creates a unique temporary directory that is cleaned up by the OS.

  4. Always load a profile. Running BotBrowser without --bot-profile means no fingerprint protection. The profile is the foundation.

  5. Combine with proxy for complete identity. A profile controls the fingerprint. A proxy controls the network identity. Both are needed for a consistent identity.

  6. Use --bot-cookies for session restoration. Instead of relying on persistent cookies in a data directory, manage cookies explicitly with the --bot-cookies flag for reproducible sessions.

Frequently Asked Questions

Can I use BotBrowser in incognito mode? You can, but you should not. Incognito mode adds detectable artifacts without providing additional fingerprint protection. BotBrowser's profile-based approach provides better privacy in normal mode.

Does BotBrowser prevent local data persistence? By using a temporary --user-data-dir, session data is not persisted. This achieves the same data non-persistence goal as incognito mode without the associated artifacts.

What about private browsing in Firefox or Safari? The same principles apply. Private browsing modes in all browsers create detectable artifacts while leaving the core fingerprint unchanged. Profile-based fingerprint control is a more effective approach.

Can websites tell if I am NOT in incognito mode? In a normal BotBrowser session, the browser behaves exactly like a standard Chrome session. There is nothing unusual to detect. This is the advantage of not using incognito mode.

Does incognito mode protect against IP tracking? No. Incognito mode does not change your IP address. For IP protection, use a proxy with BotBrowser.

What about "enhanced tracking protection" in Firefox? Firefox's enhanced tracking protection blocks known trackers and limits some fingerprinting. However, it does not control the underlying fingerprint signals the way BotBrowser profiles do. The protection is also detectable through the absence of blocked requests.

Can I run multiple sessions without incognito? Yes. Use separate --user-data-dir paths for each session. Each directory provides full isolation: separate cookies, cache, localStorage, and IndexedDB, with no incognito artifacts.

Does BotBrowser's approach work for all websites? Yes. Because BotBrowser sessions are standard browser sessions, they are compatible with all websites. There are no API restrictions or behavioral differences that could cause compatibility issues.

Summary

Incognito mode provides local data non-persistence but does not protect your browser fingerprint. Worse, it introduces detectable artifacts that make your session more distinctive. BotBrowser takes a different approach: normal browser sessions with profile-controlled fingerprint signals. This provides real identity control without the limitations and artifacts of private browsing modes.

For complete identity configuration, see Browser Brand Switching, User Agent Control and Client Hints, and Timezone, Locale, and Language Configuration. For network identity, see Proxy Configuration and Multi-Account Browser Isolation.

#incognito#private-browsing#detection#identity#privacy