Privacy policy | EveryFrame

Australia

EveryFrame Digital Pty Ltd (ACN 701 617 674, ABN 75 701 617 674) makes EveryFrame. In this policy "we" and "us" mean EveryFrame Digital Pty Ltd, of Melbourne, Victoria, Australia.

This policy covers our website and account pages (everyframe.com.au), our licence server (api.everyframe.digital, which the application itself contacts), and the EveryFrame desktop application. It is written for schools in Australia. Schools in New Zealand and the United Kingdom have their own versions.

Effective date: 2 October 2026. Version: 6. Contact: privacy@everyframe.digital

The short version

EveryFrame runs on computers inside your school. Your school's footage, photos, consent records, student information and the face templates the application creates stay with your school, on those computers and in any shared folder your school chooses. They are not sent to us, we do not hold them, and we could not produce them if asked.

The personal information we do hold is what it takes to run a website and a subscription: what you type into our forms, the school name and billing email for a subscription, the school email address of each staff member who activates a computer, an identifier for each activated computer, any email you send us, and any pilot log your school chooses to email us. The application shows its complete list of network connections on a settings page generated from the code itself, so your school can check this for itself.

Our status under the Privacy Act

We are a small business, and the Privacy Act 1988 (Cth) does not apply to us by law. We handle the information described in this policy to the standard of the Australian Privacy Principles, and our agreement with your school binds us to do so. Because the Act does not apply to us, the Office of the Australian Information Commissioner may be unable to investigate a complaint about us. If our status changes, this section will say so.

Two different roles

Privacy law treats two things separately here, and so do we.

Information we collect. Website enquiries, subscriptions, staff activations, licence checks, pilot logs and correspondence. We are responsible for this information, and the first half of this policy is about it.

Information your school processes inside EveryFrame. Student images, face templates, consent records and the records staff create while using the application. Your school collects and holds this, on its own computers, under its own privacy obligations. We supply the tool and design it so that this stays true. The second half of this policy describes what the application does with it, so your school can describe it accurately to families.

What we collect, and why

When you visit everyframe.com.au

We run no analytics and no advertising trackers. The public pages of the website set no cookie. Signing in to your school's account sets one, which is described below. Our host, Netlify, records standard server logs, including IP addresses and browser details, to serve and protect the site. Netlify keeps these logs for 14 days.

Some pages load resources from other providers, which then receive your IP address and ordinary request details.

Typefaces come from Google Fonts on the home, log in, subscribe, privacy, terms and error pages.

The overview video on the home page comes from YouTube's privacy enhanced player. It loads only when you press play.

The account pages load nothing from another provider.

When you register interest

The full form asks for your name, work email, school and role. A shorter form asks only for your name, school and work email. We use these details to send you information about EveryFrame, to answer your questions and to talk with you about trying it at your school. Submissions are stored in Netlify's form service and passed on to us by email.

You can ask us to stop contacting you at any time by replying to any email from us or by writing to privacy@everyframe.digital.

When your school subscribes

The Subscribe page collects your school's name, a billing email address, your enrolment and the contract length you choose. It also asks four optional questions: where you post most of your content, where you keep your consent information, how many computers will use EveryFrame, and whether your consent record asks who gave consent and the date given. You can skip them. The optional answers help us build a picture of how schools use their content. They are not used to set up or run the software, and they are not shared. All of this passes through our website host, Netlify, to our licence server, and from there to Stripe. Payment happens on Stripe's own secure page: we never see or store a card number. Stripe tells us the outcome, and we keep your school name, billing email, enrolment, contract length, any answers to the optional questions, licence key, subscription status and dates, the identifiers Stripe gives the subscription and its invoices, the dates we sent renewal reminders, any limit set on the number of computers, and the time your school accepted our terms at checkout. We use them to set up and bill the subscription, to email the licence key and renewal reminders, and to keep the records the law requires of a business.

If your school changes its billing contact, we send the new address to Stripe and email the licence key to the new contact.

When you sign in to your school's account

The account pages are part of everyframe.com.au. Our website host, Netlify, passes each request for them to our licence server and passes the answer back. Netlify therefore carries, in transit, what those pages send and show: the billing email you type, the sign in link, the sign in cookie, and the pages themselves.

