fliklist — Privacy Policy

Who this is about

fliklist is how two people decide what to watch: you each swipe through the same films and shows, and fliklist tells you what you both said yes to. It is published by Lucid Studios LLC. Questions go to developer@lucidstudios.io.

This one policy covers all three ways you can use fliklist — the iPhone app, the Android app, and the website at flicker.joeyshub.com. They are the same product talking to the same server and the same database, so splitting this into separate policies would only mean two pages saying the same thing and drifting apart. Where the app and the website genuinely differ, this policy says so on the spot rather than hiding it.

fliklist is rated for adults and is not directed at children. We do not knowingly collect anything from anyone under 18.

Your account

Unlike a timer or a notepad, fliklist cannot work without an account — the whole point is that your swipes meet someone else's. Creating one stores:

• Your email address. It is how you sign in, it is the only way we can reach you, and — see What your partner sees below — a partner can read it.
• Your password, stored only as a one-way Argon2 hash. We cannot read it, and nobody here has ever seen it.
• A display name — the label your partner sees. It starts as the part of your email before the @, and you can change it in Settings to anything you like. It does not hide your email address, though — changing it changes the label, nothing else.
• Three timestamps and a counter: when you signed up, when you last used fliklist at all, when you last read your home feed, and how many swipes you have made. They drive "what's new since you were here" and nothing else.

There is no self-service password reset yet. If you are locked out, write to developer@lucidstudios.io.

What you do in fliklist

This is the part that lives on our server, because it has to be compared against another person's. Everything here is tied to your account:

• Every swipe — the title and whether you said yes or no, with the time you did it.
• Which streaming services you told us you subscribe to, so the deck shows things you can actually watch.
• Your pairings: who you are connected to, and whether the connection is pending or active.
• Your matches — the titles you and a partner both said yes to — and the time each one happened.
• Titles you added outright to a shared list without meeting them in the deck. Adding one also records a yes swipe from you for that title, so the list and your swipes do not disagree.
• What you marked as watched, which list it came from, and who marked it.
• The daily pick fliklist suggested you, and whether you watched it, skipped it, or left it alone. A fourth state is ours rather than yours: a pick is retired when its title leaves your shared list.
• The activity feed for each pairing — a short record of what happened between the two of you, so neither of you has to be online at the same time.

Trailers are the one thing fliklist plays that it does not hold itself. Tapping play opens an embedded YouTube player — Google's privacy-enhanced youtube-nocookie.com one — which means your device connects straight to Google for that video. What they can see is the ordinary shape of a video request: your IP address, your browser or app's identification line, and which trailer you asked for. Nothing about your account, your swipes or your partner goes with it, and nothing happens at all until you tap play.

The films and shows themselves are not about you. fliklist keeps its own catalogue — names, posters, blurbs, scores, cast, and which services carry what — refreshed from Watchmode. That catalogue is the same for everybody.

What your partner sees

Your display name and your email address, and everything the two of you share: what you matched on, what either of you added or marked watched, and the activity feed for your pairing. That is what a shared list is.

The email address is worth spelling out, because it is the one people assume is hidden. It is printed under your name on the Partners screen, and it is what "Added by …" says beside anything you put on a shared list yourself. Somebody you ask to pair with sees it too — they have to know who is asking. An invitation emailed to a stranger does not: that message carries your display name only, and your address reaches them once they have an account and the pairing exists. Your display name is a label on top of it, not a mask over it.

Your partner also sees, in the home feed, how many titles you swiped through on each day you used the deck and when the last of those was — a number and a time, not which titles. It is what tells them you have been keeping up, so neither of you is waiting on the other without knowing it.

Your swipes are never published to your partner as a list. Two of them show through anyway, and it is fairer to say so than to claim otherwise. The Alone list shows each of you the titles you said yes to that every active partner has said no to — so with one partner, their Alone list tells them, title by title, which of the things they liked you passed on. And when a title stops being a match because one of you changed a yes into a no, the other is told which title it was. Everything else — the titles neither of you flagged, and every no on something they never said yes to — stays yours.

Your partner never sees your password, and never sees anything from a different pairing. You can hold more than one pairing at a time, and they are entirely separate from each other.

