Privacy Policy

1. Who we are and what this covers

Final Frame is a trade name of Highland Park Electric Co, Inc., a California corporation (“we”, “us”). This policy covers the Final Frame macOS application (the “App”) and the service at finalframe.cc (the “Service”), including its marketing pages. It is part of the Terms of Service, and words defined there mean the same here.

Two kinds of data pass through Final Frame, and we treat them differently. Data about you, our customer, we hold as the controller: your account, your billing, your security activity. Data about the people in your credits, and about the collaborators you invite, you hold as the controller and we process on your instructions. Section 5 explains what that means for someone named in a roll.

2. The App, and what it sends

2.1 Nothing, until you ask it to

The App has no analytics, no telemetry, no crash reporter and no usage tracking. It does not phone home about what you build. Your projects, revision history, style templates and renders stay in ~/Library/Application Support/Final Frame and in the folders you choose, on your Mac.

2.2 The connections it does make

• Update check. When it opens and every six hours while it is open, a packaged build asks finalframe.cc whether a newer signed version exists and, if so, downloads it from our file storage. Those requests carry nothing about you or your account. Our hosting providers (Vercel and Supabase, Section 6.1) see their IP address and user agent, as they do for any request, and we do not use them for anything. The App remembers on your Mac which version it last ran, to say once that it was updated, and which update notice you closed.
• FFmpeg download. The first time you render, the App downloads the FFmpeg encoder from ffmpeg.martin-riedl.de, a third-party build server, which sees the IP address of that one request. It happens once; the encoder is then kept on your Mac. If the App finds an FFmpeg you installed yourself, it uses that instead and downloads nothing.
• Logo library. When you add a logo from the library, the App downloads it from Final Frame's own storage. Nothing about you or your production is sent with that request. You confirm your production qualifies first, and the logo is kept in your production like any picture you add.
• Signing in. The App asks you to sign in the first time it opens, and again after you sign out. Your email address, and either your password or the code we mailed you, go to our authentication provider. The session token is kept in the App's local storage on your Mac, and an App already signed in keeps working offline.
• Publishing and syncing. Every project you create, duplicate or open from a file in the App is put online when you do, and the App uploads its whole document, which is your Credit Data. If the App cannot reach the Service at that moment, it puts the project online the next time it can. When you publish a Version, it also uploads a review video. With the document goes the part of the Sources record about the people on the roll: the names and days of the files each of them was found in, the titles and spellings those files used, who added or changed each credit and when, notes such as a deal memo, and up to three clips per person: a small picture of the line in a file that names them, cut to their name and the title beside it. Everyone on the project can see it. The rest of the record of files checked, including the people left out and the corrections made since, stays in the project file on your Mac and is not uploaded. While a cloud-linked project is open, the App asks the Service roughly every 20 seconds whether there are staged edits and whether the project changed on another Mac. A project that is not yet online, one made before this version of the policy or one waiting to be uploaded, never does any of this.
• Notifications. After publishing, the App asks the Service to email the people on the project. It sends only the version id; the Service looks up who to tell.
• Opening a browser. Buttons that say they open finalframe.cc open your default browser. That is a page visit, covered by Section 3.

2.3 What stays on your Mac

Fonts. The App reads every font installed for your user, including fonts synced by Adobe Creative Cloud, so your credits render in the typeface you chose. Font files are loaded into the App and never leave your Mac; only the family name is saved in a project. Spell check reads the macOS word list at /usr/share/dict/words and sends nothing anywhere. The App keeps a cached copy of the answer to “is this account entitled to a clean render”, stamped with the account it belongs to and readable only by your user.

Call sheets, crew lists, spreadsheets and music files. Files you check against a project are read on your Mac, and the files themselves are never uploaded, music cue sheets, music logs, clearance logs and audio files included. For each person added to a project that is online, up to three lines naming them are kept as clips, as Publishing and syncing describes; nothing else of the page goes with them. From an audio file only the song details written into it are read, never its sound. A picture or a scanned PDF is read with the text recognition built into macOS, on your Mac, and the picture itself is never uploaded either. What each file read is cached on your Mac, keyed by a fingerprint of the file, which makes the same file instant the next time. A record of the files checked, the answers you gave, the people added and left out, and the corrections made to those credits since is saved in the project file, and so is the Sources record: for each name, which files mentioned it and under which titles and spellings, and for each credit, who added or changed it and when. To show a file again from Sources, the App looks for it on your Mac by name with Spotlight, or asks you to choose it, and checks its fingerprint before showing it; nothing about the file or the search leaves your Mac. When a file lists a person's email address on that person's row, the App keeps the address in the project file too, to offer it when you ask that person to verify their credit. It never goes online with the project, and reaches us only as the address of an ask you send (Section 5.1).