The account shows your school's licence and plan, the computers activated under it, any staff address your school has removed, billing, up to six paid invoices, and the installer download. The invoices are read from Stripe when the page opens. We do not store them.

There is no password. You give the billing email address, we email a link to it, and opening the link and pressing Sign in signs you in. We send at most three links to one address in fifteen minutes, and six in a day.

We keep the link and the session only as one way hashes, so our own records cannot be used to sign in as you. A link works once and expires after fifteen minutes. A session ends fourteen days after you sign in, or when you sign out.

Signing in sets one cookie. It is strictly necessary to keep you signed in, holds only a random session reference, cannot be read by scripts on the page, and is not used for analytics, advertising or tracking across sites.

The sign in form uses Cloudflare Turnstile to check that a person, not a bot, is asking for a link. For that check Cloudflare receives your IP address and information about your browser and device, and our server passes Cloudflare the network address it saw for the request when it confirms the result. We receive only whether the check passed.

When a signed in school downloads the installer, we record which licence and which signed in email address downloaded it, and when, so we know which version a school is running when it asks for help. The download comes from Cloudflare's file storage through a link made for that request, which works for one hour.

When staff activate EveryFrame on a computer

Each computer is activated with your school's licence key and a staff member's own email address at your school's email domain. We email a six digit code to that address to confirm it belongs to the person activating. We keep:

the staff email address, linked to the computer it activated, and the email domains your school uses, so the account can show the school which computers are licensed and to whom;

an identifier for the computer, made by scrambling (hashing) its Windows installation identifier together with, where it has one, its firmware identifier. It contains no serial number, user name or school data, it cannot practicably be turned back into either identifier, and we use it only to stop one licence being copied onto more computers than the plan allows;

the code, stored only as a hash and usable for one hour, with the staff address and computer identifier it was asked for. We keep that record for about a day, even if the activation is never finished.

If a staff member's address is removed from a computer, or blocked by your school's account, we keep a record of that so it takes effect.

A person who holds your school's licence key can look up the school's name, whether the licence is current, and the billing address partly hidden. Keep the key within the school.

When the application checks its licence

Each time EveryFrame opens, it asks our licence server, in the background, to renew its licence. The request carries the licence identifier, the staff email address the computer was activated with, the computer identifier described above, and the signed licence file already on the computer, which names the school, that staff address and the billing address partly hidden. It carries no footage, images or student information.

If our server cannot be reached, the computer keeps working on the licence it already holds. For a plan billed monthly that licence runs for up to seven days after the last successful check, followed by a 14 day grace period. After that the application becomes read only until it can check again. Staff can still view and export consent records while it is read only, so your school is never locked out of its own records.

Like any internet request, each connection shows us an IP address. Our licence server holds IP addresses in memory for up to an hour to limit repeated requests, and does not write them to disk. Our server's own event messages show email addresses partly hidden and only the last four characters of a licence key. There is one exception: if reading a school's invoices from Stripe fails, the message records Stripe's error text, which can include Stripe's identifier for the customer. Our host, Fly.io, keeps these messages and its own connection logs for 14 days.

When you email us or ask for help

We keep the correspondence. If you ask for support, we may ask for a screenshot, or for a report on the computer. A fuller diagnostic report exists as a separate tool that we run together with your school. The installed application cannot produce it. Any report is made on your computer, can be read before it is sent, and is designed to name no student. We will not ask for footage or student information, and if any reaches us by mistake we delete it and do not use it.

The pilot build and the pilot log

Schools in the Term 4 2026 pilot receive a build named EveryFrame_PILOTBETA. It is not the finished product.

The pilot build works for five weeks, counted from the first time it is opened on a computer. Reinstalling it does not start the five weeks again, and moving the computer's clock back ends the pilot. In the final week the application says so.

When the five weeks finish, the pilot build refuses to export video in any form: a whole video, a single shot, a still frame or a clip. It does not refuse to save a photo or to analyse footage, so the pilot terms ask your school to stop using it for those as well. Your school's own records stay open: staff can still read and save the consent register and the paper trail.

