MaskWright

2026-07-31 · Jordan Hale · 663 words

What cookie-based session management is

Session versus fingerprint. Cookie robot merge lives in pre-made cookies. This definition keeps a jar from being confused with a canvas hash.

What cookie-based session management is 1

Cookie-based session management is the boring job of keeping logins in a store you can name, move, and isolate. It is not a canvas hash. It is not a fingerprint seed. Sites persist “you are signed in” as cookies first. Everything else is support.

This definition keeps those layers apart. The cookie-robot merge lives in pre-made cookies and cookie robots. I will not teach a buy. I will name the session.

The page sits in Privacy because a session is personal data you are responsible for.

Cookies first, then the other stores

A cookie is a name/value the site set, with a host and a path and flags. Export Netscape and you have a portable session, until it expires or the site rotates it. MaskWright import applies via CDP Network.setCookies at Chromium launch, not by writing Chrome’s cookie DB on import.

Then localStorage. Then IndexedDB. Then service workers. A “cookie-only” move can still miss a logged-in app. Disk use is the whole tree.

Fingerprint is a different layer: UA, WebGL, canvas noise. You can have a perfect spoof and a shared cookie store. You can have isolated cookies and a sloppy spoof. Session management is the first problem.

Isolation is the management

One profile, one user-data dir, one cookie store. Sharing a profile is sharing cookies. Encryption: profiles.json AES-256-GCM. Cookie files plaintext. We do not upload them. What leaves this machine. Geo lookups are IP, not cookies.

Ads in the operator UI are not session management. Dashboard ads, owned slots. SmartScreen is the installer, not the jar.

LayerJob
Cookies“You are logged in”
localStorage / IDBApp state next to the login
FingerprintHow the browser looks
ProxyWhere the TCP goes

On a Windows profile I treat “am I logged in?” as a cookie question first. I check the site, not CreepJS. If I need to move the login to a new disk, I export cookies I own, or I copy the whole user-data dir while the browser is quit. I do not buy a pack. I do not scrape a session out of a HAR from someone else.

Fingerprint work happens after the store is split. Geo alignment happens if you attached a proxy. Neither replaces the cookie. People who skip this definition spend money on spoofing and still paste one Netscape file into five profiles.

Import is CDP setCookies at launch for Chromium. If a site also needs localStorage, import that too. If it needs IndexedDB, copy the folder. Cookie-only is sometimes enough and sometimes a ghost login that looks logged out.

Pushback I hear: “fingerprint is the session.” It is not. Sites persist login as cookies first. You can spoof canvas and still share one Netscape file across five profiles. Split the stores, then worry about WebGL. Import is for a session you already had, applied at Chromium launch via CDP, not a trophy.

FAQ

Is importing cookies “session management”?

It is a move of a session you already had. It is not a way to acquire someone else’s login. That is the robot page.

Does Firefox/Camoufox use the same import path?

Chromium is the documented CDP import path. Treat Firefox as a second core with less import parity until you verify it yourself.

Can I manage sessions without antidetect?

Chrome profiles already do a weaker version. Antidetect adds fingerprint and per-profile proxy. The cookie split is still the core. Download MaskWright if you wanted named stores on Windows.

Do I need localStorage import every time I move cookies?

If the site is a simple cookie login, cookies may be enough. If it is an app that stores tokens in localStorage or IndexedDB, copy those too, or copy the folder. Cookie-only can look logged out.

If a vendor talks about sessions and only shows canvas screenshots, they skipped the boring job. The boring job is the login. Keep it in a folder you can point at.

Related notes