Contacts. When you ask people to verify their credits and the files gave no address for someone, the App can look that name up in your Mac's Contacts, once you allow it when macOS asks. It reads only the email addresses of the contacts with that name and offers them to you. It keeps nothing, and an address leaves your Mac only as the address of an ask you send. Your address book is never uploaded or copied.

3. What we collect on the Service

3.1 What you give us

• Signing in with Google. If you choose to sign in with Google instead of with an email address and password, Google tells us your Google account identifier, your email address, your name and a link to your profile picture, and we keep them as your account. That is all we ask Google for: we can read nothing else in your Google account, and we never see your Google password. We do not display the picture anywhere, and no page of ours loads it. Google will know that you have an account with us and when you sign in. You can add a password on the account page at any time and stop using Google.
• Account. Your email address, a display name if you set one, and your password, which is stored only as a hash. A prefix of a hash of a new password is checked against the Have I Been Pwned breach corpus so that a known-breached password is refused; the password itself is never sent. If you turn on two-factor authentication, the authenticator secret and hashed recovery codes.
• Guest name. A guest admitted through an invite link, before invites required an email address, gave a name to sign comments with. It is stored on the guest's anonymous account and in the guest's browser. No new guests are admitted.
• Projects and Credit Data. Project names and the whole credit document: names, roles, headings, song and logo credits, text, and logo images embedded in the document. Every published Version keeps an immutable copy of the document, its hash, its per-row timecodes and its compliance findings.
• Collaboration. The email addresses you invite, the role you give each person, whether the invite was accepted, staged edits with their old and new values, who made them, and whether and by whom they were held in the App, comments with their text, timing, frame drawings and byline, replies, and resolutions. We also keep when you sent each invite, for 24 hours, to limit how many invites one account can send in a day.
• Intake memory. When an editor checks call sheets, crew lists, spreadsheets or music files against a project, the files are read in their browser and the files themselves are never uploaded (for the people added, the line naming each is kept as a clip, under Sources below); from an audio file only the song details written into it are read. For that project we keep the names and fingerprints of the files read, the answers given to questions about them, who was added from them and where, the people left out, the corrections made to those credits since, which lets the next check answer the same way, and for everyone the files mention, which files mentioned them and under which titles and spellings. Only the project's editors can see it, and it is deleted with the project.
• Sources. What everyone on a project can see about where a credit came from: for the people on the roll, the names and days of the files they were found in and the titles and spellings those files used; who added a credit from files or changed it, and when; and notes editors add, such as a deal memo or a contract. Editors write it, everyone on the project can read it, commenters included, and it is deleted with the project. The files themselves are not part of it. What is kept of them is at most three clips for each person on the roll: a small picture of the line in a file that names them, cut to their name and the title beside it and never the rest of the page, or for a spreadsheet those two cells as text. Clips are stored with the project and deleted with it. To see a whole file again, you choose it on your own device, where it is read and not uploaded.
• Approvals. Who was asked to sign off, at which address, and what they decided, when, with any note.
• Student applications. Your school, course, year of graduation, what you are making, and the email address the application was made from. Applications are read by a person.
• Product news. Whether you want our product news email, where you told us (the box when you signed up, the account page, or when we asked once), and when. The box starts unticked, and no answer means we do not send it. The answer is kept on its own, where nobody on your projects can see it.
• Contact messages. Your name, address, subject and message, and, to stop abuse, the IP address and browser user agent the message came from.
• Problem reports. What you write, and the details shown to you in the report before you send it: the app or site version, your macOS or browser version, the frame size, frame rate, speed and background of the production you have open (never its credits or names), and the last few error messages the app showed you. The app keeps these error messages in memory only, never writes them to disk and never sends them unless you send a report. Like a contact message, a report also records the IP address and user agent it came from, and is kept and deleted in the same way.
• Billing. Your Stripe customer and subscription identifiers, plan, status and period end, and for a Picture Licence or Season Licence the production or season name you gave, the amount, and a link to the invoice. Card details and billing address go to Stripe and never reach us.

3.2 What we record automatically