The pilot log. At the end of the pilot the application offers to save a plain text log, and asks that a staff member email it to hello@everyframe.digital. The same log can be saved at any time from the Settings page. The application never sends it. A person at your school saves the file, can read all of it first, and chooses to email it.

The log holds:

the build, the date the pilot started and the date it ends;

facts about the computer: the operating system, the number of processor cores and the graphics options available;

counts of the work done: footage processed, files cleared, faces covered, unrecognised faces identified, sign off documents produced, and videos in the library;

counts of anything that failed, and the number of jobs in the queue;

the result of each readiness check, as its title and whether it passed;

the text of any crash report.

A crash report is the one part of the log made of free text. Before it goes into the log, the application removes each name of three or more characters on your school's register, and anything shaped like a file or folder path. The log contains no consent answer, no picture, no face and no part of the paper trail. A crash report could still carry a word the application does not know to remove, such as the name of a person who is not on your register. That is why the log is plain text, which your school can read in full before sending it.

We use a pilot log to find and fix faults before the full release, and for nothing else. We keep it for 12 months after the pilot ends and then delete it.

When the law requires it

We may disclose information we hold where Australian law requires or authorises it, for example to a regulator, to law enforcement, or in a tax audit of the billing records we must keep.

What we never collect

We never ask for or require student names, photos, videos, face templates or consent records, and the application never sends them to us. The application sends no telemetry, no usage analytics and no crash reports. We do not sell or rent the details we hold, and we do not use them for anyone else's marketing.

One thing reaches us only because a person sends it: the pilot log described above, which a staff member at a pilot school saves, can read, and chooses to email.

Automated decisions

From 10 December 2026 the Privacy Act requires a privacy policy to describe certain decisions that a computer program makes, or substantially helps to make, using personal information. We describe ours now, in two parts: what our own systems decide, and what the application works out for your school.

What our own systems decide

Our licence server decides some things by itself, using the details described above:

whether a licence is current, and until when;

whether an activation code is correct;

whether a staff address may activate a computer: it must be at one of your school's email domains and not blocked;

whether a licence has reached its limit of computers;

whether a licence file presented by a computer is an out of date copy;

whether a sign in request passes the bot check;

whether one address has made too many requests.

These decisions concern your school's licence. Anyone affected can ask a person at EveryFrame Digital to review one by writing to privacy@everyframe.digital.

What the application works out for your school

Staff use EveryFrame to decide what may be published. The application works some things out by itself, and a person makes every decision to publish. These are your school's decisions, made with a tool we supply. We describe them here so your school can describe them accurately to families.

The consent verdict. From your school's consent register, the application judges whether each recognised student is cleared for the stated use. A refusal outranks a missing answer, and a missing answer outranks a yes. A yes past its review date is treated as a missing answer.

Covering a face in a video. When staff review a video, no face is covered until a person chooses. One button covers everyone who is not cleared for the stated use.

Covering a face in a photo. When staff open a photo, or a folder of photos, every face that is not cleared starts marked to be covered. Staff can change any of them before anything is saved.

The submissions folders. If your school uses them, the application returns a copy of each submitted video with everyone who is not cleared covered. No person chooses each face. Anything that needs a person comes back untouched, in a separate folder, with a note saying why.

The check when a file leaves. When staff export a video or save a photo, the application asks the current register again. If a person left visible is no longer cleared, the application covers that person, tells the operator who and why, and records it.

The unidentified face rule. The application will not export a whole video while a face it could not identify is unresolved. No setting switches that off.

Deleting unidentified faces. The application deletes the pictures and measurements of unidentified faces when your school's retention window passes.

In every case a person at your school decides whether a file is published. Staff can see each judgement, and the reason for it, before a file leaves.

Whether any of these is a decision your school must describe in its own privacy policy is a question for your school and its advisers.

Artificial intelligence and machine learning

EveryFrame uses machine learning models to find faces, recognise students, label scenes, transcribe speech and replace a face. This is what each one does, and what it cannot do.

