T6FV Security Overview

THE 6-FIGURE VIDEOGRAPHER LTD. Mississauga, Ontario, Canada

Last Updated: November 1, 2026

This document is for the person who has to sign off on your team using T6FV. It describes how the app handles production data, what we can and cannot see, the controls we run, and — in Section 11 — what we do not have yet. It sits alongside our Privacy Policy and Terms of Use.

Which version this describes. A sentence that says "from version 2.0.10" or "from version 2.0.11" describes the app at that version and later. Version 2.0.10 (build 211) has been in the App Store and Google Play since October 19, 2026. Version 2.0.11 and later is, on the date above, on TestFlight, our Mac download and the web app, and not yet in the App Store or Google Play; what this page says of 2.0.11 reaches a store's users as that store carries it. A device that has not updated behaves as its own version did, and we say so where that matters.

The short version: most of what you would worry about never reaches us unless a user sends it. The production planner is local-first — briefs, scenes, shoot days, contacts, rates, invoices, footage and AI conversations live on the device. On a plan without a cloud library we run no sync for them; they reach us only when the user sends them — a T6FV Cloud Drive backup, which sends the takes the app holds at full resolution only if the user chooses to include them, and the app's automatic snapshots of the whole library (Section 4); a file they send to T6FV Cloud Drive from the File Manager; or what they publish on a client link (Section 3.2), on their Portfolio or in another community feature. Plans that include a cloud library copy the planning records — and, since this release, the pictures, documents and recorded audio those records point at — to our servers so that a user's own devices, and the people they invite to a binder, see the same work; footage and AI conversations are never in it, but every email a user files into a binder is, with its attachments. That copy is readable by us as the operator, and Section 4 says so rather than leaving it implied. Three features cross the internet sealed on the sending device: for two of them — Studio Link, and the recording a guest makes from a recording link — we hold no key at all (Sections 3.1 and 3.3 say what that rests on), and for the third — client links — we now hold one, which Section 3.2 states plainly rather than leaving you to find. The remainder — your account, what you put on T6FV Cloud Drive, and the community features you opt into — sits on Google Cloud and Cloudflare infrastructure under access rules, and we are explicit below about what that means we can technically read. We run no analytics, advertising or tracking of our own (two Google components report usage metrics about themselves, Section 4), and we run no cloud AI for the app; the one AI we run off a device is the assistant on our website, in Section 4. On a Mac or a Windows PC, a user can choose to connect an AI app they installed, to chat on their own API key from Anthropic, OpenAI or Google, or to chat with a model server they run at an address they type, and let the app's AI buttons work in T6FV through a key or a server; on any device an AI button can copy its prompt for the user to paste into an AI website they choose. What that AI reads then goes from the user's device to its provider, or to that server's address, under the user's own arrangements and never through us. We cannot see or control what happens to it there (Section 4, "AI connections"). Voice-overs in an AI voice, including the user's own voice, are made on the Mac, and the user's own voice never leaves it (Section 4).

1. The Three Places Your Data Can Be

Almost every security question about this app resolves once you know which of three categories a given piece of data falls into.

Where it lives Can T6FV read it?
Tier 1 On your device only No — we never receive it, unless the user uploads it (T6FV Cloud Drive, a client link), when it becomes Tier 3
Tier 2 Sealed on your device, carried by us Studio Link: no — we hold no key. Comparing the fingerprint the two devices show is the check against someone in between, us included (§3.1). A guest's recording link: we hold no key, but the page that seals it is ours, served on each visit (§3.3). Client links: since September 2026 the key rides in your own library (§3.2)
Tier 3 On our backend, under access rules Yes, technically

The rest of this document works through them in order. The important point is that the bulk of what a production company would classify as sensitive — client identities, rates, contracts, footage, schedules — is Tier 1 on a plan without a cloud library, unless the user backs it up to T6FV Cloud Drive (Section 2). On a plan that includes one, the planning records — and the pictures, documents, emails and recorded audio filed with them — move to Tier 3 for as long as the plan is held. AI conversations stay in Tier 1 on every plan. Footage and field audio takes stay in Tier 1 until the user sends them to us — a T6FV Cloud Drive backup (full-resolution takes only if the user chooses to include them), a file sent to T6FV Cloud Drive from the File Manager, editing copies shared for a production, a review cut on a client link or a video on their Portfolio — after which they are Tier 3. So is a small still, about 320 pixels across, of a file or take the user sends to T6FV Cloud Drive from the File Manager, which the cloud library carries with its other pictures. A recording made for somebody else's recording session also goes to their device, over the local network and never to us (Section 2). A guest who records for a session from a link in a web browser is different again: that recording crosses our storage, sealed in their browser with a key we never receive (Section 3.3). Tier 1 means we never receive them unless the user sends them to us. It is not a promise that they never leave the device: a user who connects an AI app, chats on their own API key or with a model server, lets an AI button work through one of them, or pastes an AI button's prompt into an AI website can let that AI read their work — through a connected app, including still frames and transcripts of footage — and the AI's provider receives what it reads from the user's device; the in-app cameras copy what they shoot to the device's photo library only if that is turned on, and the Directors Viewfinder does so unless its Copy to Photos is turned off; and dictation may send speech to Apple, Google or, on the web, the browser's maker, unless Keep speech on this device, from version 2.0.10, is turned on (Section 2).

2. Tier 1 — What We Never Receive