• Page views. We count visits with Vercel Web Analytics, so that we know which pages are read. Its script is served from finalframe.cc rather than from another company's domain, it sets no cookie, and it keeps no identifier that would let us or Vercel recognise you on a later visit or on another site. Each view records the page, the page you came from, the country, and the kind of browser and device. It is not tied to your account, it cannot be tied back to you, and the Terms of Service and this Privacy Policy do not run it at all.
• Security activity. Each sign-in is logged with its IP address, user agent and assurance level, and so are changes to your email, password, two-factor and recovery codes, and deletion requests. Only you can read your own log, on the account page. Your active sessions, with the device and address each came from, are listed there too.
• Reference stills. Anyone can view the stills in the Reference library without an account. Nothing is recorded about who looks at them beyond the server logs below.
• View log. When a review player opens a Version it records the viewer's id and label and the time. The project owner sees every view of their production; a viewer sees only their own. It is a record of players that asked to be recorded, not proof that a person watched.
• Per-viewer watermark. If a project owner turns it on, the review player draws each viewer's name and the time over the video while it plays. Nothing extra is stored.
• Mac presence. While you have a cloud-linked project open in the App, a timestamp says your Mac is present, so collaborators know whether a render can happen.
• Server logs. Our hosting and database providers keep request logs, including IP addresses, for a short time for security and operations, under their own policies.

3.3 Cookies and local storage

The Service sets one cookie, ff_gate, while the site is pre-launch: it holds a hash of the shared site password for 30 days so you are not asked again. It is strictly necessary and carries nothing about you. The checkout page, and no other page, loads Stripe.js from Stripe to take the payment: Stripe sets its own cookies there (__stripe_mid and __stripe_sid) and collects device and browsing signals on that page to prevent fraud, under Stripe's privacy policy. They are strictly necessary for paying. There are no advertising or tracking cookies. The site counts page views with Vercel Web Analytics, whose script is served from finalframe.cc itself rather than from anyone else: it sets no cookie, stores no identifier for you, and cannot follow you to another site. What it records is the page, where the visit came from, the country, and the kind of browser and device, which tells us which pages are read and nothing about who read them. It does not run on this page or on the Terms. The sign-in page loads nothing from Google: choosing to sign in with Google sends you to Google's own site and back, and is the only point at which Google is involved. The signed-in app keeps your session token, your guest name, your theme, a column width, a guides toggle, and a new-project intent in your browser's local storage, none of which are sent to anyone. It also keeps there, for each project, the email addresses the files you checked listed beside people's names, to offer them when you ask someone to verify their credit; an address leaves your browser only as the address of an ask you send (Section 5.1). When you check files against a project, what each file read is kept in your browser's IndexedDB, keyed by a fingerprint of the file, which makes the same file instant the next time; it is not sent anywhere, and clearing the site's data in your browser removes it. The signed-in app loads the Barlow typeface from Google Fonts, which sees the IP address and user agent of that request under Google's privacy policy; the marketing page loads nothing external.

3.4 What we do not collect

We do not use analytics or advertising services, we do not build profiles, we do not track you across sites, we do not sell personal data, and we send product news only to people who ask for it (Section 10.5). Every other email we send is about something you or a collaborator did: an invite, a sign-off request, a published version, a reply to your note, an answer to a credit check you asked for, an application update, a deletion you asked for that could not go ahead, or an account security notice.

4. How we use it, and on what basis

To administer the Service, our staff can see an account's email address, name, plan, when it joined and last signed in, which productions it owns by name, and its security activity. From there they can give free access, sign an account out, suspend it for abuse, and schedule it to be closed, with the same 30 days and the same protections for other people's work as closing it yourself. Every such action is recorded with a reason, and the ones done to your account appear in your own security activity. Staff do not open your projects.

We use what we collect to run the App and the Service for you: to sign you in and keep your account secure; to store, sync and display your projects to you and your collaborators; to render, review and record sign-off; to decide whether a render carries the render mark; to take payment and issue invoices; to review student applications; to answer your messages; to send the transactional emails listed above, and product news to people who asked for it; to prevent abuse and enforce the Terms; and to meet legal obligations such as tax records.

Where the GDPR or UK GDPR applies, our legal bases are: performance of our contract with you (the account, the projects, the payments, the emails the Service is designed to send); our legitimate interests in security, abuse prevention, record-keeping and improving the product, balanced against your rights; consent, for product news and wherever else we ask for it; and legal obligation, for tax and accounting records. We do not make automated decisions with legal or similarly significant effects about you. The compliance check produces advisory findings about a document, not decisions about a person.