Model	What it does in EveryFrame
Face detection and face recognition (InsightFace buffalo_l)	Finds each face in a frame, and turns it into a set of numbers that can be compared with an enrolled student's
Scene labelling (CLIP)	Labels what a shot shows, so staff can search footage by description
Speech transcription (Whisper)	Writes down what was said, and when
Voice separation	Separates speech from background music, so a clip can be saved without the music
Face replacement (InSwapper)	Puts an AI character's face in place of a real one, when a person chooses it

Where they run. Every model runs on your school's computer. All of them come inside the installer, and the installed application never downloads or updates one. Analysing footage needs no internet connection.

What they learn from your school. Nothing. No model is trained, tuned or changed by your school's footage, photos or register, and nothing from your school is used to train a model anywhere else. What your school teaches the application, which is keywords, corrections to a label and search words that mean the same thing, is stored sealed on your school's computer. It is used only for that school's own labels and search, and it goes nowhere.

What the application does not work out. It does not estimate the age, gender, emotion, ethnicity or health of anyone in footage or photos. The AI characters carry labels for age band, gender, skin tone and hair colour so that staff can choose one. Those labels describe generated characters, not people.

What the models get wrong.

Face recognition makes mistakes. Published research finds that it makes more of them on children than on adults, and that a child becomes harder to recognise as the gap grows between the enrolment photo and the footage. It is also less reliable when a face is turned, small, blurred, shadowed or partly hidden.

The detector can miss a face altogether. A face it never found is never checked.

Transcription can write words that were not spoken, and is less reliable for some accents and in noisy recordings.

Scene labels are approximate, and the model behind them has known biases.

We publish no accuracy figure, because we have not measured one on footage like your school's.

What follows from that. Every match is a suggestion for a person to check. A person at your school looks at footage and photos before they are published, including for a face the application did not find. Staff can correct any name or label. Before relying on face recognition, your school should try it on its own students, by year level, and enrol a newer photo as a student grows.

In designing and describing these features we have had regard to two guides published by the Australian Government: the Guidance for AI Adoption (21 October 2025) and the Voluntary AI Safety Standard (5 September 2024). Both are voluntary. Neither is a certification, and we claim none.

Student information inside the application

This part describes what the application does on your school's computers. None of it reaches us. Your school collects and holds this information, and answers for it under its own privacy obligations.

Two points of Australian law shape what your school tells families.

A face template is sensitive information under the Privacy Act, whatever it is used for.

Measuring a face counts as collecting it, even when the measurement is held only for a moment. The Administrative Review Tribunal decided this in Bunnings Group Limited and Privacy Commissioner [2026] ARTA 130. EveryFrame measures every face in the footage it analyses, including students who have not consented to face recognition and people who are not students, because it cannot cover a face it has not found. Your school's collection notice should say so.

Where it lives, and how it is protected

Everything the application stores sits in a data folder in the Windows user's profile, on the school computer running it. This version cannot link computers, so there is no shared copy.

Almost every stored file that holds student information is sealed, which means encrypted with AES 256 GCM, under one key the application creates for that computer and protects with Windows. Sealing protects the files if they leave the computer. It does not protect against a person using the computer while signed in to it: any Windows account on that computer that can read the key file can open every sealed file. Your school's own accounts, passwords and screen locks are the real protection, together with disk encryption.

Seven files are not sealed.

Four can carry a student's name, because they hold the names of files and folders, and a school often names a file after a child. They are the job queue, the record of submissions taken in, the register import settings, and the list of footage locations.

Two hold counts only: the usage counters and the quality log.

The crash log holds program traces. A file path in it is cut down to the file type before it is written.

The key cannot be copied out in this version. The application can show and accept a key, but the only screen that offers it is the linking screen, which this version keeps shut. So a school cannot keep a copy of its key, and the sealed files cannot be opened on another computer, or on the same computer after Windows is reinstalled. The application keeps no backup of its own. Until this changes, a copy of the data folder is not a usable backup. Your school should keep its own consent records as the master copy, and treat the register in EveryFrame as a working copy of them.

What it holds

The consent register: each student's name; their answer for each of six uses, from internal use to advertising; a separate answer for face recognition; any review date; where each answer came from (typed in, a file import or a student information system), who gave it (parent, carer or student, or not recorded) and when; the student's ID and year level, where your school's file or system provides them; any AI character your school prefers for that student; and the names of students your school has removed, kept so that a later import cannot bring them back by accident.

