T6FV Security Overview

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

Last Updated: September 16, 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.

The short version: most of what you would worry about never reaches us. The production planner is local-first — briefs, scenes, shoot days, contacts, rates, invoices, footage and AI conversations live on the device, and on a plan without a cloud library none of it is uploaded. 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. That copy is readable by us as the operator, and Section 4 says so rather than leaving it implied. Two features cross the internet sealed on the sending device: for one of them we hold no key at all, and for the other — client links — we now hold one, which Section 3.2 states plainly rather than leaving you to find. The remainder — your account, and the community features you opt into — sits on Google Cloud infrastructure under access rules, and we are explicit below about what that means we can technically read. We run no analytics, no advertising, no tracking, and no cloud AI.

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.

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. On a plan that includes one (Section 2), the planning records — and the pictures, documents and recorded audio filed with them — move to Tier 3 for as long as the plan is held; footage, field audio takes and AI conversations stay in Tier 1 on every plan.

2. Tier 1 — What Never Leaves Your Device

The planner is built local-first: it works fully with no account and no server, and on the free and entry paid plans there is no sync service for this data, so there is no server-side copy to breach, subpoena, or mistakenly expose.

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 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, location data or AI conversations, on any plan.

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 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, under names our servers sign a short-lived URL for and nobody else can guess. They are Tier 3 on the same terms as the records, and Section 6 names the store.

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

• Projects and binders ‡: briefs, productions, shoot days, call sheets, schedules, scenes, shots, takes, tasks and deliverables.
• Client and crew contacts ‡, including anything imported from your address book.
• Financial data ‡: rates, quotes, estimates, invoices and payment records.
• The pictures and files a record points at ‡: letterhead and logo, reference images and stills, the images, looks, models and renders in the Maker libraries, the portfolio, documents filed into a binder, and audio recorded in the music tools.
• Camera footage and field audio takes. A four-gigabyte take is what the drive tools are for; no part of the library carries one. (A review cut deliberately hosted on a client link is a separate, user-initiated upload — Section 3.2.)
• Location data. The sun-position and location-scouting tools compute on-device; coordinates are not transmitted.
• AI conversations. The assistant runs on-device (see Section 4), and chats are excluded from every sync and sharing path.

What this means for you: on a plan without a cloud library, if we were compelled to produce your production data, we could not, and if our database were fully compromised none of the above would be in it. We consider this a stronger guarantee than encrypting it would be, because it removes us from the picture entirely. On a plan with a cloud library that guarantee narrows to the unmarked items above — footage, location and AI conversations — and the marked ones carry the Tier 3 guarantees in Section 4 instead.

The honest limits. Local data is protected by your device's own encryption and passcode, not by an additional application-level cipher. On iOS, app data is included in iCloud device backups if you have those enabled. 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

Two features send data across the internet. Both are sealed on the sending device and opened only on the receiving one, and our servers carry ciphertext. They differ in one respect, and this release changed it: for Studio Link we hold no key and cannot acquire one, while for a client link the key now travels in the owner's cloud library so that every device on the account can revoke a page, 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.

3.1 Studio Link

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.

• The two devices agree a session key by ephemeral X25519 key exchange, with HKDF-SHA256 derivation. The pairing code you read off one screen and type into the other is folded into the derivation, so it authenticates the exchange.
• Content is encrypted with AES-256-GCM, with replay protection and a per-sender nonce.
• The key is never transmitted. Not at join, not afterwards. It is agreed independently on both ends and exists nowhere else.
• Successful authentication-tag verification is the authentication, so forgery and tampering are the same failure.
• A new key is agreed per session, so a compromise of one session does not reach earlier ones.

Because the key is never sent, our relay holds base64 ciphertext and nothing that opens it. That is a property of the arithmetic, not of our access policy — it does not depend on us behaving well, and a misconfiguration on our side would leak material nobody can read.

3.2 Client Export Links

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 is the only claim of its kind we have ever had to withdraw. 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, collect what the client has sent to it, and above all revoke it. A link minted on a phone that was later lost used to be unrevokable by its owner; it is the reason the token travels.

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

• On a library we serve (the Firestore-backed plans), our database holds that token beside the encrypted payload it opens. No other account can read it — the access rules put it under the owner's library like every other record — but our systems can, under the same controls as the rest of that library, which is exactly the Tier 3 honesty in Section 4. We can open the client pages of an account whose library we serve.
• On a plan that syncs through the user's own iCloud or Drive folder, the record lands in their folder and not in our database. The token is theirs and their storage provider's; it never reaches us.

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.

One carve-out, stated plainly. Images, video and PDFs attached to an export link are not encrypted. They are stored in a private-by-obscurity bucket under long, unguessable, cryptographically-derived filenames, and those filenames are themselves inside the encrypted payload — so obtaining one requires the link token. But the files are served over plain HTTPS without authentication, and a media URL that leaks by other means stays valid until the file is garbage-collected, including after you revoke the link. If that matters for a particular deliverable, do not attach it to a client link.

Location metadata is stripped from images on export: every image is re-encoded, and EXIF including GPS does not survive.

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:

• Your account record: email address, display name, subscription tier.
• Community content you publish: portfolio and directory entries, forum posts, Blueprint submissions.
• Team membership and activity for shared binders.
• The cloud library, on plans that include it: the planning records marked ‡ in Section 2, in Firestore, encrypted in transit and at rest, served only to the devices on the account and to the people it has invited, to the extent of the access level each was granted. We do not read it, use it, or train on it — but we could read it, which is why it is listed here and not in Section 2.
• The files that library points at: Maker-library images, filed documents, recorded loop audio, and any record too large to be a Firestore document, stored as objects in Cloudflare R2 (Section 6) under names only our servers can sign a download for. Same sentence as above — we do not read them, and we could.
• The client links published from that library, including the tokens that open their pages (Section 3.2). This is the one item on this list that used to be in Tier 2.
• Learn progress, and Blueprint purchase records.

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

