FlimmerPrivacy
Last updated 2 October 2026
Flimmer is a player. Its account service stores only what it needs to sync your account; your video and your provider's full catalogue never pass through our servers.
The short version. We store your email address so you can sign in, plus your profiles, your favourites, the series you follow and where you stopped watching, so those can follow you to a new phone when you opt into provider restore; otherwise the provider credential and the random library namespace remain on this iPhone and cannot be re-associated after a reinstall. If you choose to send feedback, we store the message and any diagnostics you choose to attach. We do not use trackers, advertising or third-party data-collection SDKs. We do count a handful of anonymous milestones — first launch, provider connected, first film played, crashes per app version — as totals with no account, no device identifier and no free text; you can switch them off in Settings. Your video never passes through our servers.
You do not need an account. Flimmer plays your own provider without one, and when you use it that way nothing that identifies you reaches our servers — no account, no email, no profile, no favourites, nothing you watched, not even a message you send us. Such a device sends only the anonymous milestone counts above — the same for everyone, carrying no identifier, and switched off in the same place — and a request for this week's popular films and series, which carries nothing about you. Your saved library stays on that device: a reinstall loses it and a second device will not see it. Sign in only when you want it to follow you, and everything below then applies.
What we collect
| Data | Why |
|---|---|
| Email address | It is your account. We email you a six-digit code to sign in. If you use Sign in with Apple and hide your address, we only ever see Apple's relay address. |
| Profiles | A name and an emoji you choose, so a household is not one shared mess. A random profile-create request id is retained as a bounded retry record; if that profile is deleted, the record temporarily remains as a tombstone so a lost-response retry cannot recreate it. |
| Sign in with Apple authorization | If you use Sign in with Apple, Apple gives our account service a refresh token so it can disconnect Flimmer from your Apple Account when you delete your Flimmer account. We encrypt that token at rest and never use it to read any other Apple data. |
| Favourites and resume points | The identifier and title of an item on your provider, an optional artwork URL after the app removes known provider host and credential material, and how many seconds into it you were. This is what makes “Continue watching” work on a second device whose provider restore includes the same catalog namespace. Rows also carry a random catalog namespace so ids from two unrelated providers cannot be confused. It is not derived from your provider address, username, password, or device. |
| Series you follow | For each series you follow, or have followed, on your provider: its identifier and title, an optional artwork URL as above, whether you still follow it, and how far through its episode list you have looked, so a series you have caught up with on one device is not “new” on another. An unfollow is kept as a row that says so, which is how your other devices stop following too; it is deleted with your account like the rest. Following works without an account; this is only stored when your signed-in device sends its changes. New-episode alerts are composed on your iPhone or iPad from your own provider’s answers and shown by the system — Flimmer has no push service, and what an alert says never reaches our servers. The only trace an alert leaves with us is the anonymous count below of how many installations have opened one, which you can switch off. |
| Your provider's address and sign-in — only if you ask us to | Ticking “Remember on my account” stores the provider address and username, and an AES-GCM-encrypted password, so a new device is a sign-in rather than a retyping session. The same random catalog namespace is stored so the new device opens your synced library safely. Leave it off and the credential never leaves your iPhone. |
| Short-lived security records | We keep counters and one-time replay records to stop sign-in-code, Apple-sign-in and API abuse. Their keys include one-way SHA-256 values derived from a normalized email alias, client IP address, account id, or Apple's opaque subject, plus random lease owners and counts/timestamps. These are pseudonymous operational identifiers, not anonymous data, and are never used for advertising, analytics or cross-service tracking. We do not store the raw client IP address in these records. |
| Feedback — only when you send it | Your message, its category, the app and system versions, device model, the screen you sent it from, and the connection log if you choose to attach it. Provider responses are reduced to status, timing and fixed categories; the log contains no provider address, credential, title, stream id or raw response text. Invisible control and bidirectional-formatting characters are removed before storage so an exported report cannot forge or reorder an operator's display. |
| Anonymous milestone counts | Totals only: how many installations reached first launch, connected a provider, built a library, played something, signed in or stayed a guest, followed a series or opened a new-episode alert — and how many crashes or freezes each app version had. Each is a count per day, platform and app version. There is no account, no device identifier, no installation identifier, no location, no free text and nothing about your provider or what you watch. We do not store your IP address with them. Turn them off in Flimmer under Settings → Anonymous counts. |
What we do not collect
- Nothing that identifies you, if you use Flimmer without a Flimmer account. The app talks to the provider you configured; what it sends us is the anonymous milestone counts described above, which you can switch off, and a request for this week's popular films and series, which carries nothing about you.
- No third-party analytics, advertising, tracking or crash-reporting SDK, no advertising identifier, no device fingerprinting and no profiling. The only measurement is the anonymous milestone counts described above, which carry no identifier of any kind and which you can switch off. The short-lived pseudonymous abuse counters described above are used only to protect the account service.
- Flimmer's functional open-source dependencies are disclosed in the app and in our terms; none of them collects anything.
- We never receive your provider's full catalogue or channel list, and no media stream passes through us — the app fetches those directly from the server you configured. The account service sees only the saved/watched item metadata described above when you choose to sync it.
- We do not sell data or share it for advertising or tracking. Cloudflare processes the account data needed to host this service, as described below.
An honest word about the provider vault
If you tick “Remember on my account”, your provider password is encrypted with AES-GCM before it is stored. Our server holds the key, which means our server can decrypt it. That protects you against a database leak; it does not protect you against us. We say so plainly in the app at the moment you choose, and the feature is optional. If that trade is not for you, leave it off — the app works exactly the same, and the credential stays in your iPhone's Keychain.
Setting up an Apple TV from your phone
Typing a server address and a password with a TV remote is miserable, so the Apple TV shows a code and your phone does the typing. If your phone sends the Apple TV your provider login, it is encrypted for that exact television before it leaves your phone, using a key the television made and never gave us in a readable form. Our server passes the encrypted blob along, deletes it the moment the television collects it (and in any case after five minutes), and holds no key that could open it. This is the one place where “we cannot read it” is literally true, and it is true because the code shown on your television is a fingerprint of the television's own key: your phone refuses any key that does not match what you saw on screen.
If your phone is signed in, the Apple TV is given its own new Flimmer session by our server. Your phone's sign-in is never copied to the television, and you can sign the television out on its own. Before it uses that session, the television shows you which account your phone is signing it into and waits; if it is not yours, one button turns the sign-in down and the television keeps none of what came with it — not the account, and not the provider login that came with it. Anything that was already on that television, such as a provider login someone typed on the remote, is left alone. What the television itself had saved — its favourites and where it had got to in something — is not sent to that account unless the sign-in actually goes through: it moves into the account on the television first, and is only uploaded once you have accepted.
You do not need Flimmer on your phone for this. Scanning the code on the television's provider screen with any phone's camera opens a setup page on our website. It shows you the code first and asks you to confirm that the same code is on the television in front of you — if someone sent you the link, stop there, because whoever shows that code receives the login. You then type your provider login, and it is encrypted in your browser, for the television showing that code, before it is sent — the same encryption the app uses, done by the page's own code with the cryptography built into your browser. Our server only relays the encrypted login, keeps it for at most five minutes, and holds no key that could open it. The page loads nothing from any other site, sets no cookies and stores nothing on your phone, and it can only send a provider login: it can never sign the television in to a Flimmer account. The code and the television's key are in the part of the link a browser does not send when it loads the page; the page then sends the code — never the key — inside the request that delivers your login, where our server uses it to find the pairing and keeps it only as a one-way keyed hash for those five minutes. Neither is written to our logs. As everywhere else on our service, your IP address is used briefly to stop abuse and is not stored in a readable form.
Flimmer asks for no camera access of its own. Scanning is your phone's own Camera app opening that page, which offers to hand over to the Flimmer app if you have it, and you can always type the twelve characters into the app instead.
This week's popular films and series
Home can show what is popular this week among the films and series your own provider offers. The app asks our server for the week's lists; the request carries no account, no title, nothing from your catalogue and nothing about what you watch — at most a country code, which our server currently ignores. The lists are the same for everyone. Our server builds them from public data: how often Wikipedia articles were read, published by the Wikimedia Foundation, and Wikidata, both under the CC0 public-domain dedication. It sends those services nothing from your request. Matching the lists against your provider's catalogue happens on your device. As everywhere else on our service, your IP address is used briefly to stop abuse and is neither written to our logs nor stored in a readable form.
Where it lives
On Cloudflare's network, in a database hosted in Western Europe. Traffic between the app and our servers is encrypted with HTTPS. Your provider credential is always stored on your iPhone in the Keychain. If you choose “Remember on my account”, its address and username plus an encrypted password also live in that account database. A Sign in with Apple refresh token is also AES-GCM encrypted in the account database when that sign-in method is used. A token Apple has issued is encrypted before Flimmer finishes linking it to an account, so a rejected or interrupted sign-in can still be cleaned up without retaining plaintext.
Operational logs
Persistent Cloudflare invocation logs and traces are disabled because they include request URLs, and Flimmer URLs can contain profile ids or sync cursors. The account Worker retains only deliberately data-minimised operational event categories, status numbers and error classes: no request URL, body, email, account or profile id, cursor, code, token, provider identity or credential. Cloudflare still processes each HTTPS request transiently to deliver the service.
How long we keep it
Your synced library remains until you delete its profile or your account. Removing a favourite leaves a hidden deletion marker on the server; we keep that marker so a phone which was offline for a long time cannot accidentally bring the favourite back. It is erased with the profile or account. A sign-in code is deleted when used and becomes unusable after ten minutes. Scheduled, bounded housekeeping then removes expired codes (normally on the next 15-minute run; a backlog can take additional runs). Sessions expire after 90 days of not being used, each account retains at most its 20 most recently used or created sessions, and expired rows are removed by the same housekeeping. An Apple TV pairing lasts five minutes, is delivered once and is then deleted; cancelling on the television deletes it immediately, and the same bounded housekeeping removes any that were abandoned. Profile create retry records last at most 30 days and are capped at the newest 100 per account; profile deletion leaves a tombstone only inside that bounded window. Feedback is capped at the newest 100 reports per account and otherwise lasts until account deletion. Per-IP abuse counters stop accepting requests after their one-hour window; global email and verification counters use a 24-hour window, while Apple sign-in counters use a one-hour window. Their one-way keys remain until bounded housekeeping removes rows at least 24 hours old, so a backlog can require additional 15-minute runs. Apple identity-token replay hashes remain through that token's short expiry and the next bounded sweep. The one-way email-identity and Apple-subject coordination leases used during sign-in, linking, deletion or revocation are normally deleted with the request; an interrupted request's lease becomes inactive after five minutes and is removed by housekeeping. If Apple is temporarily unavailable while you delete your account—or while we clean up a grant from a sign-in that could not finish—the encrypted refresh token is kept without your Apple subject, Flimmer user id, or an account foreign key. A one-way subject tag is retained only to avoid revoking a still-live Apple authorization after a concurrent sign-in. The row is retried for up to 30 days, then destroyed. Anonymous milestone counts are kept for at most 400 days and then deleted; they contain nothing that could be linked to you, so account deletion neither removes nor needs to remove them.
Deleting everything
Open Flimmer, go to Settings → Delete account. That erases your account, your profiles, profile retry/tombstone records, your favourites, the series you follow or have followed, your resume points and your stored provider credential, along with feedback you sent. It is immediate and it is not recoverable. Short-lived pseudonymous per-IP/global abuse counters, coordination leases, and already-consumed Apple replay hashes are not account-owned rows; they expire under the retention rules above. If you used Sign in with Apple, we also ask Apple to revoke Flimmer's access. If an older account has no token we can revoke, the app tells you to remove Flimmer in your Apple Account settings; this never delays deletion of your Flimmer data. You can also email us to request deletion of Flimmer data, but only you can use Apple's manual account control. If another operation is already changing the same Apple authorization, deletion asks you to retry before erasing anything rather than report success while that operation is still in flight.
Children
Flimmer is not directed at children and we do not knowingly collect anything from them. The app has profiles that can be marked as a child's, which hides adult categories regardless of any other setting.
Your rights
If you are in the EEA or the UK, the GDPR gives you the right to see, correct, export or erase what we hold about you, and to object to how we process it. The Delete account button covers erasure; for anything else, email us and we will answer. The legal basis for what little we store is performing the service you asked for. Our lawful establishment is in Norway.
Changes
If this policy changes in a way that matters, we will say so in the app rather than quietly editing this page.