Face templates: numeric representations of a student's face, made from reference photos, used to recognise them. They are biometric information.

Portrait photos: a small photo of each student who has a yes to face recognition, shown on the register.

What it works out from footage and photos: where faces appear and the measurements taken to follow and compare them, who they were matched to, the cuts between shots, labels for what a shot shows, transcripts of speech, thumbnails, and for a face it could not identify, a small picture of the face and the frame it came from.

Cover decisions: which faces staff chose to cover in a video or a photo, and how.

What your school teaches it: keywords, corrections to labels, and search words that mean the same thing.

Register import history: each time a register file is imported, a sealed copy of the register as it stood before the import, and a report of the import that names students. The application does not delete these, and a withdrawal or a removal does not reach into them.

Records of decisions: the publication register, sign off documents, the governance pack, and a paper trail of every action. Each entry in the paper trail records the computer's name.

Records about staff: the name each operator gives, the Windows account they were signed in with, each operator's attestation and when it was given, and, if the review page is used, its accounts, the network address of each device that signs in, and a log of who viewed what.

Connection details, if your school connects a student information system: the credentials your school issued, and the names of any students whose change a scheduled check held back for a person to approve.

A computer upgraded from an earlier version of EveryFrame may also hold two backup files made during the upgrade, one of which contains face templates. The application does not delete them. A computer that starts with this version holds neither.

Face recognition happens only with consent

The register holds consent to face recognition separately from consent to appear in media. The application creates a face template, and keeps a portrait, only for a student whose register records a yes to face recognition. A student recorded as no, or with no answer, is never enrolled and never matched, and no screen in the application relaxes this. When a person confirms who a face is, the application learns from it only for a student who has said yes.

To find faces and cover them, the application must detect and measure every face in a frame, including students who have not consented to face recognition and people who are not students. When a face matches no one, the application keeps its measurement, and for video a small picture of the face and the frame it came from, so that a staff member can review it. The application does not put a name on a student who has not said yes. A staff member may do so while reviewing, and that creates no face template.

Faces the application could not identify

A face that matches nobody blocks the export of a whole video until a person resolves it. No setting switches that off. A person resolves a face by matching it to a student on the register, or by recording it as a visitor, a sibling, a staff member, a former student, or a face that needs no identification. Each of those records who decided and when. None of them clears the face for publication.

Three limits apply.

Exporting a single shot, a still frame or a clip is not blocked.

Once the record of a face has been deleted at the retention window, it no longer blocks, so footage should be reviewed within the window.

A video that has never been analysed has had no face checked. The application warns the operator, and lets the video be exported if they choose to go on.

Consent is checked again when a file leaves

A plan made earlier is not trusted. When staff export a video or save a photo, the application asks the current register again, for the stated use, so a withdrawal or a change made after the covers were chosen is honoured. For video it also applies any rule your school has set for that event. An event rule can only tighten what the register allows. In this version an event rule does not reach photographs, so staff apply it to photos by hand.

If an export would leave anyone who is not cleared visible, the application says so first. If staff go ahead, the application records that choice, with the operator's name, before the file is written, and stops if it cannot record it.

Saving a still frame is the exception. The application records that the still was saved, and whether covers were applied, and stops if it cannot record it. It gives no warning of who is visible in the still.

Replacing a face with an AI character

Instead of blurring a student who is not cleared, staff may choose to replace that face with an AI character. The application never does this by itself: a person chooses it for each face, in each file.

The characters. The characters that come with the application were made by an AI image generator that was asked to create fictional children. No photo of a real person was given to the generator. We have not compared the characters with real people, and no generator can promise that a face it makes resembles nobody. A school can also add a character of its own. The application does not check an image a school adds, so a school must never add a picture of a real person.

The label. The application can burn the words AI-REPLACED FACE into a saved file that contains a replaced face. The label is on by default, for video and for photos. An operator can turn it off for a single export. The setting is not remembered for the next export, and the application records which way it was set. A whole folder of photos saved in one go always carries the label. The publication register records which files carry a replaced face, and whether they were labelled.

