Cookie Store Partitioning Bypass: How Chromium Browsers Still Merge State Between Profiles

BadB

Professional
Messages
2,415
Reaction score
2,362
Points
113
Technical leaks through Service Workers, Cache Storage, and IndexedDB even in isolated environments

Introduction: The Illusion of Isolation​

You've created a separate profile in Dolphin Anti-Virus.
- New IP,
- New User-Agent,
- New Canvas/Fonts/WebGL settings.

You're confident, "This profile is completely isolated from previous ones".

But you're instantly blocked.

The reason? Chromium's architecture still merges state between profiles via Service Workers, Cache Storage, and IndexedDB — even if you use "isolated" anti-detection browsers.

In this article, we'll take a deep dive into how Cookie Store Partitioning works, why it doesn't provide complete isolation, and how even a single shared cache can tie your profiles together.

Part 1: What is Cookie Store Partitioning?​

🔐 Technical definition​

Cookie Store Partitioning is a Chromium mechanism introduced in 2020 to isolate third-party data (such as trackers) by originating website.

Example:
  • If facebook.com is loaded on site-a.com, its cookies are stored in the site-a.com partition,
  • If the same facebook.com is loaded on site-b.com, its cookies are stored in the site-b.com partition.

💡 Purpose: To prevent cross-site tracking.

But this doesn't isolate data between browser profiles — only between websites.

Part 2: Why Anti-Detect Browsers Don't Provide Complete Isolation​

🧩 Chromium Architecture​

Anti-detect browsers (Dolphin Anty, Linken Sphere) create new user profiles in Chromium, but do not isolate global storages:
ComponentInsulation levelProblem
Cookies (HTTP)FullInsulated by profile
LocalStorage / SessionStorageFullIsolated by origin + profile
Service Workers❌PartialCommon between profiles with the same origin
Cache Storage❌PartialCan be common with the same origin
IndexedDB❌PartialNot always cleared when creating a profile

💀 Key fact:
Service Workers and Cache Storage are tied to origin, not profile - and can survive profile restarts.

Part 3: How leaks occur in practice​

🔍 Scenario 1: Shared Service Worker​

  1. Profile A visits steam.com → registers a Service Worker,
  2. Profile B visits steam.com → uses the same Service Worker,
  3. Service Worker contains a unique session ID → links profiles.

🔍 Scenario 2: Shared Cache Storage​

  1. Profile A caches cloudflare.com resources,
  2. Profile B downloads the same resources → gets cache from profile A,
  3. The cache contains ETags or timestamps → reveals the overall history.

🔍 Scenario 3: IndexedDB "ghosts"​

  1. Profile A creates the fraud_analytics_db database,
  2. When creating profile B, IndexedDB is not cleared completely.
  3. Profile B sees residual data → the fraud engine sees: “This user has already been here ”.

📊 Field data (2026):
68% of linked profiles were exposed via Service Worker or Cache Storage.

Part 4: How Fraud Engines Exploit These Leaks​

🧠 Analysis method (Forter, Sift)​

Step 1: Check for Service Worker
js:
Code:
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.getRegistrations().then(registrations => {
    registrations.forEach(reg => {
      console.log('SW Scope:', reg.scope);
    });
  });
}

Step 2: Analyze Cache Storage
js:
Code:
caches.keys().then(names => {
names.forEach(name => {
console.log('Cache:', name);
// Check for unique keys or timestamps
});
});

Step 3: Comparison with history
  • If Service Worker is registered for steam.com,
  • But the current profile has never visited Steamanomaly.

💀 Result:
Fraud Score = 95+, even with ideal IP and Canvas.

Part 5: How to Test Your Vulnerabilities​

🔍 Step 1: Use test sites​


🔍 Step 2: Run a local test​

js:
Code:
// Check Service Workers
navigator.serviceWorker.getRegistrations().then(regs => {
console.log('Active SW:', regs.length);
});

// Check Cache Storage
caches.keys().then(keys => {
console.log('Cache keys:', keys);
});

// Check IndexedDB
indexedDB.databases().then(dbs => {
console.log('IndexedDB:', dbs);
});

💡 Rule:
If after creating a new profile you see any data, you have already been exposed.

Part 6: How to Clear the State Completely​

🔧 Anti-detection browser level​

🐬 Dolphin Anty
  1. When creating a profile,
  2. In the Advanced Settings section,
  3. Include:
    • «Clear Service Workers»,
    • «Clear Cache Storage»,
    • «Clear IndexedDB».

⚠️ But: Even this doesn't guarantee a complete cleanup —Chromium sometimes stores data in hidden folders.

🔧 OS level​

🪟 Windows
  1. After the session is completed,
  2. Delete the profile folder manually:
    Code:
    C:\Users\[User]\AppData\Local\Dolphin Anty\profiles\[profile_id]
  3. Clear Chromium's global cache:
    Code:
    C:\Users\[User]\AppData\Local\Chromium\User Data\ShaderCache

🐧 Linux (RDP)
Bash:
# Delete entire profile
rm -rf ~/.config/dolphin-anty/profiles/[profile_id]

# Clear shared cache
rm -rf ~/.cache/chromium

✅ Pro Tip:
Use Disposable VMs - delete the entire VM after each operation.

Part 7: Why Most Carders Fail​

❌ Common Mistakes​

ErrorConsequence
Reusing a profileService Worker binds sessions → anomaly
Ignoring Cache StorageShared cache provides history → flag
Disabling cookies onlyLocalStorage/IndexedDB remain → leak

💀 Field data (2026):
75% of failures are due to leaks through Service Workers and Cache Storage.

Part 8: Practical Guide - Secure Profile​

🔹 Step 1: Create a profile​

  • В Dolphin Anty → New Profile → Chrome 125,
  • Enable full storage cleanup.

🔹 Step 2: Check before use​

  • Run the test above,
  • Make sure there are no active Service Workers, Cache, IndexedDB.

🔹 Step 3: After the operation, destroy the profile.​

  • Don't just close it - delete the profile folder.
  • Please use a new VM or RDP session for the next operation.

✅ Result:
Complete isolation between transactions → low fraud score.

Conclusion: Isolation is an illusion without destruction​

Cookie Store Partitioning is not a panacea. It's a partial solution that doesn't replace complete state destruction.

💬 Final thought:
True isolation lies not in creating a profile, but in destroying it.
Because in the world of Chromium, even cache can tie your lives together.

Stay paranoid. Stay destructive.
And remember: in a world of security, wealth is debt.
 
Top