onscryn

Security / data flow

The app stays put.
Pixels travel.

For a security review, the useful question is not what a product does but where your data sits while it does it. This page draws that out, one hop at a time, and says what each part of Onscryn checks.

YOUR USERBrowser tabNo install, no VPN,no files receivedONSCRYNControl planeSign-in and SSO, roles, policy,session tickets, audit logChecks identity on every requestONSCRYNBrokerRelays the stream, enforcesclipboard and file policy,burns in the watermarkCloses streams with no valid ticketHOST SIDEWindows hostApp and its files,one account persession, plus theOnscryn agentData stays hereRecordings (if on)1sign in2ticket back3ticket, policy4pixels outinput back5frames ininput out6agent connects outward
Arrows show direction. The diagram is simplified: it leaves out the shared pool and the warm-slot logic.

One session, step by step.

  1. 01

    The user signs in

    Through SSO (OIDC or SAML) or email and password. The control plane checks identity and role, and keeps checking on every later request.

  2. 02

    Control issues a ticket

    A short-lived ticket bound to that session, user and role. Without one, the stream does not open.

  3. 03

    Control tells the broker what is allowed

    The broker learns the session's policy: clipboard, file transfer, watermark and whether to record. It reads these when the session launches.

  4. 04

    The browser opens the stream

    The tab connects to the broker with its ticket. The broker closes any connection without a valid one (close code 4401). Pixels flow to the browser and mouse and keys flow back.

  5. 05

    The broker talks to the host

    The Windows host runs the application in its own session account and sends frames to the broker. The broker forwards only what the policy allows.

  6. 06

    The agent connects outward

    The Onscryn agent on the host opens its own outbound connection to the control plane to register and report in, rather than the control plane reaching in.

What crosses each boundary.

The application and its files

Stay on the Windows host

Which hosts you use: your own, or ours. Nothing is installed on the user's device.

Screen pixels

Host to broker to the user's browser

An optional watermark with the viewer's email and the time is drawn into the frames.

Keyboard and mouse

Browser to broker to host

Viewers who watch a shared session cannot drive; one person controls at a time.

Clipboard

Only if policy allows

Allowed or blocked per app and per organization. The broker drops blocked messages.

File transfer

Only if policy allows

Allowed or blocked per app and per organization, enforced by the broker.

Recordings

Broker to object storage, replayed through a short-lived signed link

Per app or organization, decided when the session launches. Beta, and plan-dependent.

Account and audit data

Held by the control plane

Roles scoped to your organization. The audit log is plan-dependent.

The edges
we state plainly.

  • Sessions are separated at the Windows account level, not by a virtual machine per session. Dedicated hosts are plan-dependent.
  • If your own hosts are at capacity, sessions can fall back to the shared pool. Tell us if your data must stay on your own hosts.
  • Policy is read when a session launches, so a change applies to new sessions, not running ones.
  • Clipboard and file transfer default to on, and the watermark to off, until you change them.

Need the answers
in a form?

Read the questionnaire answersBook a security review