Privacy and data

Exactly what Teleprompt stores, where it stores it, and what it never sees.

What is stored

Data	Why
Name, email address, profile image from your provider	To identify the account, and so you can tell which account a device is signed into. The verified email address is also what links a Google sign-in and a GitHub sign-in into one account.
OAuth tokens from your provider	To keep you signed in. Stored server-side, never sent to the browser.
Your scripts, and the folders you file them in	So they are there on the other device, and findable.
Sharing grants: the email address you shared with, and the level	So that person can reach the script or folder. An address is stored whether or not it has ever signed in. That is what lets a grant be waiting for somebody rather than needing an invitation to be accepted. Owners can see and remove the grants they made; nobody else can read the list. See Folders and sharing.
Rooms: the script snapshot, the state, the join code	So a device that reloads mid-session lands where it left off.
Device labels: a platform string such as “iPhone · Safari”	So the connected-devices list is readable. No hardware identifiers.

What is not

No analytics, no tag manager, no third-party trackers.
No recording of anything you say, and no camera access, ever. The microphone is used in exactly one place: voice tracking, which only listens while you turn it on, and is described in full below.
No advertising identifiers, no fingerprinting.
No content sold, shared or used to train anything. Your scripts are yours.

Third parties in the path

Google and GitHub, for sign-in, and only the one you use. Supabase, which hosts the Postgres database and the realtime relay. Public STUN servers, which help two devices discover a direct route. They see IP addresses during connection setup, never message content.

Where it lives

Everything is in one Postgres database in a Supabase project, in seven tables prefixed teleprompt_. On the hosted instance that is our project; if you run your own, it is yours, and nothing reaches us at all.

What stays in the browser

Two values in localStorage, and neither ever leaves the device except as described below:

teleprompt.device: a random 128-bit identifier generated in your browser. It is the presence key on the realtime channel and the address for WebRTC signalling. It is not derived from anything about your hardware, and clearing site data regenerates it.
teleprompt.device.label: the readable name shown in the devices list.
teleprompt:voice: the language you picked for voice recognition on this browser. Only written once you change it.

The service worker caches the app shell and pages you have visited. It never caches API responses, so no script content is written to the HTTP cache.

What crosses the network

During a session, the messages between your devices carry the playback state: an anchor, a play flag, and the display settings. The script text itself is fetched over HTTPS from the server by each device separately; it is not streamed peer to peer.

When a direct WebRTC channel is open, those messages are encrypted end-to-end by DTLS and do not pass through any server. When it falls back to the relay, they pass through Supabase Realtime over TLS.

Voice tracking

This is the one feature that sends something you produce somewhere other than your own devices, so it gets its own section, its own switch and its own warning next to that switch.

With voice tracking on, the display asks the browser for speech recognition. That is a browser API, not a service we run: there is no key to obtain and nothing is added to a self-hosted deployment to make it work. What happens to the audio is therefore the browser’s decision rather than ours.

Chrome and Edge stream the audio to their vendor’s speech service and return text. That audio leaves your machine, under their privacy policy, not this one.
Safari does more of the work on the device.
Firefox has no built-in recognition, so the feature is unavailable there.

On our side: no audio ever reaches a Teleprompt server, no transcript is stored anywhere, and nothing about what you said is written to the database. The words come back into the page, are matched against your script in memory, and are discarded. The rolling readout under the script holds the last hundred or so characters and is thrown away when listening stops.

The room does record that a display is listening, because the remote has to be able to see it and switch it off. That flag is deliberately not restored when a room is reopened; a microphone should never turn itself on because of a saved row.

If this is not a trade you want

Do not press the microphone. Nothing listens until you do, the browser asks permission the first time regardless, and every other part of Teleprompt works exactly as it does without it.

Deleting things

Deleting a script deletes it, detaches it from any room that used it, and removes every grant that pointed at it.
Deleting a folder deletes the folders inside it and their grants. The scripts are moved back to your top level, never deleted.
Removing somebody from a share deletes the grant outright. A copy they made while they had access is their own script and stays theirs.
Ending a room deletes its device records, whether you end it yourself or it closes after five quiet minutes. A room that closed on its own releases them the next time the account opens a room or loads the dashboard, and stops reporting them straight away. The room row itself is marked ended.
To delete an account and everything attached to it, email the address in the privacy notice. Every table cascades from the user row, so removal is complete rather than cosmetic.