Privacy
This page says what we collect, why we collect it, who else sees it and how long each thing is kept. It is written against the Australian Privacy Principles.
What we collect
From a host: your name and email address, and whatever you type into the album — its title, the date, the words you write for your guests.
If you sign in with Google or Apple, that company tells us the name and email address on your account, whether it has checked that the address is yours, and an account id. We keep the name, the address and the account id. Google also sends the web address of your profile picture, which we do not keep. Once you are signed in, we keep none of the sign-in tokens Google or Apple hand back. We have removed the ones we kept from earlier Google sign-ins.
If you choose Apple’s Hide My Email, the address we get is an Apple relay address. Mail we send you goes there, and Apple forwards it to you.
While you sign in with Apple, what Apple sends us — its sign-in code, a signed token carrying your email address and, the first time, your name — passes through a short-lived record on our side. That record is deleted as soon as it is used, and within about twenty minutes if it never is.
From a guest: the photos, videos and recordings they upload, the name and message they choose to attach to them, and a Cloudflare Turnstile check that tells us an upload came from a person rather than a script.
If you add photos to an album, you can leave your email for a link back to them. We use the address only to send that link, and we don’t store it. We keep a scrambled code made from it with a secret key, so the link can find your photos. The hosts and other guests never see your email or the code. The code is deleted with the album. We send nothing else to that address.
And one nobody would guess from the feature list: an IP address. Ten things in the product count requests by IP address so one visitor cannot flood them — reserving an upload, nudging a host, reporting a picture, the partner create form, a wrong passcode, an album link that leads to no album, writing in the guestbook, asking for a link to your photos, signing in, and starting Google or Apple sign-in from a co-host invitation. Each counter row holds the address as part of its key. That is personal information, and we would rather name it here than leave you to find it. Reserving an upload is counted per album, by address and also by the guest’s upload session (gf_up, below); that second counter holds the session’s random id rather than an address. Asking for a link is also counted by the scrambled code of the email address, and removing a photo by the guest’s upload session or that code; neither counter holds an address.
The purpose of those counters is limiting abuse and nothing else. They are outside the album clock below and keep a clock of their own: a counter row falls due 24 hours after its window starts, and a scheduled job removes what is due, in batches. Signing in keeps its counters in a table of its own, where a row falls due 24 hours after its last request, and the same job sweeps both tables.
Signing in as a host also records an IP address and a browser user agent on the session row. The purpose is authentication: it is how the product tells one sign-in from another. Those rows belong to your account rather than to any album, so deleting an album does not touch them, and a cookie expiring on your phone is not the same thing as the row going away.
These words are our own plain-English draft and have not been checked by a lawyer. Where this page and the product disagree, the product is what we describe and this page is what we fix.
Why we collect it
To run the album you asked for. We do not sell your details or your guests’ to anyone, we do not build a profile of you or of your guests, and there is no advertising network anywhere in this product.
We email you offers and news about GuestFlick only if you ask for them, and you can stop them any time from the link in each email or from Email preferences in your dashboard. We never give your address to anyone else to market to you.
Visits to our public pages are counted too, so we can see how many people find us and how quickly those pages load. What we measure, below, says what that involves.
What we measure
Ten things, through Cloudflare’s Analytics Engine: an upload starting, completing or failing; a media file being served; a download archive starting and finishing; a purchase; someone opening our home page, a page for a particular occasion or a photo-sharing guide; someone opening the form that creates an album; and someone not yet signed in pressing Continue to sign in on that form. The first seven each carry at most three short labels — the kind of file, where it belongs, the plan — at most two numbers, such as a byte count, and the album’s id as its only index.
The last three are counted with no cookie and nothing that identifies you. Each keeps four short labels: where the visit came from (a partner, an album’s page or anywhere else); the campaign name, if it is one of our own; whether it looked like a person’s browser or a program, such as a search engine or a link preview; and which page it was or, for the two counts on the form, whether the visit came through a partner’s signed link. Opening a page and opening the form also keep a fifth: the version of any wording test shown on the page, or “none” when there is no test. Your IP address, your browser’s details and the full web address are not kept in them. We look at your browser’s details only to tell a person from a program.
No signed link, no passcode, no token, no email address and no filename is ever put in one.
Our public pages can also run Cloudflare Web Analytics: the home page, the pages for a baby shower, a birthday and a memorial, our photo-sharing guides, and the terms and this privacy page. We allow it only on pages we have reviewed for this purpose, and it runs there only when Cloudflare’s settings enable it. It is a small script from Cloudflare, the company that already hosts GuestFlick, and it reports to an address on our own site that Cloudflare runs. It sets no cookie and stores nothing in your browser.
It sends Cloudflare the page’s web address, with anything after a question mark or a hash (#) cut off; the address of the page you came from, cut the same way, or only our site’s name if you came from another of our pages, never which one; how long the page took to load and how it behaved while loading; and your browser, operating system and kind of device. Cloudflare sees your IP address, as it does for every page it serves for us, and works out your country from it.
Cloudflare says it does not use your IP address or your browser’s details to recognise you, and does not follow anyone from one website to another. It keeps the full detail for a week, then a sample of about one in ten, and its reports cover the past six months.
We use it to see how many people visit those pages, which sites sent them and how quickly the pages load. It never runs on an album, the slideshow, the host dashboard, the form that creates an album, an invitation, or a photo, video or download link: the site’s security settings block it there. Our own counts above remain the numbers we rely on; this is a second, rougher view.
How long we keep it
An album and everything in it run on the clock in the terms, which depends on the plan:
- Free — 30 days to add photos, album up to 3 months.
- Standard — 6 months to add photos, album up to 12 months.
- Premium — 12 months to add photos, album up to 12 months.
When the album window ends we keep everything for another 60 days and then delete the files. The record that the album existed is removed 12 months after that. The same clock, in the terms.
The host who made an album can also delete it themselves at any time, from the album’s Edit details page. Deletion starts at once and guests lose access straight away. The photos, videos and messages are removed from storage shortly after, by the same job that removes an album at the end of its clock; that job works through a few albums at a time, so we do not promise an hour. The record that the album existed is removed 12 months later. Deleting an album cannot be undone.
Material an authority needs kept is kept, the album’s files included, until that authority no longer needs it, whatever the album’s clock says and even after its host deletes it.
Records attached to an album go when the album goes. That is the background jobs, the parts of any download archive we built, and the reminder emails we sent about that album. The record of a payment is kept after the album goes: it holds which album it paid for, what was bought, the amount, whether it was refunded and the Stripe reference, and no photo, message or guest detail.
When we ourselves act on an album, an item in it or an account, the record of that action is kept after the album goes too: it holds which one by its id, when, who acted and why, and no photo or message.
Some records are not attached to an album and outlive it, and it is worth being exact about which. Your account row, and your sign-in sessions with the IP address and user agent on them, belong to your account. The rate-limit counters above belong to no album either. Each row falls due for removal 24 hours after its window starts, and a sign-in row 24 hours after its last request.
We will not state a deletion timeframe the code does not run. Where there is no sweep, this page says there is no sweep, and it changes when the code does.
Who else sees it, and who is overseas
Australian Privacy Principle 8 asks us to name the recipients outside Australia. By category and by vendor, they are:
- Cloudflare — hosting, the database, file storage, the bot check and counting visits to our public pages. Your album and its files live there.
- Stripe — payments. Card details go to Stripe and never to us.
- Resend — the emails we send you.
- Google Fonts — and this one works differently from the other three. We hand Google nothing for this. Some of our pages ask your browser to fetch a font file from Google’s servers, and your browser making that request hands Google your IP address and your user agent. The guest album pages, the slideshow, the host dashboard and the partner create form still do this. The page you are reading, and the public pages, load only the two faces we host ourselves.
- Google and Apple — sign-in, only if you choose to sign in with them. They see that you signed in to GuestFlick, and they receive nothing about any album.
We stay accountable for what we hand each of them. We describe the steps we take and we do not promise anyone else’s behaviour on their behalf.
Who can see an upload
The audience rules live in one place so they cannot drift. The short of it: the links a guest uses are bearer links, so whoever holds one can use it until it expires. Switching the guest gallery off stops the gallery handing out new links, and it does not reach an image link already handed out; an already-issued link to a gallery video or a guestbook recording is refused on the next request, because those are what that switch is checked for. Who can see what is uploaded, in full.
Hiding and deleting are not the same for a download you have already prepared. A hidden item or message stays inside that archive until its links expire. Deleting an item or a written message withdraws every download prepared for the album: the links stop working at once, the archive files are removed shortly after, and the next download is built without it. Deleting also clears the guest’s name and caption on an item, and the words of a message.
How it is looked after
Every page is served over HTTPS. A photo or a video is never a public file on the internet: each one is reachable only through a link our Worker signs and checks, and those links expire in about an hour.
An upload is checked for its type and its size before anything is written. The Turnstile check sits in front of guest upload. Host sign-in is a link we email you, or a Google or Apple account where those are switched on, so there is no password of yours for us to lose.
We describe the mechanism rather than reaching for an adjective. There is no external audit and no certificate behind this page, and a privacy page that says otherwise is fiction.
Children
The Privacy Act 1988 requires the Office of the Australian Information Commissioner to make and register Australia’s Children’s Online Privacy Code by 10 December 2026. The date the Code begins to apply is not set, and we will be bound by it once it is. An album with pictures of children is handled the same as any other: the same clock, the same controls, the same removal path. We build a profile of nobody, we show no advertising, and nothing here is aimed at a child as a user — the host is 16 or over, and a guest uploads without an account.
If you are a parent or guardian and you want a picture of your child taken down, write to abuse@guestflick.com.
Access, correction and complaints
To ask for a copy of what we hold about you, to have it corrected, to have your account removed, or to complain about how we have handled any of it, write to ops@guestflick.com.
A person reads that inbox and answers. We are a small Australian product and we would much rather fix something than have it escalated, so please tell us first.
If our answer does not satisfy you, the Office of the Australian Information Commissioner is the regulator for the Australian Privacy Principles, and you can take a complaint there.
Changes to this page
The version and the date at the top move whenever the words do, and the words move when the product does. Each version is kept in our source history under its version string.