Privacy
Last updated
Written by reading the code, not from a template. It describes what StoryView actually does with what you record — what stays on your Mac, what leaves it and when, and who else touches it. It is not legal advice.
What StoryView is
StoryView is a Mac application that records your screen, your camera and your microphone, and writes the result to your own disk. Recording, editing, transcribing and building the step-by-step document all happen on your Mac, and none of them require an account.
Nothing leaves your Mac until you do one of three things: sign in and share a recording, turn on search across your library, or configure your own AI provider. Each of those is described below, and each of them is something you choose. Until you choose one, StoryView makes no network request carrying anything you recorded.
What stays on your Mac
Your recordings live in StoryView’s sandbox container, under Application Support in your home folder. So do the edits you make, the transcript, the step document and its screenshots, and every earlier version of an edit. Deleting a recording in StoryView deletes those files.
Transcription runs on this Mac. On macOS 26 StoryView uses Apple’s on-device speech model through the Speech framework; macOS downloads that model from Apple once and caches it system-wide, and the audio itself is never sent anywhere to become text. On older versions of macOS the local engine is not installed in this build, so StoryView reports transcription as unavailable rather than quietly sending your audio somewhere.
That claim is about transcription, and only about transcription. It is not a promise that your audio never leaves the machine — when you share a recording you upload the exported video, and the exported video carries its sound. We would rather say that plainly than write a sentence that is true of one feature and false of the product.
Signing in
Sharing needs an account, and the only way to make one is Sign in with Apple. Apple gives us your name and email address the first time you sign in, and never again; if you chose to hide your email, we only ever have the relay address. Clerk holds the resulting account — the Apple user id, the name and the email — and issues the session tokens.
Your Mac then trades one of those tokens for a long-lived device credential, which is what every later request carries. The credential is stored in the data-protection Keychain on this Mac; we store only its SHA-256 hash, so the secret itself exists in one place and it is yours. Alongside it we store this Mac’s name — the one in Sharing settings — as the device’s label, and the time you signed in on it, so a list of your Macs is something you can read.
While you are signed in and the app is open, it asks the server once a minute whether anything has happened on your shares. That request carries the device credential and nothing else.
What we store when you share
Sharing a recording uploads the exported video, with its audio and any camera, captions and effects baked in. Alongside it go a single poster frame taken from that export, for the link preview, when one can be rendered; the transcript, when the recording has one, as timed words together with the edit list that produced the cut; and, if you made one, the step document and its screenshots. The files go to Cloudflare R2; the rows describing them go to Convex.
From the transcript the server derives more rows: the transcript in segments, the AI artifacts described in the next section, and the state of each processing step, so a failure is recorded where it happened rather than as one blanket error. Trims you make on the share page afterwards are stored as new versions; earlier ones are kept, not overwritten.
Every share starts as a link: its token is sixteen random bytes, and anyone holding an unrestricted link can watch. There is no directory of shares and nothing on this site links to yours, so a share page is reached by its link and nothing else — but a link you forward, or post somewhere public, is a link you have given away. A share page is an ordinary web page: once its address is public, a search engine can index it like any other. A share record can carry an expiry date, and the server enforces it: past that moment the page and the media stop resolving. The owner can change or remove that date in the app, revoke the link, protect it with a password, or restrict it to exact email addresses and email domains. Passwords are stored as salted, deliberately expensive digests rather than readable text. An invited viewer gets in one of two ways. The email StoryView sends them carries a key of its own on its Watch link, and opening it proves that inbox — so forwarding that email forwards that way in. Or they sign in with Apple or Google so StoryView can compare the verified email with the list. Either way, a viewer who was invited at another address can ask the page to email a link there; the page answers the same whether or not the address is on the list. A successful check creates a short-lived access grant. A viewer who is not listed may ask for access; that request stores their account id, verified email, decision state and request time so the owner can approve or refuse it. Protected shares do not expose their recording title, description or poster frame to link-preview crawlers.
You can also send a share by email from the app. StoryView sends the message, through Resend, from share@storyview.app under your name, with replies going to your email address unless it is an Apple relay address. We keep a row for each email sent — the recipient's address, who sent it, any note, when, and whether it was delivered, bounced or opened — so you can see who you sent a video to. Sending to someone on an invited-people link adds their address to that link's list. Those rows are deleted with the share or the account. Every email carries an unsubscribe link; an address that unsubscribes, bounces or reports the mail as spam is kept on a list StoryView will not email again, whoever is sending, and that list outlives the sender's account so deleting an account cannot quietly re-subscribe anyone.
To stop someone guessing a share’s password, wrong guesses are counted per visitor. Your IP address is not what is stored: the share page reduces it to a keyed hash — an HMAC under a secret only our servers hold — and only that hash and a count reach the database, where the row is deleted within about two hours of the last guess.
A clip cut from a shared recording is a share of its own, holding only that stretch of the video and its transcript. It depends on the recording it came from: revoking or deleting that recording stops the clip too.
Viewers leave traces, and you see them. Each viewing browser mints sixteen random bytes into its own local storage and sends them back with the view — no cookie, no fingerprint, no third-party script, and no IP address kept against it. Against that key we store one row per viewing session: when it started, when it was last alive, how much of the video actually played, and how far into it the viewer reached. A viewer who clears their browser is a new viewer, which is why the counts say browsers and not people. There are two exceptions, and both are someone the owner named: a view through an invited-people access grant, and a view that arrived through the Watch link of an email StoryView sent, are recorded against that email address, so the owner can see that Dana watched 80% on Tuesday. If that email is forwarded, views through it still count as the person it was sent to. A view from a link copied out of the page or passed on any other way stays anonymous. Comments carry the name a viewer types into the box, their text, the moment they are anchored to, and that same browser key — which is how someone can delete a comment they wrote. A deleted comment is hidden but its row remains, so the thread keeps its shape. Reactions carry the emoji, the moment and the browser key. If you set a brand name or logo for your share pages, we store those too.
A workspace also keeps a log of administrative changes — renamed, a sharing default changed, a member joined or removed, a connection added or removed — with who made each one and when, readable in the app.
AI features
When you share a recording, the server sends its transcript — the words and their timings, as text — through OpenRouter to write the title, summary, chapters and action items, and to turn a step document into prose. No video, audio or screenshot is sent. Every answer is stored as a new version rather than replacing the last one, so regenerating never destroys what you had.
Searching your recordings happens on your Mac and sends nothing. So does AI with no provider set up: on a Mac with Apple Intelligence, Apple’s on-device model writes titles, summaries, chapters and answers to questions on the Mac itself, and nothing leaves it.
Having Claude answer your questions instead is off until you turn it on. It uploads transcript text only — never video, audio, camera or screenshots — for the recordings on this Mac, and turning it off deletes that index. When Claude answers, the question and the matching passages go through OpenRouter as well.
Managed AI comes with a monthly allowance per workspace, so we count what each workspace uses: how many requests it made, and what they cost us, worked out from the size of each request and its answer. That count holds no text from your recordings. It is what the AI meter in the app shows you.
If you configure your own AI provider, StoryView sends the transcript text of the recording you are working on to the endpoint you named, with the API key you supplied. That endpoint is not ours: what it logs, keeps or trains on is between you and whoever runs it. The connection must be HTTPS, redirects are refused so your key cannot be replayed at another host, and the key is held in the data-protection Keychain on this Mac only — not synced, not in a backup, not written to any preferences file. This path sends transcript text. It does not send your audio.
Who processes your data
These are every third party StoryView sends data to directly. Where one of them passes something further on, its entry says so.
Apple — Identity, and the App Store. Sign in with Apple authenticates you and tells us your name and email address on the first sign-in. Apple also distributes the app and holds the record of your download. Transcription uses the speech model that ships with macOS; installing it the first time is a download from Apple.
Clerk — Accounts and sessions. Holds your account — the Apple user id, your name and email — and issues the session tokens the Mac exchanges for its device credential.
Convex — Application database and backend. Stores every row described below: recordings, shares, transcripts, documents, comments, reactions, view sessions, devices and branding. Convex runs the functions that generate artifacts and answer searches.
Cloudflare — Media storage (R2). Holds the files themselves — the exported video, the poster image and the step screenshots — under a key that begins with your workspace id. Share pages read them through short-lived signed URLs.
OpenRouter — AI generation. Routes the model requests StoryView makes on your behalf: the summary, chapters, action items and document written from an uploaded transcript, and the answers to search questions. It receives transcript text and your question — never video, audio or screenshots — and passes them to whoever runs the model it routes to, which today is Anthropic.
Resend — Share emails. Delivers the email StoryView sends when you share a recording with somebody by email. It receives their address, your name, the video's title, length and poster frame, the link and any note you add, and reports back whether the message was delivered, bounced or opened.
Vercel — Hosting. Serves storyview.app and the share pages, and therefore sees the ordinary request logs any web host keeps.
How long we keep it
While you are subscribed, everything you have shared stays. Nothing is aged out, and no recording is removed to save us money. The only limit is the storage your plan allows, and the app tells you when you are near it.
A link is a different thing from the recording behind it, and has its own life. New links stop working after ninety days unless you say otherwise — the choice is on the link's own page, from a week to no end date at all. A link nobody opens for a year goes quiet by itself, whatever end date it has, so one you made and forgot cannot keep working indefinitely. Going quiet destroys nothing: the link is still listed, and one click wakes it and starts the year again.
You can take any link back at any moment, which stops it working for everybody who has it, and put it back just as easily. You can also delete a single recording from the cloud: that removes the uploaded video, every link to it, and the storage it was using, and it cannot be undone. The copy on your Mac is never touched by any of this — deleting a recording here does not delete it there, and deleting it there does not delete it here.
If your subscription lapses, nothing is deleted straight away. The links you have already shared keep working for thirty days, so a payment that failed does not take somebody else's deliverable down the same afternoon. After that the links stop, and your recordings are kept for a year from the lapse before they are deleted. Resubscribing at any point in that year brings everything back, because nothing was removed.
The app warns you when it opens, with both dates, for as long as you are lapsed. That is the only warning we can give you today — StoryView sends no email — so it reaches you if you still have the app installed and not if you do not. That is a real limitation and it is why the year is a year rather than something shorter.
Deleting your account
You can delete your account from inside the app: open Cloud Sharing and choose Delete Account. You will be asked to confirm that you understand what it does, because it cannot be undone.
It deletes everything you have uploaded: every recording and its media, every transcript, every document, every AI artifact, every comment, reaction and view record, your branding, your devices, and your workspace itself. Your share links stop working immediately — all of them, the moment the deletion runs. Your Clerk account is deleted, and the credentials StoryView held in this Mac’s Keychain are removed.
There is no grace period and no recovery window. A deletion that leaves your data on a server for thirty days is not a deletion, so we do not offer one.
The recordings on your Mac are not deleted. They are your files, they stay in your library, and StoryView opens afterwards showing all of them — unshared. If you want them gone as well, delete them in the app.
What we do not do
There is no advertising in StoryView and no advertising network is given anything. We do not sell or rent your data, and we do not share it with anyone outside the processors named above. There is no analytics SDK in the Mac app and none on the share pages: no Google Analytics, no tracking pixel, no session recorder. Opening a share page as a viewer loads no third-party script at all — the sign-in code is fetched only when the owner opens the stats panel or the editor, and the fonts come from our own origin, so reading a share page does not tell anyone else you read it. Clerk’s own usage telemetry is turned off. We do not train models on your recordings, and we do not read your recordings except when you ask us to look at something that has gone wrong.
Contact
Questions, corrections, or a request about your data: support@storyview.app.
If something here does not match what the app does, that is a bug in this page and we want to hear about it.
