Pre-pilot — selecting the first customers

Someone has to sign on the tablet. They don’t have to be in the room.

Optima Remote streams an organisation-owned Android tablet’s screen to a one-time browser link. Whoever opens it can tap, swipe and sign — strokes arrive as one continuous line, not a row of dashes. Nothing starts until they accept, and nothing is ever recorded.

Request a pilot Read the technical measures

Built for the German market: EU-hosted end to end, and a consent gate the end user can actually refuse.

Screen content stored: never
Camera images stored: never
Hosting: EU only
Consent before capture: required
Session link: single use
Visible to the tablet’s user: always
Trackers on this site: none

What it actually does

Two jobs that normally require someone standing at the tablet

Both run off the same one-time link, in an ordinary browser. The end user installs nothing and signs in to nothing.

Mode 01 · Control

See the screen. Tap it. Sign on it.

The tablet’s screen appears live in the browser. Touch input travels back over a data channel and is replayed on the device by an accessibility service that stitches a stream of points into a single continuous gesture — which is what makes a remote signature legible instead of a row of dashes.

Points are sampled with the browser’s coalesced-event API so a fast stroke is not flattened into a staircase, and mapped through the video’s letterboxing into the tablet’s physical pixel space. On the tablet, coordinates are clamped to the real display and the input queue is bounded.

Mode 02 · Document scan

Photograph a document that is somewhere else.

Some processes have to go through the tablet’s own scanning app — its camera, its pipeline, its output. So instead of replacing it, the end user’s phone publishes its rear camera to a small screen mounted in front of the tablet’s camera, on a pure-black surround, and the tablet photographs a held, sharp still.

It is a second, independent connection: four peers and two channels per session rather than two and one. The existing scanning process does not change.

How a session works

Eight steps, and where each one is enforced

This is the whole lifecycle. It is worth reading closely if you are the person who has to sign off on it — most of the guarantees on this page live in steps 02 to 04.

Staff
A staff member mints a link.
From the console, against a tablet that is currently idle. The session’s state machine is enforced by a database trigger rather than by the interface: a finished session cannot be restarted, and a session cannot be moved to another tablet.
End user
They open the link in a browser.
No app, no account. An anonymous identity is created in that browser and bound to the session the first time it is opened. That binding is what makes the link single-use: reloading works, forwarding it to someone else does not — and the refusal is recorded.
End user
Consent. Nothing has started yet.
At this point no signaling has happened, no screen is being captured, and the tablet has not been told a viewer exists. Accepting is what starts each of those.
Declining ends the session server-side. There is nothing to opt out of afterwards, because nothing began. The decision — either way — is written to the audit log with a timestamp.
System
The browser joins one private channel.
Signaling is scoped to that single session. Only the paired tablet and the participants bound to that session may join, and only while it is live. Authorisation is a row-level security policy in the database — not a check in application code that a client could route around.
Tablet
The tablet starts capturing, and says so.
A red on-screen banner and a persistent system notification, for as long as the session lasts. The capture service runs continuously between sessions showing “ready, not sharing”; the only thing that changes when a session begins is the disclosure.
System
Media connects, peer to peer.
WebRTC, encrypted end to end with DTLS-SRTP. Where the two networks cannot reach each other — which on German mobile carriers is common — a self-hosted relay in the EU forwards the encrypted stream it has no key for. Relay credentials are minted per session and expire shortly after it; nothing durable is compiled into any client.
End user
They tap, and they sign.
Every point of the stroke goes back over the data channel and is replayed on the tablet as one continuous gesture. A network blip does not end the session: the connection is restarted in place, a bounded number of times.
Either side
The session ends.
When the end user closes the page, when staff end it from the console, or when it expires. Expiry is enforced in the database, so a session cannot stay open because a client went away — and the link cannot be reopened by anyone.

The database mints the session, authorises the private signaling channel and records what happened. It never carries the screen. Video and input go directly between the two peers, or through a relay that is handling encrypted media it has no key for.

Privacy architecture

Nothing is recorded — not as a policy, as an absence

The strongest thing anyone can say about screen content is that there is no code that could store it. That is a claim about a repository, so it was audited as one rather than asserted.

What does not exist

In the tablet app, the session page and the backend:

No MediaRecorder, anywhere.
No screenshot or frame-to-bytes path outside a developer test screen that is compiled out of production builds.
No upload path: no storage bucket, no endpoint that accepts a frame, no column that could hold one.
No localStorage of media.
No table, column or function in the schema capable of holding screen content — including for admin observation, which adds none.
No screenshot or session-replay tooling. That one was a decision.

Camera stillsIn document-scan mode a still exists only as an in-memory blob in the receiving browser, and is released when the next one replaces it. It is never written to disk and never uploaded.

The error tracker we deliberately did not add

Error tracking with session replay would record precisely the thing the consent notice promises is never recorded — the customer’s tablet screen. Adding one to satisfy an observability checkbox would have quietly created a subprocessor holding video of your customers.

So diagnostics report into the same EU database the product already uses. No new vendor, no new contract, and enough to diagnose a pilot. The interface is vendor-neutral, so an EU-hosted tracker can be added later — after a data processing agreement exists and it is written into the processing record, which is the order that keeps the record true.

Why this is the differentiatorA product that records screens can promise to delete the recordings. A product with nowhere to put them cannot break that promise by misconfiguration, by a support engineer, or by a subpoena.

Where the data lives

Every component is in the EU, including the one most products rent

