End-to-end encrypted in three steps
Every co-browse session performs a fresh key exchange. No keys are ever reused.
Key exchange
Both browsers generate ephemeral ECDH P-256 keypairs. They exchange public keys through our server. Private keys never leave the browser.
Key derivation
Each side independently derives an identical shared secret using ECDH, then derives the session encryption key using HKDF-SHA-256 with a unique per-session salt.
Encrypted streaming
All page content is encrypted with AES-256-GCM before transmission. Every message uses a fresh random IV and includes an authentication tag to detect tampering.
What the server sees vs. what it doesn't
Our server routes encrypted payloads but cannot decrypt them.
Server cannot access
- Page HTML, CSS, and text content
- User input and form data
- Console logs and errors
- Network request/response bodies
- Annotations and drawings
- Cursor positions and interactions
- ECDH private keys
- AES session keys
Server can access (metadata only)
- Session ID and team ID
- Session start/end timestamps
- That events are flowing (not content)
- Visitor consent status
NIST-approved. No custom crypto.
All cryptographic operations use the W3C Web Crypto API backed by platform-native implementations. No third-party cryptographic libraries.
Key Exchange
ECDH P-256
NIST FIPS 186-4
Key Derivation
HKDF-SHA-256
NIST SP 800-56C
Bulk Encryption
AES-256-GCM
NIST SP 800-38D
Channel Auth
HMAC-SHA-256
FIPS 198-1
Fresh keys. Every session.
Ephemeral ECDH keypairs are generated per session. The server relays wrapped keys but cannot unwrap them.
Nothing to subpoena. Nothing to breach.
Visual Assist is live-only by design. When a session ends, all in-memory state is discarded. There is no replay, no server-side buffer, and no persistent storage of encrypted payloads.
- No session replay capability
- No server-side content buffer
- No disk writes of session data
- No data retention of page content
- Session metadata retained for 90 days (audit only)
Consent, authentication, and authorization
Multiple layers of access control govern who can initiate sessions and what level of access they have.
Visitor consent
Configurable consent mode. Require explicit visitor approval before viewing, or use silent mode for seamless support.
Channel authentication
Time-windowed HMAC-SHA-256 tokens with constant-time comparison. Strict channel format validation.
Role-based access
Per-agent Visual Assist permission. Organization admins, team admins, and agents have distinct access levels.
Element blocking
Administrators designate page elements hidden from agents. Blocked content is excluded before encryption.
Session lifecycle
Automatic timeout after 30 minutes of inactivity. Stale session cleanup at 2 hours.
Rate limiting
Per-connection event limits and per-IP connection caps. Message size limits and protocol validation.
Two layers of encryption. Independent.
All connections use TLS for transport encryption. On top of that, Visual Assist adds application-layer AES-256-GCM encryption. Compromising TLS alone does not expose page content.
How helpr compares
Most co-browse solutions rely on TLS only and store session recordings server-side.
| helpr | Typical solutions | |
|---|---|---|
| Encryption | E2E AES-256-GCM | TLS only (server decrypts) |
| Session recording | None (by design) | Server-side recording |
| Server content access | Zero-knowledge | Full access |
| Key management | Ephemeral per-session | Shared or server-managed |
| Data at rest | None | Recordings stored |
| Consent model | Configurable (explicit or silent) | Varies |