The planner is built local-first: it works fully with no account and no server, and on a plan without a cloud library we run no sync service for this data. The Educational plan can carry it between your own devices only through your own iCloud Drive or Google Drive folder, which we never receive, so we hold no copy of it unless the user backs it up to T6FV Cloud Drive, on a plan that includes it, which keeps the app's automatic snapshots of the whole library where we can read them (Section 4).

That stopped being unconditional on 2026-09-13. Plans that include a cloud library copy the planning records — the items marked ‡ below, including the contacts, rates and notes inside them — to Google Cloud Firestore, so that every device signed in to the account, and, on a plan that also includes sharing, anyone the account invites to a binder, sees the same work. While such a plan is held those records are Tier 3, and Section 4 describes them as such; they return to Tier 1 only when the plan ends and the hold in Section 8 expires. The library never includes footage, field audio takes, the mailbox cache, a mailbox password or AI conversations, on any plan. It does not carry your device's position either — but a location you deliberately save, such as a scouted site, is a planning record and travels like one. Two questions about a saved place are answered by our servers and not stored: its time zone, for which the app sends the coordinates rounded to two decimal places (about a kilometer), and a client link's shoot-day forecast, for which the page sends the date and the place rounded to one (about eleven kilometers). A connected mailbox's settings travel too, to the account's own devices only; the mailbox item below says exactly what that is. So do the app's own preferences — favorite tools, notification choices, theme, the desk background, the Graphics Editor's saved brushes — and Section 4 lists them. So does what a user records about each hard drive they add: its name, notes, tags and photo, the folders on it linked to productions, how to recognize the volume and a summary of its last scan — and, unless they switch it off for a drive, the listing of its last scan: every folder and file name it reached, with sizes and dates. Never a file from the drive. And it carries every email a user files into a binder, with its attachments: the mail item below says what that means.