The relay is the piece that usually goes to a global provider with endpoints on three continents. Here it is self-hosted on a German box instead — which is the only reason “no transfer outside the EU” can be said without a footnote.

Components and regions
Component	What it does	Where it runs
Supabase	Database, authentication, realtime signaling, edge functions	EU · Frankfurt
TURN relay (coturn)	Forwards encrypted media when the two peers cannot reach each other. Self-hosted, not rented.	EU · Nuremberg / Falkenstein
Vercel	Hosting for the staff console and the session page	EU regions
Screen and camera content	In transit only, between the two peers. It reaches none of the above except the relay, which cannot decrypt it.	nowhere at rest

Retention
What	Where	Kept for
Screen video, camera video, touch and signature input	In transit only	never stored
Session metadata	Supabase, EU	90 days
Anonymous participant identifier	Supabase, EU	deleted with the session
Audit trail	Supabase, EU	12 months
Pairing attempts	Supabase, EU	30 days
Relay connection metadata	Relay, minimal logging by configuration	not retained beyond the session

Deletion is code, not a calendarA nightly job purges each of the rows above at the intervals stated, and that job is covered by the automated test suite. Retention is not a paragraph in a policy that someone has to remember to act on.

Oversight

Every session is reconstructable — including the times somebody was watching

The audit trail is append-only at the database level: no application role holds insert, update or delete on it, and only trusted database functions write to it. Refusals are written too, which is the half that usually gets lost.

What gets written

These are the event names as they appear in the log, not a summary of them:

session.created
session.opened
session.consent_accepted
session.consent_declined
session.claim_rejected
session.ended
session.observe_started
session.observe_ended
session.observe_denied
session.observe_rejected
tablet.paired
tablet.renamed
tablet.deleted
member.added
member.removed
member.role_changed
member.add_denied
member.remove_denied
member.role_change_denied

Why refusals are returned, not raisedPostgreSQL has no autonomous transactions, so an exception on a failure path rolls back the record written on that path — a lockout counter that raises can never fire, and a rejected claim that raises is never audited. Both were real bugs here, caught by the tests. Expected failures are now returned so the trace survives.

Admin observation is a processing activity, and it is logged as one

An administrator of your organisation can watch a live session read-only from the console. The read-only part is technically enforced rather than merely stated: the observer is refused writes on the control channel by a database policy, so there is no path by which they could send input, and the observing client renders the video with no pointer handlers at all.

The start and the end of every observation — with its duration — go into the same append-only log. “Was anyone else watching that session?” is a question with an answer.

Roles, and one gap we will not paper over

Staff and admin are distinct roles enforced in the database. Staff create and end sessions, pair tablets and see their organisation’s fleet; admins additionally hold the audit log, member management and live observation.

The audit log is a hard boundary. The session list is not: its underlying policy is still organisation-wide so the console can watch it live, which means a staff member can read raw session rows for their own organisation through the API. It is a deliberate trade, it is written down in our security model, and tightening it is a one-line change we will make when a customer needs it.

Fit

Who this is for, and where it stops

The right-hand column is the one worth reading. We would rather lose a deal on the second list than discover it during a pilot.

A good fit

A field or branch process with a signature or a scanWhere the tablet is in one place and the person who has to sign is in another.
Organisation-owned Android tabletsDeployed by you or your MDM, kept as a fleet, running your own application.
Buyers whose data protection story gets checkedPublic sector, insurance, finance, healthcare adjacent — the places where “we never record it” has to survive being read by a DPO.
Deliberate onboardingStaff accounts are provisioned by hand. There is no self-signup, by design.

Not a fit — at least not yet

Not a general remote desktopIt drives one organisation’s Android tablets. Not laptops, not servers, not arbitrary machines.
Not for personal or BYOD devicesThe tablet has to be a device the organisation owns and provisions.
No Play Store distributionThe app is installed privately or by MDM. That is a permanent, documented decision — not a stopgap. If your policy mandates managed Google Play, this does not fit today.
iOS Safari is not yet verifiedThe session page is tested on desktop and Android browsers. We have not proven it on an iPhone, so we are not claiming it.
Not load-tested at scaleBehaviour past a few dozen tablets is unknown. That work comes before the second large customer, not after.
No SOC 2, no ISO 27001, no certificationsWe do not hold any, and we are not going to imply otherwise with a badge. What we have instead is the technical measures document, in full, on this site.

Where the product actually isPre-pilot. The system is built and its database rules are covered by an automated test suite that runs as the same anonymous and authenticated roles a real HTTP caller uses; the production infrastructure is being provisioned alongside the first customers. If you need a reference deployment you can call today, we are not it yet — and we would rather tell you now than during procurement.

Bring us the process you cannot do remotely today

A pilot is a handful of tablets, one process, and a short deployment. Tell us what has to be signed or scanned and where the tablet sits, and we will tell you honestly whether this fits — including when it does not.

Request a pilot Security & technical measures

Pricing: [[PRICING TBD]]

Someone has to sign on the tablet. They don’t have to be in the room.

Two jobs that normally require someone standing at the tablet

See the screen. Tap it. Sign on it.

Photograph a document that is somewhere else.

Eight steps, and where each one is enforced

A staff member mints a link.

They open the link in a browser.

Consent. Nothing has started yet.

The browser joins one private channel.

The tablet starts capturing, and says so.

Media connects, peer to peer.

They tap, and they sign.

The session ends.

A gate, not a banner

Before we start

Why the ordering matters