What the result is. A file with a replaced face is an altered image of a real scene. It is never described as anonymised, because a student's voice, clothing and surroundings can still identify them.

When a replacement cannot be made. If a face is turned too far, is partly covered, or the character is not on this computer, the application blurs that face instead and tells the operator why.

A character for a student. Your school may record on the register a character it prefers for a student. It is offered first when that student's face is chosen, it is never applied by itself, and it can be removed at any time.

Whether your school's collection notice should mention the AI character feature, and a character recorded against a student, is a question for your school and its advisers.

Speech in footage

To help staff find clips, the application transcribes speech on the school's computer, and can separate voices from background music. A transcript is stored sealed with its video's record. It can name a person who was spoken about and never seen. The retention window below does not cover it: a transcript is deleted when its video is removed from the application and the trash is emptied. No audio or text leaves the computer.

How long the application keeps faces it could not identify

The application deletes the picture, the frame and the measurements of a face that matched no student once they are older than your school's retention window. The window is 30 days unless your school changes it, and your school can set it anywhere from 7 to 90 days. The lower limit of 7 days is there so that staff have time to identify a face before the record of it is destroyed. The application checks when it starts and once a day while it is open, and staff can run the check at any time.

The deletion reaches analysed videos, checked photo folders, faces a person has set aside, and saved cover decisions. A measurement that now matches a student on the register who has not refused face recognition is kept, because that face is no longer unidentified. A deletion that fails is tried again, and is never recorded as done. Every change to the window and every deletion is written to your school's paper trail, with how many were deleted and how many are still held.

When consent is withdrawn or a student is removed

Recording a no to face recognition destroys that student's template and portrait at once, and removes their face measurements from analysed videos, checked photo folders and saved cover decisions. The faces the application had recognised as that student lose the name and stay covered. Removing a student does the same, deletes their register entry, and keeps their name marked as removed so that a later import cannot bring them back by accident.

Recording a refusal also empties the list of where that student appears, because the list is built from their name on each face. Staff should note where a student appears before recording a refusal or removing them.

Four things are not reached.

The student's name stays in the records of decisions staff made, such as a saved cover decision or a publication record, because those records are the history of what was decided.

The register import history keeps earlier copies of the register.

A transcript that names the student stays until its video is removed.

Files your school has already exported or published are outside the application.

Deletion here means removal from the application's own files. The application does not yet destroy a separate key for each student. Whether anything could be recovered from the disk afterwards depends on the computer's disk encryption, which is your school's.

The record of what was done

Every action is written to a paper trail on the school's computer, under the operator's name, with the Windows account for actions taken at the computer and the review page account for actions taken there. The operator's name is the name that person typed: the application has no sign in of its own. Each entry is chained to the one before it, so an entry altered or removed from within the trail can be detected. The trail is tamper evident. It cannot prove that nothing was removed from the very end of it. Each sign off records the exact version of the consent register it relied on.

Four documents name students: the sign off, the governance pack, the publication register, and the copy of the paper trail that travels with an exported file. Each is saved as a PDF file that is encrypted and refuses editing and copying. A list saved as a spreadsheet file carries no such protection.

Each operator is asked to attest, in their own name, that they are authorised staff, have completed the school's child safety training, will not keep school material on a personal device, and understand the rule on unidentified faces. The application asks again every 24 months.

Features your school can turn on

Four features are off until your school turns them on. None of them involves us.

The review page. EveryFrame can serve a page on your school's own network, so colleagues can see the queue, consent verdicts and unidentified faces from their own computers. It refuses any connection from outside the local network before reading it, always uses an encrypted connection, and requires an account your school creates on the main computer. It separates viewing from identifying faces and from signing decisions, locks out a device after repeated wrong passwords, and logs every view. Its certificate is made on the computer, so a browser shows a warning the first time. Nothing can be processed, exported or downloaded through it.

Submissions folders. Staff can drop footage into a shared folder. The application processes it and places a copy with everyone who is not cleared covered in a Cleared folder, with a consent report beside it, and anything that needs a person in a Needs review folder. The consent report is an ordinary, unsealed file that names the students in the footage, so the folder should be one that only authorised staff can open.

A register watch folder. The application can watch a folder your school chooses, and import a new register file when one arrives.