Either of you can unpair at any time, from the partners screen.

Inviting somebody

To invite a partner you type their email address. We store that address so the invitation can be tracked and resent, and we mail it — through Resend, our email provider — a message saying who invited them and carrying a link. If it did not arrive you can send it again, and each resend is another message carrying a fresh link, so there may be more than one.

Two things about that link, because it is a credential and not just a shortcut. It expires seven days after the most recent send, not seven days after the first — resending pushes the clock out. Only the newest link works — a resend retires the one before it. And a live link is not spent by being followed: until it is accepted, cancelled, or runs out, it signs that address in every time, not once. Possession of the inbox is what proves the address, exactly as a password-reset link works, so treat it like one and don't forward it.

fliklist never reads your contacts. There is no address book access on either phone: the only email address involved is the one you type.

You can cancel a pending invitation from inside the app. That kills the link immediately — it stops working there and then. The record of the invitation is not thrown away, though: it is what tells whoever you invited that the link was cancelled rather than simply broken, and it still holds the address you typed. It stays until you delete your account.

Notifications

Notifications are optional, off until you turn them on, and can be turned off again — in fliklist's Settings, or in your phone's or browser's own settings.

In the app, turning them on stores a Firebase Cloud Messaging device token and which platform it came from — iPhone or Android. The token is a delivery address for this one device. Google delivers the message for us (and Apple's push service carries it the last leg on an iPhone); a notification says who did what, for example that a partner matched with you.

On the website, turning them on stores a Web Push subscription: the endpoint URL your browser issues and the two keys that let us encrypt a message to it. Your browser's push service delivers it.

Our Firebase project exists only to route notifications. Google Analytics is switched off in it, and fliklist contains no analytics SDK of any kind.

What sits on your device

Not much, and this is the one place the app and the website genuinely differ. Both keep a signed-in session; they just keep it in different places.

• In the app: your session token, held in the iPhone's Keychain or Android's Keystore-backed storage. On iPhone it is deliberately marked device-only and excluded from iCloud Keychain sync, so a token can never ride a backup onto another phone.
• On the website: one cookie named flicker_session, holding the same kind of session token. It is HttpOnly (JavaScript cannot read it), SameSite=Lax, sent only over HTTPS, and lasts 90 days from your last visit. It is the only cookie fliklist sets. There is no advertising cookie and no third-party cookie.
• On both: a few small values in local storage — your deck filters and sort order, whether you have already been asked about notifications, whether you switched app notifications off, and whether you have seen the first-run tour. One of these does leave the device: the deck filters and sort order ride along with every request for a new deck, because the narrowing and the ordering happen on our server. The rest never go anywhere.
• On both, until the tab or the app is closed: which partner you last had selected, so a reload keeps you on the same shared list. It is a single id in session storage, it goes when you close, and it is sent with the requests for that pairing's screens — the server has to know which shared list you are looking at.

Signing out clears the session on that device. On the website, clearing your browser's site data clears the rest.

Feedback you send from the app

The account menu › Send feedback sends exactly five things: whether it is a bug or an idea, what you typed, your fliklist version, your OS version, and the email address on your account.

There is no email box on the form, and nothing to leave blank: feedback from fliklist is never anonymous. You are already signed in, so our server attaches your account's own address rather than asking you to type one. That is a deliberate choice — a bug report we cannot ask a follow-up question about is usually a bug we cannot fix — and the form says so before you send.

Your report passes through our server, then through a small relay service we run, and becomes an issue in our private GitHub repository for fliklist. GitHub stores and holds that issue on our behalf, so your description and your email address rest with GitHub. The relay keeps nothing itself.

Your device never contacts the relay directly, so your IP address is never seen by it. The relay counts a short-lived, one-way salted hash of whoever called it to stop abuse — which, for fliklist, is our own server rather than you.

Please don't put anything in a report you would rather keep private. Type what happened, not your passwords.

Who else touches your data

A handful of companies, each doing one job for us. None of them is allowed to use your data for their own purposes, and none of them pays us for it:

• Amazon Web Services (US East, Northern Virginia) — the server and the database fliklist runs on. Everything in the two sections above lives here.
• Resend — sends our two emails, and only those two: a partner invitation, and the confirmation that an account has been deleted. There is no newsletter and no marketing mail.
• Google (Firebase Cloud Messaging) and, on iPhone, Apple (APNs) — deliver notifications to the app, if you turned them on. Analytics is off.
• YouTube (Google) — plays a trailer, and only when you tap one, through the youtube-nocookie.com player. That connection is made by your device, not by our server, so Google sees your IP address, your browser or app's identification line, and the video id.
• GitHub — holds feedback you send, as an issue in a private repository.
• Watchmode — the source of the film and show catalogue. This one is worth stating plainly: our server does the asking, about films and never about you. No swipe, no account, and no identifier of yours is ever sent to them. One thing does reach them from your side, though: poster pictures are not copied onto our server, they are loaded from Watchmode's own image host wherever a poster appears — the deck, your shared list, the Alone list, tonight's pick, search results and your history — so that host sees your IP address and your browser or app's identification line, the same as any picture on any web page.

Three links inside fliklist lead out of it: this policy and the support page, both served by GitHub Pages, and Watchmode's own site from the credit in Settings. Following one is an ordinary visit to that site, and what it sees is what any site sees when you visit it.

Beyond these, we would only hand anything over if the law actually required it of us.

What fliklist never does

• No analytics. There is no analytics SDK in the app or on the website, and no analytics events are collected or sent anywhere.
• No crash-reporting SDK.
• No advertising SDK and no ad network. The occasional full-screen card between swipes is one of three picture files shipped inside fliklist itself — it loads nothing, reports nothing, and knows nothing about you.
• No advertising identifier, and fliklist never follows you across other apps or websites — it carries no third-party code that could. It does open connections to other companies, and all of them are named above rather than hidden here: poster pictures from Watchmode's image host, a trailer from YouTube if you tap play, and — only if you turned notifications on — the standing delivery channel between your device and Google's Firebase Cloud Messaging, or your browser's own push service.
• We do not sell or rent your data to anyone.
• No location, no GPS, no contacts, no camera, no microphone, no photo library.
• fliklist does not play films or shows, so it knows nothing about what you actually watched — only what you told it you watched.

How long we keep it

For as long as your account exists, and no longer. Nothing in fliklist expires on a timer: your swipes, matches, watch history, added titles, daily picks and the activity feed for each pairing stay while the account does — a shared list that quietly forgot last month would not be a shared list, and "have we seen this?" is a question about years, not weeks.

Three things do carry a clock. An invitation link expires after seven days. The website session cookie lasts 90 days from your last visit. A notification token is dropped as soon as the delivery service tells us it is dead, or when you switch notifications off.

Deleting your account is what ends the rest, and it is not a scheduled job — it happens at the moment you confirm. There is no backup copy of our database for anything to linger in afterwards, and no archive we keep on the side.

Deleting your account

Open fliklist, go to Settings › Delete account, and confirm. It happens immediately and it is permanent — there is no waiting period, no recovery window, and nothing kept behind as a ghost.

Everything in the sections above goes: your account and display name, your password hash, every swipe, every pairing you were in, your matches, your watch history, the titles you added, your daily picks, the activity feed for those pairings, your invitations, and any notification address for your devices.

Your partner keeps their own swipes and their own account, and simply sees themselves as unpaired. They are not told that you deleted your account, because that is not theirs to know.

We send one last email to the address on the account, saying it has been deleted — so that if it was not you who did it, you find out.

Three things deliberately survive, because they are not ours to delete on your behalf:

• Feedback you already sent, which lives as an issue in our private GitHub repository, with your address on it.
• Emails already delivered to somebody's inbox. We cannot reach into a mailbox that is not ours.
• An invitation somebody else sent to your address. That record belongs to the person who sent it, not to you, and it still holds the address they typed. Your own invitations — the ones you sent — go with your account.

Ask us at developer@lucidstudios.io and we will delete the issue, including your address on it, and any invitation still holding your address.

If you would rather not use the in-app button, or you want a copy of what we hold about you first, write to the same address and we will take care of it.

Changes to this policy

If fliklist's data practices change, this page changes with them and the effective date at the top moves. The current version is always the one you are reading.

Contact

Lucid Studios LLC — developer@lucidstudios.io