Session Model

A “session” groups snapshots that belong to the same continuous user activity. Our goal is to keep sessions stable during normal browsing (reloads, minor idle periods) while rolling over when activity stops for a while or enough time has elapsed. This page explains our approach without diving into implementation details.

What We Consider a Session

Top‑level context: A session represents a user’s activity in a browser context (e.g., a tab) over time.
Stable across reloads: Reloads and quick navigations don’t fragment sessions.
Short idle is okay: Brief pauses (e.g., reading text) keep the same session.
Long idle rolls over: Extended inactivity ends the current session to maintain clean boundaries.

The Ruleset We Use (Exact Values)

Time windows

Idle timeout: 30 minutes of no activity. The next visibility or heartbeat check will start a new session.
Absolute timeout: 4 hours from the moment the session is created, regardless of activity.
Grace window: 3 seconds. Prevents back‑to‑back rollovers during rapid bursts (for example, multiple quick clicks).
Heartbeat cadence: Every 15 seconds while the page is visible. Heartbeats both “touch” activity and assess expirations.

Event triggers that “touch” activity and/or assess rollover

Page becomes visible: When the tab gains focus or visibility changes to visible, we update activity and check timeouts.
Focus events: Gaining focus triggers an activity touch and timeout check.
Heartbeat (when visible): Every 15 seconds we update last activity and evaluate whether the session should roll.
Before unload: We record a final activity touch when the page is about to unload.
Initial load: On load, if a prior session is present but expired, we immediately roll to a fresh session; otherwise we continue the existing session and touch activity.

Coordination across tabs

Cross‑tab sync: Tabs coordinate via a lightweight messaging channel and a mirrored record so that all tabs agree on the current session and adopt rollovers promptly.
Consistency: If one tab rolls to a new session (for example, after an idle timeout), the other tabs adopt that new session.

Scope & persistence

First‑party session cookie: A host‑scoped, SameSite=Lax session cookie anchors the session within the current browser session; it is not designed to persist across full browser restarts.
Advisory storage: A mirrored, host‑scoped record assists with cross‑tab liveness and fast adoption of updates. It does not resurrect sessions across browser restarts.

Identification

Session identifier: A randomly generated identifier unique to the session’s lifetime.

Why This Approach Works Well

Evidence continuity: Related snapshots from a continuous user flow are grouped together.
Resilience to real browsing: Users frequently reload or open multiple tabs; sessions remain coherent under normal patterns.
Privacy‑sane defaults: First‑party, host‑scoped identifiers avoid cross‑site tracking concerns.
Clear time semantics: Idle and absolute limits make it easy to reason about when a session starts and ends.

Tuning and Customization

Your use case may need different thresholds or semantics (for example, shorter idle on mobile, longer absolute limits, or server‑issued IDs). We can tailor the behavior to your needs — let us know your requirements and we’ll align the session policy accordingly.

FAQ

Does a session survive browser restarts? No. A browser restart starts a new session.
What if storage restrictions apply? We operate with graceful fallbacks so sessions still function in constrained environments.