Your product shouldn't run on borrowed cookies
Chrome is rolling out device-bound session credentials that tie cookies to the machine that created them, so sessions replayed from a vendor's cloud start failing by architecture, not by detection. Oculr gives every account a persistent, real browser profile that your platform drives over API, MCP or CDP, so the session never has to leave home.
A cookie copied off its device is now just bytes
Device-bound session credentials tie each session to a key the device keeps in secure hardware. Sessions replayed from vendor clouds fail their next refresh; sessions that stay in a real browser profile carry on as normal. The fix is not a better cookie store. It is not exporting the session at all.
Two architectures, one deadline
The mechanism built to stop stolen-cookie malware retires stored-cookie automation with it. Resident sessions are the model that remains.
You never hold the credential
Sessions stay in profiles on hardware the account owner controls. Your backend keeps tokens for your service, nothing else.
Keep the product. Replace the browser layer.
Your sequences, inbox, CRM sync and UI are what customers buy. The browser layer underneath is undifferentiated risk that you rebuild forever. Run it on persistent Oculr profiles instead of stored cookies and shared cloud browsers.
Give every account a home that persists
Each account gets an isolated, persistent profile: its own cookies, storage, extensions and a deterministic engine-level fingerprint that presents the same coherent device on every launch. Timezone, language and geolocation derive from the profile's own proxy and re-apply on every tab. The account's session accumulates history in one place instead of hopping between anonymous cloud machines.
- Isolated persistent profiles, one per account
- Deterministic per-profile fingerprints, engine-level in native C++
- Timezone, language and geo aligned to each profile's proxy
Integrate underneath, keep your brand on top
Oculr is built to be driven by other software. A local REST API handles profile lifecycle, MCP exposes 40+ tools for agent-driven browsing and fleet control across many profiles at once, and every launched profile hands back a WebDriver-compatible driver path plus the raw CDP websocket, so the Selenium, Puppeteer or Playwright code you run today attaches unchanged.
- REST API for profile creation, launch and lifecycle
- 40+ MCP tools with raw CDP underneath, no injected frameworks
- Existing Selenium, Puppeteer and Playwright scripts attach unchanged
Get out of the credential custody business
A platform that stores live session cookies for every customer is one breach away from a mass account takeover, and that liability compounds with every signup. With sessions resident in profiles, there is nothing equivalent to leak: cookie and password sync are off by default, share links strip secrets before they leave the app, and 2FA codes are generated in the profile rather than pasted around your team.
- No customer session cookies or passwords on your servers
- Cookie and password sync stay off unless the owner opts in
- Share links never expose stored secrets
Cookie replay versus a resident session
The two architectures look similar from a customer's dashboard. They age very differently.
| Dimension | Oculr | Stored-cookie replay |
|---|---|---|
| Where the session lives | In a persistent browser profile, cookies and storage intact | In a database, replayed onto shared cloud browsers on demand |
| Under device-bound sessions | Used in place, in the browser that owns it, so refresh keeps working | An exported cookie cannot prove possession of the device key |
| What your company stores | Tokens for your own service, rotatable at will | Your customers' live platform sessions, a breach away from mass takeover |
| Session consistency | One coherent device identity per account, every day | A different cloud machine, network and fingerprint on every run |
| Integration surface | REST API, MCP tools and raw CDP; Selenium and Playwright attach unchanged | Whatever the cookie importer supports |
Frequently asked questions
What are device-bound session credentials (DBSC)?+
DBSC is a Chrome security mechanism that binds a website session to a cryptographic key the browser keeps in the device's secure hardware. The session cookie becomes short-lived, and the site periodically challenges the browser to prove it still holds the device key before refreshing it. A cookie copied off the machine cannot answer that challenge, so it stops being able to keep a session alive.
Why does DBSC break cookie-replay automation architectures?+
Products that ask users for their session cookie and replay it from cloud servers depend on an exported cookie staying valid indefinitely. Under DBSC the exported cookie fails its next refresh, because the private key it needs stays on the original device. That is not a detection arms race, it is the architecture being retired: the same mechanism that kills stolen-cookie malware kills stored-cookie automation.
How does Oculr avoid the same fate?+
By never exporting the session. Each account lives in a persistent browser profile that keeps its cookies, storage and identity together, and your product drives that profile where it lives instead of moving credentials to your own servers. Sessions are used the way the mechanism expects sessions to be used: in the browser that owns them.
How does an automation platform integrate Oculr?+
Three ways, all on the same profiles. A local REST API covers profile creation, launch and lifecycle. MCP exposes 40+ tools for agent-driven browsing, profile management and fleet control. And launching a profile returns a WebDriver-compatible driver path plus the CDP websocket endpoint, so existing Selenium, Puppeteer and Playwright code attaches unchanged. Your sequences, UI and CRM stay yours; Oculr is the browser layer underneath.
Where do the browsers run?+
On machines you or your users control. Oculr is a desktop app with a local-first API, and remote access is token-authenticated when you choose to expose it. That is the point: the session stays with hardware that belongs to the account's owner, not in a shared cloud your vendor operates.
Does this make automation compliant with platform terms?+
No, and we won't tell you otherwise. Each platform sets its own automation policies, and moving to Oculr does not change what those policies allow. What it changes is architecture: sessions stop being exported, your company stops warehousing customer credentials, and your product stops depending on a cookie-replay model that device-bound sessions are retiring.
Built on these features
Put a real browser under your platform
Create two profiles free and drive them from your own stack over API, MCP or CDP this afternoon. The session layer question stops being yours to rebuild.
No credit card required · Cancel anytime