The Operational Boundary: Profiles, CDP, Updates, and Trust

For CloakBrowser, identity coherence does not end when Chromium starts. A profile can carry state across restarts, a CDP server can multiply processes and connections, a new binary can change capability assumptions, and a license decision can arrive after a browser has already connected. This chapter follows those transitions so a reader can evaluate whether an operational design preserves identity and trust—or whether a documented convenience is weaker than the visible implementation supports.

A profile is state, not a label

An ephemeral browser context and a persistent profile answer different questions. An ephemeral context begins with little or no stored history and is discarded when it closes. CloakBrowser’s persistent launch functions instead reuse a user-data directory. Cookies, local storage, cache, service workers, IndexedDB, and related browser state can survive a restart. That continuity can make a session resemble a returning browser and can avoid signals associated with an empty private context, but it also creates durable state that must be isolated from unrelated work.

The fingerprint seed and the profile serve different parts of the same identity. A fixed seed can keep generated browser values stable across launches; the profile can keep the application state that a returning visitor would have accumulated. Either can exist without the other. A fixed seed with a discarded profile preserves only part of the story. A persistent profile with a changing seed preserves history while changing the generated device identity. CloakBrowser does not make those combinations equivalent, so the operator has to decide whether continuity, separation, or reproducibility is the actual requirement.

Persistent state also changes failure recovery. If a site challenges a first-time session, reusing a warmed profile may change the result without changing the browser binary. If a profile has stale cookies or state from a different task, reuse can create a new inconsistency. The project documents storage-quota tuning for services that infer private browsing from quota, but adjusting that value does not make a profile trustworthy by itself. It only changes one observable property. The broader profile still has to belong to the intended session and be handled as sensitive state.

Widevine shows how persistence crosses into a proprietary boundary. CloakBrowser’s binary is built with Widevine support, but the CDM is a separate Google component that the project does not redistribute. The wrapper can find a CDM that the user has already supplied and write Chromium’s hint file into a persistent profile before launch. That makes first-launch initialization work on Linux when the CDM is present; it does not grant a right to copy, redistribute, or play any particular protected content. Seeding is best-effort and can be disabled, and it is a no-op on platforms whose CDM initialization path is different.

The same profile concept appears in cloakserve, but with an additional process boundary.