Every plan with T6FV Cloud Drive storage includes that cloud library (Indie, Freelance, Pro and Agency, and the Beta testers' plan), and each device uses it unless the user chooses their own folder on that device. A device on Indie, Freelance or Beta that was syncing through its own folder when those plans gained the library, in version 2.0.13, moved to our library once, by itself. It keeps copying the records it sends us into that folder as a backup until the user stops it. On Pro and Agency, a device set to its own folder that has none set up, or whose iCloud folder can no longer be found (signed out of iCloud, say), goes on syncing through our library rather than stopping. On Indie, Freelance and Beta such a device waits, and says so, rather than reaching our servers. Sharing a binder with a team needs our library and the Pro or Agency plan. On a device several accounts use, the one-time move holds our library for the moving account alone, and the device's route and every other account's choice stay as they were. The route itself stays the device's: an account new to that device syncs through the folder it already uses until it chooses our library, a folder one account chooses becomes the route of every account there for which our library is not held, and Stop on a folder route forgets the folder for every account there, so a Pro or Agency account that had chosen it falls back to our library at its next sign-in there. Google Drive sync writes to a folder in the person's own My Drive; shared drives are not supported. Even on the folder route, some things still reach our servers: the account record (Section 4); a short index of the user's client links, which names each link's binder; each push notification's title (Section 6); a saved place's rounded coordinates when the app asks its time zone, above; what a client link carries (Section 3.2); the Studio Link relay's routing records (Section 3.1); and whatever the user sends to T6FV Cloud Drive.

It widened on 2026-09-16. A record carries a path, not bytes, so until this release a second device received a library whose pictures were placeholders. The library now carries the files themselves — the pictures a record points at, documents and emails filed into a binder, audio recorded in the music tools, and any record too large to be a Firestore document — as objects in Cloudflare R2. They are Tier 3 on the same terms as the records, and Section 6 names the store.

And a user can open three exits themselves. An AI button can copy its prompt — which can include project details and, for the mail summary, email text — to the clipboard, for the user to paste into an AI website they pick and send; on every platform but the web the app also opens that website for them, and with no on-device model installed it goes straight there. On a Mac or a Windows PC a user can also connect an AI app installed on the same computer, or chat in the app on their own API key or with a model server they run, and let it read what they choose, including items below that never reach us: still frames, captions and transcripts of footage, and contacts, rates and notes on a plan without a cloud library. The AI's provider, or the server at the address the user typed, then receives what it reads, from the user's device. We still receive none of it. Section 4 describes the controls.

Stored on your device, and uploaded only under a cloud-library plan where marked ‡:

What this means for you: on a plan without a cloud library, our servers hold none of the above unless you send it to us: a T6FV Cloud Drive backup holds the app's automatic snapshots of your library and, if you choose to include them, your takes, and a client link (Section 3.2), your Portfolio or another community feature holds what you publish there. What you have not sent us, we could not produce if we were compelled to, and a full copy of our database and storage would not contain it. We consider that a stronger guarantee than encrypting it would be, because it removes us from the picture entirely. On a plan with a cloud library the guarantee narrows to footage and field audio you have not uploaded, your device's position, mail you have not filed, mailbox passwords and AI conversations, and the marked items carry the Tier 3 guarantees in Section 4 instead. None of this changes if a user connects an AI app, chats on their own key or with a model server, or uses an AI button's hand-off or Connected AI: what that AI reads goes to its provider or to that server, not to us, so it is still not in our database and still not ours to produce. It is in the provider's hands, under the provider's terms.

The honest limits. Unless a person turns on protected mode on a device, the app adds no encryption of its own to what it stores. Protected mode, from version 2.0.11 and off until someone turns it on or a company's policy requires it, is offered on an iPhone, an iPad, an Android device and a Mac — not on Windows yet, and not in a browser. It encrypts the library database, the automatic backups, the mail kept on the device and the drives' listings with a key made on that device, which is not synced, not sent to us and not carried by a device backup, using the platform's own cryptographic module; it does not cover recordings, footage, renders or binder files, the copy of a cloud library that our database's software keeps on the device for offline use, or the app's preferences; a backup restored onto another device cannot open what it encrypted, and it does not stop someone using the device while it is unlocked. Without it, the app's database, its mail cache, its automatic backups (on by default, kept for up to a year, and the newest whatever its age) and its media are protected only by the operating system's disk encryption and passcode, which you enable, and which a company should enforce with MDM; the app shows whether a device has them, under Device security in its settings, but does not require them unless a company's policy does. On an iPhone or iPad its files use the default Data Protection class, which leaves them readable whenever the device has been unlocked once since it started. iCloud device backup and Time Machine copy the app's data unless Keep T6FV data out of device backups is turned on, and the passwords and keys the app keeps in the keychain stay on the device and are not carried by a device backup, except the passwords set for backups on hard drives. On the web, the library and a session that survives a browser restart live in the browser's storage. Several T6FV accounts used under one operating-system login are kept apart by the app, not by the operating system — use separate operating-system users where the separation has to be strict. Signing out asks whether to keep the library on the device; a library kept there is locked in the app until that account signs in again — hidden, not encrypted. If someone has an unlocked device, they have the data on it — the same as any other app.

3. Tier 2 — Sealed on the Sending Device

Three features send data across the internet sealed on the sending device and opened only on the receiving one, and our servers carry ciphertext. They differ in who holds the key, and September 2026 changed it: for Studio Link we hold no key — the two devices agree it between themselves and never send it, and comparing the fingerprint the two devices show is the check against anybody, us included, sitting between them (Section 3.1); for a guest's recording link we hold no key, though the page that does the sealing is one we serve (Section 3.3); and for a client link the key now travels in the owner's cloud library so that every device on the account can republish and edit a page and collect what clients send to it, not only the handset that published it. Until September 2026 this heading promised no key at all; Section 3.2 is why it no longer does, and why we would rather retitle a section than leave a sentence standing that has stopped being true.

Studio Link mirrors a live production to other devices — a director's monitor, a producer's laptop — over the local network or, when the devices are not together, through a relay we operate.

Because the key is never sent, a copy of what the relay carries — a backup, a leaked export, a misconfiguration on our side — opens nothing. That much is a property of the arithmetic, not of our access policy, and it does not depend on us behaving well. An active attack by whoever runs the relay is a different threat, and the fingerprint check above, not the arithmetic, is the defense against it. The relay also keeps routing records — the host's and admitted accounts' identifiers, device identifiers, the share pages a session serves, the studio's name and the host's addresses on its local network, and, if the host opens the job list, its productions' names — which are not sealed and which we can read.

When you send a client a link to a call sheet, script or schedule, the content is encrypted in the app before upload. The decryption key derives from a token carried only in the URL fragment — the part of a URL after the #, which browsers do not transmit to the server. It therefore never reaches our hosting logs, any proxy in between, or a Referer header on an outbound click.

The viewer page performs the decryption in the browser.

What changed in September 2026, stated plainly. This paragraph used to end "we hold the ciphertext and no way to open it". That is no longer true, and it was the first claim of its kind we had to withdraw (Section 3's "cannot acquire one", for Studio Link, was the second). The link's token is now kept in the owner's cloud library — one record per link, carried like any other — so that any device they sign in on can republish a page, edit it and collect what the client has sent to it. Revoking does not need it: our servers revoke a link on the account's word alone, and from version 2.0.10 a device that does not hold a link's record still lists the link, from an index on our servers that carries no token, and can revoke it — so a link made on a phone that was later lost can be closed from any other device.

What that buys, and what it costs, stated exactly rather than left to be inferred:

What the URL fragment still does is unchanged and still worth having: the token is never sent to a server by any browser, so it stays out of our hosting logs, out of any proxy in between, and out of the Referer header on an outbound click. A page's address can be shared, logged or scraped without the key going with it. What the fragment no longer does is keep the key away from us.

What is not sealed, stated plainly. A link's preview — the binder's name, the "Shared by" line and the cover image — is stored in clear with the link, and neither the cover image nor the studio's logo is sealed on any link. Every new link starts with its preview on, password and team links included, unless the company's policy keeps previews off, and the user can turn it off for each link; a link made before this change keeps the setting it had. Where it is on, for open, password and team links alike, the preview is shown to anyone who has the address, including chat apps that unfurl it, before any password or sign-in is asked, and the card's site name is the studio's company name, or the user's name where no company name is set. With it off, and on a link that has expired or been suspended, a chat shows a plain T6FV.io card that names neither the binder nor the studio. A link can carry pictures, video, audio, PDFs and any file a studio delivers, up to 100 GB each, sent in parts, as well as a "Download all" archive, and file types are neither restricted nor scanned. On an open link every file is plaintext. On a password or team link published from version 2.0.8 (build 209), files of 32 MiB or less are sealed with a key of the link's own, which travels inside the encrypted payload; larger files, and every file published from an earlier version, are plaintext. Our servers can copy a file onto a link from its copy on the user's own T6FV Cloud Drive, whether or not the publishing device holds it. The copy is made server to server, under the name an upload of the same bytes would get. It is made only from the user's own backups folder on the drive, never from its restore points, indexes or receipts, and only while the object is the size and checksum the file's record names. A file of more than 4 GiB is not copied this way: the publishing device sends it if it holds it, and otherwise it is left off. Our servers pass over such a file's bytes once, to compute its SHA-256 and CRC-32, and keep those two, the object's ETag, its size and the time beside the account, readable by no client, until the account is deleted. On a password link, such a file of 32 MiB or less that the publishing device does not hold is downloaded to it to be sealed, because our servers never hold a link's key; the download is made only once T6FV Cloud Drive reports the size, and where both name one the checksum, that the file's record names, and is cut off past that size. The downloaded copy, its sealed copy and the previews made from it are deleted when the publish ends, or at the app's next start if it was stopped first. A publish refused while moving a link from its address from before version 2.0.10 can keep such copies, each of 32 MiB or less, in the account's own folder on the device until the link has moved. Plaintext files are served over HTTPS without sign-in, under long, unguessable names that are themselves inside the encrypted payload, so finding one normally takes the link; but an address that leaks by other means keeps working until the file is deleted. Revoking a link deletes its own files at once and asks Cloudflare to drop its cached copies of them; a file that another live link of the same account also shows is kept for that link, and a browser or proxy that already fetched a file may keep its copy for up to an hour. Letting a link expire is different: expiry closes the page and deletes nothing, so its payload and files stay where they are, and anyone who already holds the link's address (and, for a password link, its password) can still fetch and open them, until the link is revoked or deleted as Section 8 describes. A hosted review cut is streamed as AES-128-encrypted HLS: our servers derive its key and give it to every viewer the link admits, so anyone who can play the cut can save it, and deleting the cut does not reach a copy already saved. Revoking the link does not take back a key a viewer kept: it goes on working until you delete the cut, and on copies still cached at Cloudflare's edge for a while after that. That is access control, not DRM (Section 11). If any of this matters for a particular deliverable, do not attach it to a client link.

Passwords and Allow downloads. A link's password, on a password link or a team link, can be any length. The app recommends ten characters or more, warns below that, and starts every new link on a generated five-word passphrase; account passwords keep their ten-character minimum (Section 5). The page has no limit on guesses, so a short password protects little. Turning off Allow downloads hides the page's download buttons and the download option in its own video and audio players; it keeps an invoice's PDF, a script's or scene's "Print or save", and calendar and contact files. It is not access control: anyone who can open the page can still save what it shows, and an older version of the app that edits the link turns downloads back on.

What readers write on a link. A link can let its readers leave notes on its deliverables and, from version 2.0.11 where the studio turns comments on, comment on the files it shares. The page seals each one in the reader's browser and writes it twice. One copy goes into the link's inbox for the owner's app to file, under a key from the link's token, and only the account hosting the link can fetch it. The other goes into the link's live thread, which every reader of the link can fetch and decrypt. On an open link the thread's key comes from the token, so the thread is as private as the address. On a password link published by version 2.0.11 or later it comes from the link's password and token together, and the owner's app re-seals the rows written before. A row that an owner's device on an earlier version, or one that missed the change, writes or rewrites there afterwards (a reply, or a tick on a reader's note or comment) is sealed under the token's key, and the re-seal, which moves only rows from before the change, leaves it there: the page does not draw it, but the address opens it. A password link last published by an earlier version takes no comments on files and writes its new rows under the token's key until a later version publishes it again. On a library we serve we hold the token and the password, so we can open the thread as well as the page. Beside each sealed row the page stores, unsealed, the time our server received it and a tag made from the page's anonymous sign-in and the link, the same for every row one browser writes on that link, which our servers count to slow a browser that writes too much. A reader cannot change or delete a row; the owner can, and the weekly clean-up keeps the newest 200 a page reads. A comment on a file is shown on every link with comments on that shows the same file, under whatever name the reader typed, which nothing checks: the page and the app draw it as plain text, just as it was typed, and only the rows the studio's own published copy marks as its own carry the studio's label, whatever name is typed. A comment carries no file, only words and a moment, a spot or a page of the owner's file. The studio's own notes on a shared file, written in the app on a device that has accepted the privacy policy of October 28, 2026, go on the page in the link's published copy and, on a link with comments on, into the live thread as a reply does, under the same key; deleting one deletes its live row from every link. A reader's browser keeps what it sent, unsealed in its own storage, until the link's published copy carries it or for a week, at most 100 for a link, and drops it with the link's remembered key.

Location metadata: from version 2.0.8 (build 209), pictures the app re-encodes for a link lose their EXIF data, GPS included. Pictures published from earlier versions kept theirs; delivered files upload unchanged with whatever metadata they carry, and so did review copies sent at their original size before version 2.0.10, which blanks their metadata; and a few pictures the app places as they are — logos on invoices, Lighting Diagram camera pictures and AV rundown frames — keep theirs. A link that shares a binder's Footage or Exports carries the files kept there as they are, including the SRT files cameras write beside their clips, which can hold a GPS track, and their XML files, which can name the camera's serial number. Clips not yet sorted, and the files that came with them, go on a link only when the user picks them.

A host running a recording session can invite a guest who has no app and no account to record their microphone from a link in a web browser. The guest is usually somewhere else, so their recording cannot go over the host's network the way a joined device's does (Section 2); it crosses our storage instead.

Where this differs from Studio Link. Studio Link's cipher runs in the app on each device. A guest's cipher runs in a page that the guest's browser fetches from t6fv.io each time the link is opened, uncached, and that page also loads Google's reCAPTCHA (App Check) to tell a person from a script. So the property above is true of every recording already made, and of recordings made later only for as long as that page — and the script it loads — is not changed to send the link anywhere. The page's content security policy is in report-only mode today, so it does not yet restrict what the page could load. That is a weaker guarantee than Studio Link's, and the one-line answer in Section 1 says so.

What is not sealed is what running the link needs, and it is Tier 3 (Section 4):

Before the guest agrees, the page already requests an App Check token (not yet enforced by our servers), signs in anonymously, claims the link, measures its clock against ours and reports every fifteen seconds that it is waiting, with the browser label, the round trip and how much is left to send. The microphone stays off, and nothing is recorded, until they agree.

The recording is stored in Cloudflare R2 under the host's account, counted against the host's storage, and deleted when the host's device collects it. One never collected becomes due for deletion fourteen days after the expiry its link had when it was made, and our weekly sweep deletes it the first time it runs after that — normally within twenty-one days of that expiry (Section 8).

3.4 Live Show Guests

Not yet available. Release builds of the app cannot make a guest link for a live show; the feature is switched off in them until a later version turns it on. This section describes how it works in the builds we test, and how it will work then.

A host running a live show in Virtual Broadcast will be able to invite a guest who has no app and no account to join from a link in a web browser. The guest's camera and microphone go straight between the two browsers over WebRTC, which encrypts the media; there is no relay of ours, and the only other servers involved are the public STUN servers both browsers ask for their own address (Google's stun.l.google.com and Cloudflare's stun.cloudflare.com), which see each browser's IP address. We never carry, see, record or store the guest's picture or sound.

The browsers exchange their handshake through our database, and it is sealed: the offer, the answer, every network candidate, the name the guest types, and the show's and guest's names the host entered are encrypted with AES-256-GCM under a key derived (HKDF-SHA256) from a 32-byte token that lives only in the link's fragment, which a browser does not send to a server. Our server checks that a caller holds the link through a fingerprint of a proof made from the token, never the token. What we can read is what routing needs: the host's account, when the link was made and expires, which anonymous sign-in claimed the guest's place and when, and whether the call was offered, left or ended; plus, as for any request, the IP address and user-agent in our server logs for thirty days, and the IP address as the key of rate-limit counters that expire within two hours. The link is itself the key: whoever holds it can take the guest's place until it expires or the host ends it. A show's link records are deleted by a daily sweep a day after they expire, and at once with the host's account (Section 8).

4. Tier 3 — What We Hold

Creating an account is optional; the app's planning features work fully without one. If you create one, the following sits on our infrastructure, protected by transport encryption, provider-side encryption at rest, and server-enforced access rules — but readable by us as the operator, and we would rather say so than imply otherwise:

We do not sell this, share it for advertising, or use your content to train AI models.

No analytics, tracking or advertising of ours. The app has no analytics, crash-reporting or advertising SDK of ours and no tracking identifiers, and our App Store privacy manifest declares no tracking domains. Two Google components the app includes — ML Kit, which runs its on-device text recognition and translation (and, on Android, face and pose detection and selfie segmentation, which also finds the faces in footage for a person to name, on the device, without recognizing anyone and without keeping any picture of a face), and Firebase Cloud Messaging, which delivers notifications — carry Google's own telemetry transport and send Google usage and performance metrics about themselves. The app's subscription library, RevenueCat's, sends RevenueCat the account's identifier, its store purchases, and the device and app details its SDK attaches (Section 6). Google's reCAPTCHA runs on the pages we host that use App Check, to request a token — a client link's page, a guest's recording page, Studio Link's share pages, our contact forms (the homepage's, the page for in-house video teams' and a Portfolio's), and our sign-up and reward pages — and Cloudflare Turnstile runs beside the assistant on our homepage and our page for in-house video teams, to tell a person from a script (Section 6).

No cloud AI of ours in the app. The app's own assistant runs on-device using models you download explicitly. We hold no LLM API key, in the app or on our servers, and the app never sends a prompt or document to an AI provider on its own initiative. The "My AI" hand-off on the app's AI buttons copies the button's prompt — which can include project details and email text — to the clipboard, and on every platform but the web opens an AI website for the user, who uses it under their own account with that site; nothing is sent until the user pastes and submits it. From version 2.0.10, on an iPhone, an iPad or a Mac the copy stays on that device rather than passing to the person's other Apple devices, is marked to be hidden from clipboard-history apps, and is set to expire after an hour — on a Mac, cleared after an hour only if the app is still open and nothing else has been copied since; on Android and the web, and on Windows once a Windows build ships, it is ordinary clipboard text that other apps can read, as it was everywhere before 2.0.10. The hand-off is outside the AI-connections switch below, the sensitive-area switches and any company control. Where a site opens in the app's own browser view rather than the system browser, that view keeps its own persistent cookies and, on Apple platforms, presents a Safari-like user agent, so managed-browser policy and browser DLP do not reach it; the desktop's Web Viewer, a general browser inside the app, is the same.

AI connections (Mac and Windows, off until the user turns them on). Four features let a user send their work to an AI they choose. None of them passes through our servers.

A server-side switch that only we operate can turn all four off, for every customer at once. A company's policy can turn each off for its people, and three of them — Connected AI's use of T6FV's tools, the chat's four sensitive areas and model servers — start off for a company's people in every workspace, including one already switched on, until its Owner or an Admin seat turns them on; turning on the chat or Connected AI does not turn them on. Only one source file in the app names a provider's endpoint, and a test pins that; a model server's endpoint is the address the user typed.

AI voices and your own voice (Mac). The app can make a voice-over from text on the Mac with a speech model that runs there (Qwen3-TTS 1.7B, our conversion of Qwen's published weights by published steps, about 1.5 GB, downloaded from models.t6fv.io after its licence is accepted and checked against a published checksum). T6FV's voices come with the app and are not anyone's voice: the model made each with no reference recording of a person. Making a voice-over sends nothing anywhere. Every voice-over file carries a machine-readable mark that it was made by AI, and every export with one in it a mark that it was made partly by AI; the marks never name the user, the account or the voice, and an export that cannot be marked stops rather than going out unmarked. The device's built-in system voices and Apple's Personal Voice are never used. A user can also make a voice of their own, only by recording it live in AI settings › Voices, never from a file and never at an AI's request: they agree first, read a consent sentence and three short sentences aloud, which the on-device Whisper model checks for the words only, and the app keeps one reference recording and a dated record of the agreement with no audio. We treat that voice as biometric data: it is never sent to us or anyone, never synced, never in T6FV Cloud Drive, a vault export or the device's own backups, never given to an AI app, never used to identify anyone, and using it for a voice-over always asks first. It is not offered to someone who says they live in Colorado, Illinois, Texas or Washington, or on a device found there by a location already allowed, and such an answer deletes every own voice on the device (Section 8).

The one AI we run: the assistant on our website. Our homepage and our page for in-house video teams answer visitors' questions about the app with an open-weight model that Cloudflare runs for us (Workers AI). It is reached through a platform binding rather than an API key, reads only our public user manual and what the visitor types, and never touches an account or anything in one. Questions and answers are not stored, logged or used for training; a daily count per visitor is kept under an HMAC of the IP address keyed by a random secret made for that day — a pseudonym that cannot be worked back to the address without the secret — and the count and the secret are deleted by an alarm at midnight UTC.

Videos embedded on other websites. On a plan that includes it, a user can let a finished hosted cut play inside other websites: any website that carries its embed code, which is how an embed starts, or only the websites they list. Embedded videos are served from play.t6fv.io, a separate site that holds no sign-in, cookie or storage. The page tells the browser which websites may show it: for a listed embed, an enforced frame-ancestors policy built from the owner's list, which anyone who opens the player can read; for one on any website, a frame-ancestors policy that lets any website show it, the rest of the page's policy the same. It plays only after a visitor presses play: until then it loads only the player and, for a video that has one, its still frame, both from play.t6fv.io, and the video's pieces come from our media host only once Play is pressed. The video is AES-128 HLS like a client link's, but an embed plays a copy of its own, under a key of its own, because that key reaches every browser that opens the embed: the key that protects the cut on client links is never handed out this way. A browser shows a listed embed's player only inside the owner's websites, and one on any website wherever its code is pasted; either way, anyone who has the player's address can fetch its ticket and save the stream, so an embed is unlisted, not confidential. Stopping embedding or getting a new code deletes that copy and stops new plays within about 20 minutes; a key someone saved then opens nothing we serve. We hold the websites listed, if any, and a count of plays per month, kept about 13 months and never naming who played; a play is counted once per IP address per embed every ten minutes, with the address held only in the memory of the server that counted it, and request logs keep the IP address and browser of each visitor that loads the player for thirty days.

5. Accounts and Access Control

5.1 Two-Step Verification: Scope and Recovery

Three things about it that an assessment will ask, stated here rather than discovered later.

It is on every plan, and optional. From version 2.0.10 (build 211), any account can turn two-step verification on, whatever its plan, the free plan included; before then only Pro, Agency and Educational accounts could. Nobody is required to: no plan, company or binder owner can make it compulsory (Section 11).

Once it is on, it is asked for every time. Once a factor is enrolled it is demanded on every sign-in, on every platform we ship, permanently — whatever the plan, including if a subscription later lapses. A billing change never weakens an account, and a cancelled subscription is not a way to unlock one.

There are no backup codes and we cannot reset it by email. Both are common and both would place the account's real security at the level of whatever could steal them — a screenshot in a camera roll, or a compromised inbox. A recovery path that is weaker than the factor it replaces sets the true security level, so we do not offer one. Instead:

What we do not yet support: hardware security keys (WebAuthn/FIDO2), passkeys, and SMS as a second factor. SMS is a deliberate omission — it is the weakest of the common factors — but hardware keys are simply not built yet.

6. Infrastructure and Sub-Processors

The app runs on Google Cloud (Firebase). Our sub-processors:

Sub-processor Purpose What it receives
Google / Firebase Authentication, database, storage, serverless functions, hosting Account data, published community content, encrypted relay traffic and the relay's routing records, the cloud library on plans that include it; for a recording link, the guest's anonymous sign-in and the Tier 3 details in Section 3.3
Cloudflare (R2) Storage for client export links and the review video they host, and for a video embedded on other websites, whose pieces it delivers to those websites' visitors; T6FV Cloud Drive, including its backups and the editing copies shared for a production; on a plan with a cloud library, the files that library carries; and guests' recordings from recording links, until the host's device collects them Encrypted payloads; link media and delivery files — sealed with the link's own key when 32 MiB or smaller on a password or team link published from version 2.0.8, and plaintext otherwise, as a link's preview image and studio logo always are (Section 3.2); hosted review video as AES-128 HLS whose keys our servers derive; T6FV Cloud Drive files as uploaded (Section 4); library images, documents, filed emails, recorded audio and oversized records; a guest's recording, sealed in the guest's browser with a key neither we nor Cloudflare hold, and the IP address of the browser uploading it (Section 3.3); an embedded video's own copy, as AES-128 HLS under its own key, and the IP address of each visitor's browser that fetches its pieces (Section 4)
Cloudflare (Workers AI, Turnstile) Answers questions on our homepage and our page for in-house video teams with an open-weight model, and tells a person from a script there A visitor's questions and the answers in one visit, not kept; the IP address of the browser asking. Never an account or anything in one
RevenueCat Subscription management Your account identifier and purchase status
Stripe Card payments your clients make to you on client links, into your own Stripe account (or, while you hold a seat in a company's workspace, its Owner's); and card payments of our own Agency invoices, into ours From us: your country and T6FV account identifier when you connect your Stripe account; for each payment, its amount, currency and invoice number, our identifiers for the account, link and invoice it is for, the payer's email if they gave it on the link's page, and the Stripe account it goes to. From the payer, on Stripe's own page: their card details and the name and email Stripe asks for. Card details never reach us
Google (Gmail SMTP) Transactional email Your email address and message content
Firebase Cloud Messaging (Google) Sends the notifications you allow to your devices Each device's push token, and each notification's title, which can name the client or person it is about
Apple Push Notification service (APNs) Delivers those notifications to Apple devices The same token and title, passed on by Firebase Cloud Messaging

Google's reCAPTCHA, which the pages we host load to request a Firebase App Check token, is not listed either: Google runs it under its own terms rather than as our processor, and we receive only its verdict (Section 3.3).

Our mailbox, info@t6fv.com, is hosted by A2 Hosting, in the United States, on our older t6fv.com domain. It is where vulnerability reports and privacy requests arrive, and where both of our website's contact forms and a client page's "Report this page" deliver, so A2 Hosting holds what is sent there.

Some services are reached from the user's own device rather than by our servers, at the user's direction, so they are not on the list above either: the operating system's or browser's speech recognition, which may send dictated audio to Apple, Google or the browser's maker (Section 2); OpenStreetMap, for maps and address search; Google Fonts, for a font the user picks; YouTube and Vimeo, for embedded videos; DuckDuckGo, for the optional AI web search; and the AI providers a user connects (below). Separately, two Google components the app includes — ML Kit and Firebase Cloud Messaging — send Google usage and performance metrics about themselves (Section 4).

AI apps a user connects, the AI providers whose API keys a user enters (Anthropic, OpenAI and Google), and model servers whose address a user enters, are not on this list. They receive content from the user's own computer, at the user's direction and under the user's own arrangements with them. We do not engage them, pay them, or send them anything, so they are the user's providers rather than our sub-processors.

Apple WeatherKit answers the forecast on a client link page. It is not listed above because it receives no account data: our servers send it a shoot day's date and a place rounded to about eleven kilometers, with no account, name or reader's IP address, and keep nothing of the question.

The secret credentials and keys our server functions use are held in Google Secret Manager; one of them, the legacy vault format's key, keeps nothing secret, because it is also built into every copy of the app (Section 11). Our repository contains no service-account keys. Our server functions run under one service identity, which can read every one of those secrets.

7. Data Residency

Our database, accounts, server logic and transactional email are in the United States, and so is our mailbox, which A2 Hosting holds (Section 6).

Files are not region-pinned, and you should know that before you ask. What you put on T6FV Cloud Drive, the media and review video on your client links, the videos you embed on other websites, and the pictures, documents and audio a cloud library refers to are stored on Cloudflare R2, which is a global network rather than a named region, and Cloudflare may hold or serve them outside Canada and the United States, and processes them on our instructions. A guest's recording on its way to the host is stored there too, as ciphertext under a key we do not hold (Section 3.3).

We do not currently offer a choice of region for either. For customers transferring personal data out of the EEA, UK or Switzerland, the relevant safeguards are described in our Privacy Policy.

8. Retention and Deletion

Account deletion is available in the app and runs server-side: it removes the account record and its subcollections, deletes associated stored files, removes the authentication user, and removes the account's identity from forum and community posts, which remain — a forum thread keeps its replies but loses its author identity. Some things outlive the account: its name on activity in binders other people own, its public Directory profile, which can stay listed after the account is gone, and the Studio Link relay's routing records and its count of the account's relay use (Section 3.1). Records of payments and invoices are kept, for tax and for payment disputes, and nothing deletes them on a schedule; so are the subscription records at our billing provider and our copies of the emails we sent.

On your device, a deleted binder or project stays in Recently deleted for 30 days and in the app's automatic backups — on by default, plain files kept for up to a year (the newest whatever its age), removed with "Delete all backups"; from version 2.0.10 a deleted binder is taken out of those backups 31 days after the delete. Removing an account from a device, from version 2.0.10, also deletes its downloaded mail and mailbox sign-ins, the passwords set for its backups on drives, its live-stream keys and its automatic backups, and clears the database's offline copy at a later start of the app, once anything it has not yet sent has reached us; earlier versions left those behind. The on-device assistant's chats belong to the device rather than to an account, and stay. A user's own voice, and the record that they agreed, are deleted together when they delete it, when the account is removed from the device or a company seat's data is cleared from it, when they say they live in Colorado, Illinois, Texas or Washington or the device is found in one of them by a location already allowed (every own voice on the device then goes), and once it has gone unused for 365 days. Your operating system's backups keep their own copies, and deleting the app from a Mac leaves its data folder. We have no copy unless you sent it to us — on T6FV Cloud Drive, a client link, a community feature or a cloud library.

The cloud library is held while the plan that includes it is held — the records, the files in R2 that those records point at, and the client-link tokens, mailbox settings, app preferences, hard drive details and hard drive listings it carries, all of which go wherever this paragraph says the library goes. An object no record vouches for any more is reclaimed by a sweep that runs weekly; nothing deletes a file on the user's own device. When paid access ends, syncing stops and the copy is kept unchanged, and served to nobody, for 60 days so that resubscribing restores it; the account holder is emailed when the hold begins and again before it ends, and at the end of it the copy is permanently deleted. Deleting the account deletes it immediately, without the hold. The copy held for somebody invited to a binder is deleted as soon as they are removed, leave, or the binder stops being shared. A move from Pro or Agency to a plan that keeps the library but not team sharing (Indie, Freelance or Beta) freezes the user's shared binders instead. The team stops receiving them and is emailed once. If no plan with sharing covers the account again within 60 days, what the binders published to the team, and their activity feeds, approvals and sign-offs, are deleted. The user's own library stays, and so do the member lists. Hosted review cuts, Portfolio videos and images, and T6FV Cloud Drive files are not part of the library: the hold does not delete them, and they stay until the user deletes them or the account. So do the member lists of the binders the user shared; their activity feeds, approvals and sign-offs are deleted with the library at the end of the hold.

A deleted company binder is held in the company's trash for 30 days, during which its Owner or an Admin seat can restore it, and its records are then deleted. Paperwork filed to it, the decks, drawings and Ideas Boards the app keeps apart from a binder, and the original uploads in its holder's library are not: they stay in the holder's library. While the company is suspended or its workspace is switched off, the 30-day purge pauses, but a binder is deleted two years after it was trashed whatever the company's state. A former seat's archive is kept until the company's Owner deletes it, and at most two years after the seat ended: a job that runs daily closes the client links still waiting on it from day 715, tells their holder, and deletes the archive — with the person's name, email and the other records of that seat's ending — on its first run from day 729. An archive made by handing a binder between seats is kept until it is brought into a library, with a yearly reminder, and then deleted. A long-suspended seat's own account deletion copies its company binders to the company before the account is deleted. A company's invoice list is kept while the company exists and deleted when it closes, with the Owner's requests still waiting on its seats' apps; once the company is closed, no payment event writes to it again. Closing a company ends every seat and makes each company binder an ordinary binder of its Owner's; it is not an erasure, and its trash and archives are kept to the limits above. A person whose seat ends keeps their own T6FV Cloud Drive — which can hold backups of company work — hosted video, decks and Ideas Boards.

Client export links follow the same 60-day hold when paid access ends. On an active plan, a link that no client has opened for twelve months is deleted, with an email to the account holder at least thirty days beforehand; a pay link is also deleted when its invoice is voided or deleted. Revoking a link removes its payload, its inbox, its thread of notes and comments and the files only it shows, at once, and asks Cloudflare to drop cached copies; a file another live link of the account also shows stays for that link, and a file whose delete fails is left to the weekly sweep (Section 3.2). Expiry deletes nothing: an expired link's page closes, and the link and its files stay until it is revoked or one of the deletions above removes it. A comment the owner's app had already filed stays in the owner's binder until they delete it.

A guest's recording from a recording link is deleted when the host's device collects it. One that is never collected, or never finished uploading, becomes due for deletion fourteen days after the expiry its link had when it was made, and the same weekly sweep deletes it, with its Tier 3 details, the first time it runs after that — normally within twenty-one days of that expiry. A link stops taking new recordings when it expires — each time it is set, at most eight days ahead, enforced by our database rules — or when the host turns it off or ends the session. A recording already under way when the session ends has up to a day to finish, never past the link's expiry, and a piece already given an upload address can still arrive up to an hour after any of these. The links' own records, including which anonymous sign-in held each link and the page's status reports, are deleted by that sweep once the links have been expired for a day, and the session's own record — whose session it is, and until when — once none of its recordings is left with us; the anonymous sign-in itself is deleted by our authentication provider about thirty days after it was created. Deleting the host's account deletes the rest at once, except that a piece already given an upload address can still arrive within the following hour; the weekly sweep deletes it the first time it runs after that. The guest's browser keeps its own copy of each recording, and deletes it only while the page is open and has been told the host collected it — so a copy the link refused, or one whose link records were cleared first, stays until the guest clears the site's data.

Our database has deletion protection, 7-day point-in-time recovery, and daily and weekly scheduled backups. What is deleted from the database stays in those backups until each one expires, and a restore from one would bring back what had been deleted since it was taken. Files in Cloudflare R2 have no backup or versioning: deleting one is immediate and final, apart from the cached copies Section 3.2 describes.

9. How We Build

10. Incidents

If a breach of security safeguards involving your personal information creates a real risk of significant harm, we will notify you and the appropriate authorities — including the Office of the Privacy Commissioner of Canada, and provincial or foreign regulators where applicable — as required by law.

Reporting a vulnerability

To report a vulnerability, email info@t6fv.com. We will acknowledge, keep you updated while we investigate, and we will not pursue legal action for good-faith research that does not access other people's data or degrade the service.

11. What We Do Not Have Yet

We would rather you learn this here than find it in an assessment.

If any of these is a hard requirement for your organisation, tell us at info@t6fv.com — it helps us prioritise, and we would rather say "not yet" early than have you discover it late.

12. Contact

info@t6fv.com — security questions, vulnerability reports, and vendor assessment or questionnaire requests.