5. People named in credits, and collaborators

A credit roll is a list of people. When one is online you are giving us personal data about cast, crew, vendors and rights holders, and when you invite someone you are giving us their email address. For that data you are the controller and we are your processor. That means:

• We process it only to provide the Service to you and your collaborators, as this policy and the Terms describe, and on no other instructions.
• We do not use it for our own purposes, do not sell it, and do not share it with anyone except the service providers in Section 6 and the collaborators you choose.
• We keep it as long as your project exists, and delete it with the project or the account, subject to Section 8.
• We help you answer a request from a person in your credits, and we tell you if we receive one directly. If you are named in someone's credits and want to ask about it, the production that made the roll is the right first call, and we will help if you write to us.
• You are responsible for having a lawful basis to give us that data, for the addresses you invite, and for what your collaborators see. A production's crew list is ordinarily processed on the basis of the production's contracts and its legitimate interest in crediting people correctly; a collaborator's address on the basis of their working relationship with you.

5.1 Verifying a credit with the person it names

An editor on a project with a paid plan can ask a person named in the credits to check their own credit, one credit at a time or a whole section or roll at once. On the editor's instruction we email each person, once for each ask, at the address the editor gives. The editor may add a short note, which goes in that email and is not kept. We keep that address, the credit as it was asked about, when it was asked and any reply-by date, the person's answer (that it looks right, the spelling they asked for, or that it is not them), any comment they leave, and when they answered. The person needs no account, and the link shows them only their own credit and the name of the production. The link works for 30 days, and an answer cannot be changed once it is sent. A spelling they ask for is added to the project as a change waiting to be merged, like any other edit, unless the credit has been changed to a different name since they were asked; then it is kept with their answer and shown beside the credit. When they answer, we email the editor who asked, once, with the answer and any comment. The project's editors can see the address and the comment; everyone on the project can see how the credit was answered. If the person says the credit is not theirs, that production does not email that address again. For this data too you are the controller and we are your processor, and a person who was asked can write to the production, or to us, as this section describes.

If you need a signed data-processing agreement for your production or company, write to us and we will provide one on these terms.

6. Who we share it with

6.1 Service providers

We use a small number of providers, each of which processes data only to provide its service to us:

6.2 Your collaborators

People on a project see each other's display names, the address of each named invitee, comment bylines, staged edits and who made them, the Sources record described in Section 3.1, approvals and who gave them, and the view log as Section 3.2 describes. A guest is shown by the name they gave. Nobody outside a project can see it; a share link is the only way in, and an owner can revoke one at any time.

6.3 When the law requires

We disclose personal data when we believe in good faith that the law requires it, to respond to a valid legal process, to protect the rights, property or safety of anyone, or to enforce the Terms. We will tell you before disclosing your data in response to legal process unless the law or the process forbids it.

6.4 If the business changes hands

If we are acquired, merge, or sell the product, personal data may be transferred to the successor under this policy. We will tell you by email and on the site before any different policy applies.

We do not sell personal data, and we do not share it for cross-context behavioural advertising.

7. Where data lives, and international transfers

The Service is hosted in the United States and our providers process data there. If you use it from the European Economic Area, the United Kingdom, Switzerland or another jurisdiction with data-transfer rules, your data is transferred to the United States. We rely on our providers' commitments, including the EU Standard Contractual Clauses and the UK Addendum where applicable, and on the necessity of the transfer to perform our contract with you. Write to us for details of the safeguards in place.

8. How long we keep it

8.1 While your account is open

We keep your account data, your projects, their Versions, review videos, comments, approvals, staged edits, intake memory, sources, credit verifications, security activity and view logs for as long as your account is open and the project exists. A project you delete is kept for 14 days, in which you can keep it, and is then deleted by a nightly job. Deleting a project deletes its document, Versions, staged edits, intake memory, sources, credit verifications, comments, approvals and review videos; the nightly job also removes any video whose project no longer exists.

8.2 Closing your account

You can schedule deletion from the account page. It completes 30 days later, and you can cancel it at any time before that. It is refused, and the page says why, while a project you own has other collaborators or an approved Version, or while a subscription is active, because those are records other people rely on. If, on the day it is due, a project you own has gained collaborators or an approved Version, or a subscription is active, deletion is cancelled instead and we email you what stopped it. On completion we delete your authentication record, profile, projects, Versions, videos, memberships, security activity, two-factor data, student application and Mac presence.

8.3 What survives, and why

