Documentation menu

Security and access

What Sess does to keep your keys, the person's link and the page itself safe, and the limits of those protections.

On this page

Preview. Send only fabricated or non-sensitive data to the preview. Sess offers no service-level agreement and holds no compliance certification.

Credentials

  • Owner keys, human links and trial management credentials are separate credentials; one can never stand in for another. See credential audiences.
  • Owner keys and trial management credentials travel only in the Authorization header, never in a URL. A management credential is returned once, at trial creation, and stored only as a hash; it reads only its own trial's Sessions.
  • Human links carry a 256-bit random token. Sess stores only a hash of the token and finds the Session by that hash; the token itself is never stored. IDs in public URLs are never sequential or guessable.
  • An unknown, expired or revoked link gets the same generic "not found" page, so links cannot be probed.
  • API keys are stored as hashes, have an expiry, and can be revoked from your account at any time. Draft — lands with P1 increment 2

A human link works like a password: whoever holds it can open that one Session's page. It does not identify the person.

  • Human pages send Cache-Control: no-store, Referrer-Policy: no-referrer and X-Robots-Tag: noindex, nofollow, and are never listed in a sitemap or linked from public pages.
  • Sess redacts the token from its application logs and telemetry.
  • Opening a link, or a chat app generating a link preview, never changes or answers a Session.
  • A link cannot call the owner or trial API, read your private metadata or change where results go.

Your part: send the link only to the intended person, and keep it out of your own logs, analytics and public channels.

Page safety

  • Sess renders your data as text, records and tables. It never renders HTML, JavaScript, CSS or remote content from your data or from anyone else.
  • Human pages use a strict Content Security Policy: no inline scripts and no external origins. Submissions are accepted only from the page itself, and cross-origin requests to the API get no CORS permission.
  • Pages are built to work with a keyboard, screen readers, phone screens and 200% zoom.

Who answered: assurance

A response through a human link is recorded as coming from "whoever held the link". Sess does not verify the person's identity in this release, so do not use it to authorize irreversible or protected operations (payments, deletions, access grants).

Signing in to your developer account proves who you are as a developer; it never verifies the person who answers. Draft — lands with P1 increment 2

Results, receipts and webhooks

  • Each submission is bound to the exact revision the person saw; a stale one is rejected, never re-applied.
  • Each accepted result can be checked against a receipt signed by Sess (Ed25519) with a published key ID, and verified with standard JWS tooling against the public key set. A receipt records what Sess accepted; it does not prove what the person understood or what happened downstream.
  • Webhook deliveries carry a separate per-workspace signature (Standard Webhooks v1, HMAC-SHA256), distinct from the receipt. The signing secret is shown once and kept by Sess only encrypted; rotation keeps the previous secret signing for a 24-hour overlap.
  • A webhook endpoint must be an https:// URL on port 443 and must answer a signed challenge before anything is delivered; a verification holds for 30 days. Every connection resolves the host and refuses non-public addresses, and Sess follows no redirects.

These public pages

The product site and docs are static pages. They load no analytics, cookies, fonts or third-party scripts, and accept no input.

What Sess does not claim

  • No service-level agreement or uptime guarantee.
  • No compliance certification (for example SOC 2 or ISO 27001), and no legal e-signature.
  • No verification of the responder's identity in this release.
  • No proof that an agent, webhook receiver or other system acted on a result.

Report a security problem

See Support and contact. Never include an owner key or a full human link in a report; a Session ID and the request_id from an error are enough.