A student information system connection. EveryFrame can read names, consent answers, student IDs and year levels directly from your school's system, for example Synergetic, Compass, iSAMS, aXcelerate, OneRoster or Wonde, using credentials your school issues, stored sealed on the computer. It only reads, never writes, and a scheduled check can withdraw a consent but never grant one.

Linking several computers is not available in this version, and no setting turns it on.

What else to know

Files your school exports, such as videos, photos, sign off documents, the governance pack, the publication register and consent lists, are your school's copies, handled like any other school document.

A settings page titled "What talks to the internet" lists every connection the application can make and every connection it can accept. The list is generated from the code, not written by hand. The application records on its paper trail any connection it detects that is not on that list. That check cannot see every kind of connection, and the page says which kinds it cannot see.

The installer is not code signed yet, so Windows shows a warning when it runs. Your school can check the file against the fingerprint published beside the download. The application installs for one Windows user, without administrator rights. It has not had an independent penetration test.

We cannot see, change or delete anything on your school's computers. The only thing we control is whether a licence is renewed. If a subscription ends, if we end a licence under our terms, or if your school removes a computer from its account, that computer learns this at its next licence check, and becomes read only once its current licence and grace period have run out.

While the application is read only, staff cannot analyse footage or export video, photos or captions. They can still open and export the consent register, the paper trail, sign off documents, the governance pack and the publication register. Your school's data stays on its computers.

The Australian privacy regulator's guidance on facial recognition, updated on 29 July 2026, expects the measurements of a face that matches nobody to be deleted immediately. That guidance is written for shops, and does not address schools. EveryFrame keeps those measurements for your school's retention window, for the reason given above. Your school should record why it needs the window it has chosen.

Questions about a student

Because we hold no student information, a question or request about a student's information in EveryFrame should go to the school. Your school remains responsible for its own collection notices, consent processes and privacy policy. We supply draft wording on request.

Government schools

A government school is bound by the privacy law of its own state or territory.

Victoria. Privacy and Data Protection Act 2014 and its Information Privacy Principles. Office of the Victorian Information Commissioner.

New South Wales. Privacy and Personal Information Protection Act 1998. Information and Privacy Commission.

Queensland. Information Privacy Act 2009 and the Queensland Privacy Principles. Office of the Information Commissioner.

Western Australia. Privacy and Responsible Information Sharing Act 2024. Information Commissioner.

Tasmania. Personal Information Protection Act 2004. Ombudsman Tasmania.

Australian Capital Territory. Information Privacy Act 2014 and the Territory Privacy Principles. The Territory's Privacy Commissioner.

Northern Territory. Information Act 2002. Information Commissioner.

South Australia. The Information Privacy Principles Instruction, a Cabinet circular. Privacy Committee of South Australia.

What we agree to. For the details a government school gives us, which are licence, billing and staff account details, our agreement binds us to that state's or territory's privacy principles in the same way and to the same extent as the school.

Before a government school uses EveryFrame. An education department may have its own policy on facial recognition, and on tools that use artificial intelligence to alter images of students. In Victoria the Department sets steps a school takes before it obtains any biometric technology, starting with its Privacy team. Whether your department's policy permits EveryFrame, or its AI character feature, is a question for your department. No department, regulator or scheme has assessed, approved or endorsed EveryFrame, and we claim no such thing.

Records. In some states the records a government school creates are public records, which may be destroyed only with approval. EveryFrame deletes unidentified face data when the retention window your school has set passes. Ask your records authority how that window sits with your school's obligations.

Providers we use

These are the providers involved, what each does for us, what it receives, and where it works. We do not give any of them the details we hold for its own purposes.