No analytics, no tracking, no advertising. The app ships with no analytics SDK, no crash-reporting SDK, no advertising SDK and no tracking identifiers. This is verifiable from the app bundle, and our App Store privacy manifest declares no tracking domains.

No cloud AI. The AI assistant runs entirely on-device using models you download explicitly. There is no LLM API key in the app or on our servers, and no prompt or document is sent to any AI provider programmatically. The optional "external AI" feature opens a provider's own website in a browser view under your own login — a hand-off you drive, not an integration.

5. Accounts and Access Control

• Two-step verification (TOTP) is available on Pro plans and above. It uses a standard authenticator app — Google Authenticator, 1Password, Authy, or the one built into your password manager. Verification is performed by Google's identity service, not by our application: without the code, no session token is issued at all, so the requirement cannot be bypassed by a modified client. We never hold the shared secret. See Section 5.1.
• Email verification is enforced server-side. An unverified account cannot obtain an account record, entitlements, or organisation membership at all. This is checked in the account-creation function and independently in the database rules, not just in the interface.
• Privilege fields cannot be written by a client. Role, admin status, email and subscription state are on a server-side locked list; the functions that grant them derive identity from the authentication token rather than trusting anything submitted.
• Team permissions are enforced on the server, re-read per request from the caller's own membership record. A team administrator cannot grant a capability they do not themselves hold.
• Destructive operations require recent re-authentication, verified server-side against the token's age rather than accepted on the client's word.
• Paid downloads use short-lived signed URLs (15 minutes), issued only after entitlement checks pass. The underlying storage path grants nothing on its own.
• Password policy: a minimum length with a check against commonly-used passwords. Following NIST SP 800-63B, we do not impose composition rules or forced rotation, both of which produce weaker passwords in practice.
• Rate limiting on account emails, per address and per IP, and password reset responses are identical for known and unknown addresses so the endpoint cannot be used to discover whether someone has an account.

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 paid plans. Two-step verification is available on Pro, Agency and Educational accounts. It is not offered on the free or entry paid tiers. We recognise that gating a security control by plan is a fair criticism; it is a commercial decision and we would rather name it than have you find it.

Turning it on is gated by plan; being asked for it is not. Once a factor is enrolled it is demanded on every sign-in, on every platform, permanently — including if the 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:

• users may enrol more than one authenticator (a phone and a tablet, or a desktop password manager), which is the self-service route and the one we recommend at enrolment; and
• an account with no working authenticator left is restored by our support team, after an identity check, at which point all existing sessions for that account are revoked and the account holder is emailed. That email is sent whether or not they were the one who asked.

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:

Server-side credentials are held in Google Secret Manager, not in source code or configuration files. Our repository contains no service-account keys.

7. Data Residency

Our cloud infrastructure is in the United States (Google Cloud region us-central1). We do not currently offer a choice of region. 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 anonymises content that must remain for others' sake — a forum thread keeps its replies but loses its author identity.

Tier 1 data is deleted by deleting the app or the project on your device. We have no copy to delete.

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 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.

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 at once; attached media stays until garbage-collected (Section 3.2).

Our database has deletion protection, scheduled backups and 7-day point-in-time recovery enabled.

9. How We Build

• Security rules are covered by an automated test suite that runs the rules rather than reading them, including negative cases — that a stranger is refused, that an owner is not, that a quota cannot be rewound.
• The two end-to-end encryption implementations are pinned by tests that decrypt fixtures captured under earlier dependency versions, so a library upgrade cannot silently change the format or disable authentication.
• Cryptographic changes are reviewed against the property they are supposed to provide, and where a mechanism is weaker than it looks, it is documented as such in the source rather than described optimistically.

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.

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.

• No SOC 2 or ISO 27001 certification. We have not undergone either audit.
• No independent penetration test. Our security review to date has been internal.
• No SSO or SAML for enterprise identity providers. Email and password is the only sign-in method. Two-step verification is available on top of it (Section 5.1), but there is no way to federate to your own identity provider, and therefore no way to enforce your own access policy or deprovision a leaver centrally.
• Two-step verification is limited to Pro plans and above, and to authenticator apps only — no hardware security keys or passkeys (Section 5.1).
• No choice of data region. United States only (Section 7).
• No customer-managed encryption keys.
• No published uptime SLA or status page.
• Vault exports are not confidential to us. The .t6fv_vault backup and export format uses an encryption key embedded in the application rather than one derived from your password. It obscures the file from casual inspection; it does not keep the contents secret from anyone holding the app, us included. Do not treat a vault file as an encrypted archive. Moving this to a per-user key is planned work.
• Export-link media is not encrypted (Section 3.2).
• A client link's key is in the owner's library, and therefore ours while we serve that library (Section 3.2). Until September 2026 the key to a client page existed only in the URL its owner sent their client, and we could not open one. It now travels with the account so that any of the owner's devices can revoke a page — a capability that was asked for, and is worth more to most people than the property it costs. On a served library that puts the key beside the payload; on a plan that syncs through the user's own iCloud or Drive folder it does not. Holding the token in a form we cannot read, while still letting every device on the account revoke, is real work and we have not done it.

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.