Data and privacy

What Sessions keeps

Loading what it keeps…

Only with a yes

Nothing is recorded before the person says yes. Each page's token carries the moment they did, Sessions refuses a recording without it, and it refuses anything recorded more than 5 seconds before it, the leeway for a browser's clock. Asking your visitors, as the law where they are requires, and telling them about it in your privacy policy, is your part: see our terms for developer services and Record only with a yes.

A person is known by your own ids only, never a name or an e-mail address. The journey holds route names, statuses and timings, and the names of refused form fields, never their values or a URL.

Masked before it leaves the browser

Every input, all media, and every word outside your own UI strings are masked in the browser before a chunk is sent. URLs keep their path, never the query or the hash, and ids in them are replaced.

Masking is always required in production, and in any other environment the project ticks: Sessions refuses an unmasked recording there. And it checks every masked chunk again on arrival: one that still holds an e-mail address, a Finnish personal id, an IBAN, a phone number or a card number is refused before anything is kept. Mask what a recording shows has the details.

Encrypted with your project's key

Each chunk is encrypted before it touches the disk, with AES-256-GCM and your project's own key, and bound to its recording: a file copied into another recording doesn't open there. A copy of the disk or a backup shows nothing without the service's master key, which your project's key is itself sealed under.

Who sees a recording

• Watching a recording takes its own permission, Watch recordings, which an admin gives with a role. The project's owners always may. Who may watch.
• Each recording watched and each journey opened is written in the project's audit log.
• Your server can read back only a test person's recordings, made under test: true, never anyone else's. Each read-back is written in the audit log too.

Erasing a person's data

When a person's account is closed, or they ask, erase what Sessions keeps of them; when a whole account (a workspace, team or organisation) is closed, erase what was kept in it. Each call needs the server secret:

Each answers how many went, and throws when Sessions doesn't confirm. Call them from a queued job with retries, so an erasure is never lost to a network blip; asking again is safe.

namespace App\Jobs;

use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Queue\Queueable;
use MyBeast\Sessions\Laravel\Facades\Sessions;

final class EraseFromSessions implements ShouldQueue
{
    use Queueable;

    public int $tries = 10;

    public function __construct(public string $userId) {}

    public function handle(): void
    {
        // Each throws until Sessions confirms, so the job tries again.
        Sessions::eraseSubject($this->userId);
        Sessions::eraseJourney($this->userId);
    }
}

Sessions writes each erasure in the audit log by its count only, never the id it erased. A tab that is still recording an erased recording is refused for a day after (403, erased), so it can't start it again. The same calls are in the API.