Provider	What it does for us	What it receives	Where
Stripe (Stripe Payments Australia Pty Ltd)	Payments, invoices and the billing page	School name, billing email, and the card details you enter on Stripe's own pages	Australia, the United States and other countries
Fly.io (Fly.io, Inc.)	Hosts our licence server and its database	Everything described above under subscriptions, sign in, activation and licence checks, and its own connection logs	Sydney, Australia. The company is in the United States
Postmark (AC PM, LLC, an ActiveCampaign company)	Sends sign in links, activation codes, licence keys, renewal reminders and notices about a plan	The recipient's address and the message	The United States. Postmark states that its parent group also works from other countries
Cloudflare	The bot check on the sign in form, and the file storage that delivers the installer	Your IP address and browser and device information for the check, and your IP address and ordinary request details for the download	The United States and other countries
Netlify	Hosts the website, stores register interest submissions, and passes account requests to our licence server	Form submissions, its own server logs, and in transit everything the account pages send and show	The United States and other countries
Google	Typefaces on the public pages, and the overview video on the home page	Your IP address and ordinary request details	The United States and other countries

Postmark states that it keeps the content of a message for 45 days, and its records of bounced and blocked addresses indefinitely.

Information handled outside Australia

Some of the providers above handle information outside Australia. The table above says where. The information involved is limited to what that table describes, and never includes student information.

No country has been prescribed under the Privacy Act as giving substantially similar protection, and we do not describe any of these destinations as approved. We rely on our contract with each provider, and we remain responsible for how each one handles the information we give it.

How we protect what we hold

Connections to our website and licence server are encrypted, and so is the email we send on its way to our mail provider. Sign in links, sessions and activation codes are stored only as hashes. Our licence database is readable only by the server itself and holds no student information, so a breach of it could not expose a student record. Licences are signed with a private key that exists only on our server. Access to our provider accounts is limited to the people who run EveryFrame, and the actions our own staff can take on a school's account need a sign in from the last 30 minutes. No system is completely secure, and we do not claim otherwise.

Inside the application, security depends on both of us: we build the protections described in this document, and the school secures the computers, accounts and networks they run on. Our Security Overview for Schools sets out that split and is available on request.

If something goes wrong. If a breach of the information we hold is likely to result in serious harm, we will assess it within 30 days, and tell the people affected and the Office of the Australian Information Commissioner as soon as practicable. If the breach involves details a school gave us, we will tell that school as soon as we know.

How long we keep things

Our licence server clears records that have passed their period each time it starts, so a record can remain for a short time after its period ends, until the next start.

What	How long we keep it
Register interest submissions and related email	Two years after our last contact with you, then deleted by hand
Billing and licence records: school name, billing email, licence key, subscription dates and status, Stripe identifiers, terms acceptance, download records	Up to seven years after the last transaction, as the law requires of a business. Nothing deletes these automatically yet: we remove them by hand
Staff activation records: staff email and computer identifier	Until removed by your school, or 90 days after that computer last checked its licence
Blocked staff addresses	One year
Activation codes	Usable for one hour. The record is deleted when our server next clears records after a day
Sign in links	Usable once, within fifteen minutes. The record is deleted when our server next clears records after a day
Sign in sessions	Fourteen days from sign in, or until you sign out
IP addresses at our licence server	Held in memory for up to an hour. Not written to disk by our application
Email we send, at Postmark	As Postmark states: content for 45 days, records of bounced and blocked addresses indefinitely

Access, correction and deletion

Email privacy@everyframe.digital to ask what we hold about you, to correct it, or to have it deleted. There is no charge. We will respond within 30 days. We delete on request except where we need the information for an active licence, to stop a licence being copied during its term, or to meet a legal retention period. If we refuse a request we will tell you why in writing, and how to complain.

For anything inside your school's EveryFrame, ask the school. We cannot see it.

Complaints

Email privacy@everyframe.digital with "privacy complaint" in the subject line. We will acknowledge it within 7 days and give you a written response within 30 days. If you are not satisfied, you can contact the Office of the Australian Information Commissioner at oaic.gov.au or on 1300 363 992, although, as explained under "Our status under the Privacy Act", it may be unable to investigate a complaint about us.

Children

Our website and services are for schools and their staff, and we do not knowingly collect personal information from children. The only information about students that EveryFrame touches is processed inside the application, on the school's own computers, and is held by the school, not by us. If someone sends us a child's information by mistake, we delete it and do not use it.

Changes to this policy

When we change this policy we will publish the new version here with a new effective date, and email subscribing schools about any change that matters to them. A feature that would send student information off a school's computers would need this policy to change, and schools to be told, before that feature ships.