• A comment you left on someone else's project keeps its text and the byline you signed it with, with your account id removed.
• An approval you gave on someone else's project keeps the address it was requested at and your decision, because a sign-off record that loses its signer is not a record.
• A view-log entry on someone else's project keeps the label it was written with.
• A staged edit you made on someone else's project keeps its values, with your id removed.
• Picture Licence and Season Licence receipts, invoices, subscription and payment records are kept for as long as tax and accounting law requires, typically seven years, by us and by Stripe.
• Contact messages are kept while we may need to refer back to them, and are deleted on request.
• Backups taken by our database provider expire on their own schedule, within a short period after deletion.

8.4 The App

Nothing on your Mac is deleted by closing an account. When a project is deleted, in the App, on the site or with its owner's account, the App removes its copy and that copy's revision history from each Mac signed in to an account that holds one, the next time it looks. To know, it sends the Service the ids of the projects it holds copies of and is told which no longer exist. Leaving a project in the App removes the copy on that Mac. Renders you exported are never touched. Signing out of the App purges the cached entitlement answer. Uninstall the App and delete ~/Library/Application Support/Final Frame to remove everything it kept.

9. Security

Every request to the database is checked against row-level access rules that run inside the database itself; there is no server of ours in between that could be misconfigured. Passwords are hashed and checked against breaches, sessions time out, two-factor authentication is available with recovery codes, and destructive actions ask you to re-prove yourself. Review videos live in a private bucket and are served through short-lived signed links. Data is encrypted in transit and at rest by our providers. The App keeps its cached entitlement and its upload credentials in files readable only by your user, and update packages are verified against a signing key before they install.

No system is perfectly secure, and we do not promise that ours is. If we learn of a breach affecting your personal data we will tell you and any regulator the law requires, without undue delay. Report a security concern to the address in Section 13.

10. Your rights and choices

10.1 Built into the account page

• Access and portability. Download one JSON file with your profile, every project you own, every Version and its document, every comment, staged edit and approval, and your recent security activity.
• Correction. Change your display name and your email address there; a changed address updates every byline.
• Deletion. Schedule deletion of your account, as Section 8 describes.
• Sessions. See where you are signed in and sign out everywhere.
• Cancel billing. Cancel a subscription from the billing portal.

10.2 Other rights

Depending on where you live you may also have the right to object to or restrict processing, to withdraw consent, to know what we hold and to whom we have disclosed it, and to complain to a supervisory authority. To exercise any of these, write to us at the address in Section 13. We answer within 30 days, or sooner where the law requires, and we may ask you to confirm you control the account. We do not discriminate against anyone for exercising a right.

10.3 California

If you are a California resident, the California Consumer Privacy Act gives you the right to know the categories and specific pieces of personal information we collect, the sources, the purposes, and the categories of third parties we disclose it to, all of which this policy sets out; to delete it; to correct it; and to not be discriminated against. In the past twelve months we have collected the categories in Section 3, identifiers, commercial information, internet activity in the form of sign-in and view logs, and the content you provide, and disclosed them to the service providers in Section 6 for business purposes only. We do not sell or share personal information as those terms are defined in the CCPA, and we do not knowingly collect personal information of consumers under 16. You may use an authorised agent to make a request; we will ask the agent for proof of authority and may ask you to confirm it.

10.4 Europe and the United Kingdom

If you are in the EEA, the UK or Switzerland, you may lodge a complaint with your local data protection authority. We would rather hear from you first. We have not appointed a representative in the EU or the UK; write to us directly.

10.5 Choices

Using the App needs an account, and every project you make in it is put online. You can decline two-factor authentication, though we recommend it. You can leave a project you were invited to. Product news is sent only if you ask for it: a box, unticked, when you sign up, a switch on the account page you can change at any time, and an unsubscribe link in every issue. Transactional email cannot be turned off while your account is open, because it is how the Service tells you what happened.

11. Children

Final Frame is a professional tool. It is not directed to children, we do not knowingly collect personal data from anyone under 16, and an account holder must be at least 18. If you believe a child has given us personal data, write to us and we will delete it.

12. Changes to this policy

We may change this policy. For a material change we will give at least 30 days' notice by email to the address on your account, and the App and the Service will ask you to accept the new version. The version and date at the top of https://www.finalframe.cc/privacy always show the current revision.

13. Contact

Privacy questions and requests: hello@finalframe.cc, or https://www.finalframe.cc/contact. Highland Park Electric Co, Inc., a California corporation, doing business as Final Frame.