Effective date: [PLACEHOLDER — confirm: effective date]
Last updated: [PLACEHOLDER — confirm: date this version is published]
Version: 1.0 (draft — not yet attorney-reviewed)
0. The short version
ChuEok lets an event host collect short video and voice messages from their guests. Guests do not need an account, an app, or a password — they open a link or scan a QR code, record a message, and it goes to the host.
That means we handle something unusually sensitive: video and audio of identifiable people, recorded by people who often never signed up for anything themselves. This policy explains exactly what we hold, who touches it, how long we keep it, and how to get it removed.
We do not sell your data, we do not show ads, and we do not use any third-party analytics or tracking SDKs.
1. Who we are, and who is responsible for what
"ChuEok", "we", "us" means [PLACEHOLDER — confirm: full legal entity name, e.g. "ChuEok Inc."], of [PLACEHOLDER — confirm: registered business address]. You can reach us at [PLACEHOLDER — confirm: contact email; the code currently sends outbound mail from support@mychueok.com].
The Service means the ChuEok websites at [PLACEHOLDER — confirm: production domain(s); the code assumes mychueok.com], the ChuEok iOS app, and the guest recording pages.
Three kinds of people appear in this policy:
| Term | Who it means |
|---|---|
| Host | A person with a ChuEok account who creates an Event and receives the messages. |
| Co-Host | Someone a Host invites by email to view an Event's messages. |
| Guest | Someone who records a Message for an Event. Guests have no account. |
Who is the data controller?
- For Host and Co-Host account data, we are the controller.
- For the Messages guests record (the video, the audio, the name, the note), the Host decides why they are collected, who sees them, and when they are deleted. Under GDPR/UK GDPR terms, the Host is the controller of that content and we act as their processor, hosting and delivering it on their instructions.
- We are also a controller for a narrow set of our own purposes that apply to Message traffic — fraud and abuse prevention, rate limiting, security logging, and keeping the Service running.
[PLACEHOLDER — confirm with counsel: controller/processor characterisation.] The split above is the honest description of how the system actually behaves, but a regulator could instead treat ChuEok and the Host as joint controllers for Messages, which would require a joint-controller arrangement under GDPR Art. 26 and a different statement here. Counsel must decide, and if the processor model is kept we need a Data Processing Addendum that Hosts accept.
2. What we collect
2.1 If you are a Host (you have an account)
| Data | Where it comes from |
|---|---|
| Email address | You type it, or Apple gives it to us when you use Sign in with Apple (this may be an Apple private-relay address). |
| Password | You choose it. It is stored only as a salted hash by our authentication provider. We never see it. |
| Display name | You type it, or it is derived from your Apple/profile data, or defaulted from the part of your email before the @. |
| Apple user identifier | From Sign in with Apple, if you use it. |
| Event content you create | Event title, category, theme, the prompt question you ask guests, an optional intro note and thank-you message, how long messages may be, and when the Event opens and closes. |
| Your intro recording | If you record or upload a video/voice intro for your Event, we store that media. Note: intro media is stored in a public bucket — see §6.2. |
| Notification preferences | An account-level on/off switch and a per-Event push/email switch. |
| Push notification token | If you allow notifications in the iOS app, we store the Apple Push Notification token for your device, plus the platform label. |
| Billing identifiers | If paid subscriptions are enabled and you subscribe, we store a Stripe customer ID, a Stripe subscription ID, and the subscription status. We never receive or store your card number — Stripe handles that directly. |
| Session data | Login session cookies in your browser; a session token held in the iOS Keychain on your device. |
| Support messages | If you write to us through the support form, we receive whatever you put in it. |
2.2 If you are a Guest (you record a message)
| Data | Notes |
|---|---|
| Your video and/or audio recording | This is the sensitive one. It contains your face, your voice, whatever you say, and whatever is visible or audible behind you. Your image and your voice are personal data about you. |
| Your name | Required — you type it before recording. |
| Your email address | Optional. See the transparency note below. |
| A written note | Optional. |
| Recording metadata | Media type (video or voice), length in seconds, real file size, upload timestamp, and the storage location of the file. |
| A device identifier | On the web this is a random ID we create and store in your browser's local storage (guestbook_device_id). In the iOS app it is Apple's per-vendor device identifier. It is not linked to any account and is not used to track you across other websites or apps — it exists to group your repeat messages under one name and to stop one device from flooding an Event. |
| Your IP address | Recorded against each upload authorisation, to rate-limit abusive traffic. |
Transparency note — Guest email. The Guest email field is presented as optional and, in the current build, we do not send anything to it. It is stored on the Event record and is visible to the Host and Co-Hosts. If we start using it (for example, to tell a guest the host watched their message), we will update this policy first. [PLACEHOLDER — confirm: decision. Either remove the field, or state a concrete purpose here. Collecting an identifier with no stated purpose is a data-minimisation problem under GDPR Art. 5(1)(c).]
2.3 What we do not collect
- No advertising or marketing SDKs, no third-party analytics, no cross-site trackers, no fingerprinting beyond the single device ID described above.
- No location data.
- No contacts, photo library scanning, or health data.
- No facial recognition, voiceprinting, or biometric matching. We never analyse a recording to identify who is in it.
- The "analytics" screen a Host sees (message counts, total minutes) is computed only from that Host's own Event data. It is not a third-party product.
3. Why we use it, and our legal basis
For people in the UK, EU/EEA, and other places with similar law, here is the lawful basis for each purpose. (Basis references are to GDPR Art. 6.)
| What we do | Why | Lawful basis |
|---|---|---|
| Create and run your Host account; authenticate you | To provide the Service you asked for | Performance of a contract, Art. 6(1)(b) |
| Store and play back Messages for the Host | Core function of the Service | Contract with the Host, 6(1)(b); for the Guest's own data, consent given by choosing to record and submit — see §4 |
| Transcode video and serve it over a CDN | So messages actually play on every device | Contract, 6(1)(b) |
| Send push and email notifications about new messages | Requested by the Host, and switchable off | Consent, 6(1)(a), for push (an OS-level permission); legitimate interests / contract for service email |
| Send the "your event expires soon" warning emails | So a Host does not lose content unexpectedly | Legitimate interests, 6(1)(f), and contract |
| Rate limit uploads by device and IP; cap messages per Event; enforce file size and format limits | To stop spam, flooding, and abuse of the recording link | Legitimate interests, 6(1)(f) |
| Take payment for keeping an Event past its free period | To bill you | Contract, 6(1)(b) |
| Respond to takedown, deletion, and support requests | To honour rights and keep the Service safe | Legal obligation, 6(1)(c), and legitimate interests |
| Keep security and error logs | Security and reliability | Legitimate interests, 6(1)(f) |
We do not use anyone's data for advertising, profiling, automated decision-making, model training, or resale.
[PLACEHOLDER — confirm with counsel: special-category analysis.] Face and voice recordings are only "biometric data" under GDPR Art. 9 when processed for the purpose of uniquely identifying a person, which we do not do. Some US state laws (notably Illinois BIPA and Texas CUBI) define biometric identifiers differently and may be triggered by capturing face/voice at all. Counsel should confirm whether an Art. 9 basis and/or a state biometric notice and written-consent flow is required before launch, particularly for Events held in Illinois or Texas.
4. Consent to be recorded — please read this
ChuEok records people. Two things follow.
If you are a Guest: recording and submitting a Message is voluntary. Nothing is uploaded until you tap the button to send it. When you send it, you are agreeing that the Host of that Event may keep, watch, download, and share your Message according to §5 below. If you change your mind, see §9 — you can ask for it to be removed.
If you are a Host: you are responsible for making sure everyone in a Message knows they are being recorded and agrees to it, and for meeting any legal requirement that applies where your Event takes place. Some places require the consent of everyone recorded. Some require notice before recording starts. Some have specific rules about recording children. We do not obtain that consent for you, and we cannot. The Terms of Service place this obligation on you.
Children. The Service is not intended for people under [PLACEHOLDER — confirm: minimum age. Our recommendation is 16 for Hosts, aligned to the highest GDPR "information society services" age, or 13 with parental- consent handling; the current web copy says 16]. You may not create an account if you are under that age. If a child appears in a Message — which happens at weddings, birthdays, and family events — the Host must have permission from that child's parent or guardian before collecting the recording. If you believe a Message contains a child whose parent or guardian did not agree to it, contact us at [PLACEHOLDER — confirm: contact email] and we will remove it. We do not knowingly collect account data from anyone under the minimum age, and we will delete it if we find it.
[PLACEHOLDER — confirm with counsel: COPPA position.] ChuEok is not directed to children and has no child-oriented features, so it should sit outside COPPA's "child-directed service" definition. But a Guest recording is collected without any age gate at all, and a child can physically record one. Counsel must decide whether an age attestation on the guest recording screen, a stated minimum guest age, or an explicit "hosts must obtain parental consent" acceptance is required. The current build has no age gate anywhere.
5. Who can see a Message
- The Host of the Event, and any Co-Hosts the Host invites by email. Co-Hosts see guest names, recordings, notes, and Event details.
- Us, only as needed to run, debug, secure, or moderate the Service, or to answer a legal request.
- Our service providers (§6), strictly to perform the service they provide.
- Anyone the Host chooses to show it to. Hosts can download messages and do what they like with the files after that. We have no control over what happens to a downloaded copy.
Access is also protected by the secrecy of links. Two honest caveats:
- The guest recording page is reachable by anyone holding the Event's share code. The code is randomly generated and not guessable in practice, but it is not a password — anyone a Host forwards the link to can open the recording page and can see the Event title, prompt, host intro media, and the count of messages received.
- Playback URLs for stored messages are long, unguessable links. They are not individually password-protected, so anyone who obtains a playback URL can watch that message. Do not repost those links publicly.
[PLACEHOLDER — engineering decision, then confirm here: whether to enable signed/tokenised playback URLs on the CDN.] Today the CDN playback URL and the downloadable MP4 rendition are accessible to anyone with the link. That is a normal industry pattern but it is worth an explicit product decision before launch, and this section must match whatever is chosen.
We do not sell personal information, and we do not "share" it for cross-context behavioural advertising, as those terms are used in the California Consumer Privacy Act as amended by the CPRA.
6. Our service providers (sub-processors)
We use these companies to run ChuEok. Each one only gets what it needs.
| Provider | What it does for us | What it touches |
|---|---|---|
| Supabase | Database, authentication, and file storage | Everything: account records, event records, guest names/emails/notes, recording metadata, the original media files, IP addresses and device identifiers in the rate-limit ledger |
| Cloudflare (Stream) | Converts uploaded video into a streamable format, generates a poster thumbnail, and delivers playback worldwide | Video Messages and their thumbnails |
| Vercel | Hosts the website and runs the scheduled cleanup and email jobs | Web requests, including IP addresses and standard server logs |
| Resend | Sends our transactional email (new-message digests, expiry warnings, support replies) | Host email addresses; guest names appear in digest emails |
| Apple | Sign in with Apple; Apple Push Notification service for iOS alerts | Apple account identifier / relay email; push tokens and notification content |
| Stripe | Subscription billing, only if paid subscriptions are switched on | Host email and payment details, handled directly by Stripe. We store only Stripe's customer/subscription IDs and status. |
Cloudflare Stream and Stripe are environment-gated in the current build: if they are not configured, video falls back to direct signed-link delivery and no billing occurs. [PLACEHOLDER — confirm: which of these are live on the launch date. This table must be trimmed to only the ones actually enabled, or state clearly that they may be enabled.]
We may also disclose data to professional advisers, or to a buyer if the business is sold or merged, or where we are legally required to (court order, lawful request from a public authority), or where necessary to protect rights, property, or safety.
6.2 One thing you should know about host intro media
The bucket that stores a Host's own intro recording is publicly readable. Anyone with the file URL can play it, without signing in. This is deliberate — it lets guests see the host's welcome before recording — but it means a host intro should be treated as public-facing content, not private content. Guest Messages are stored in a separate, private bucket.
7. Where your data goes
Our providers operate globally, and your data will be stored and processed in countries other than your own — in particular the United States, and wherever Cloudflare's global network caches video for playback.
If you are in the UK, EU/EEA, or Switzerland, transfers out of your region rely on appropriate safeguards, in our case the European Commission's Standard Contractual Clauses (and the UK Addendum / Swiss equivalents) in our contracts with those providers, together with the providers' own certifications.
[PLACEHOLDER — confirm: hosting region of the Supabase project, and confirm that signed SCCs / DPAs are in place with Supabase, Cloudflare, Vercel, Resend and Stripe before publication. If EU/UK users are targeted, counsel should also advise on whether a UK/EU representative under GDPR Art. 27 is required.]
8. How long we keep things — the real numbers
We would rather tell you exactly what the software does than give you a vague promise.
8.1 Events and everything in them
- When an Event is created in the current apps, it is stamped with an expiry 37 days from creation (30 days plus a 7-day grace period). The server enforces this window; a host cannot extend it by editing the request.
- A scheduled job runs on our servers and, when an Event's expiry passes, deletes the Event and its media. Deleting the Event also removes its guest records, message records, reactions, notification queue entries and the rate-limit ledger rows (including the stored IP addresses) for that Event.
- Warning emails are sent to the Host roughly 7 days and 1 day before deletion, so nothing disappears without notice.
- If paid subscriptions are enabled and the Host subscribes, the expiry moves forward for as long as the subscription is active. If the subscription lapses, the Event returns to the expiry countdown.
8.2 Three honest exceptions
(a) Some Events never expire. Events that were created without an expiry value — this includes Events created by earlier versions of the apps — have no expiry date recorded, and the cleanup job will never delete them. They are kept until the Host deletes them or asks us to. [PLACEHOLDER — product decision required: whether to backfill a 37-day expiry onto those Events, or to state here that they are kept indefinitely. This policy must be updated to match whatever is decided. See §12.]
(b) Deleting an Event does not currently remove every copy of a video. When a whole Event is deleted — by the expiry job, or by a Host deleting it in the iOS app — the database records go, and the original files are removed from storage by the expiry job. But a transcoded copy held by our video delivery provider may survive, and an Event deleted from inside the iOS app currently leaves both the original file and the transcoded copy behind. We are fixing this. Until it is fixed, we will not claim that deleting an Event erases every copy. [Engineering: this is tracked in the project's TODO under "cost hygiene" and in the migration notes. This paragraph must be rewritten the moment it is fixed.]
(c) Deleting a single message is thorough. When a Host deletes one Message, our server removes the stored original file first, then the transcoded copy at our video provider, then the database record — in that order, so a failure part way through can be safely retried rather than silently leaving the file behind. This is the deletion path we would use to satisfy an erasure request today.
8.3 Everything else
| Data | Kept for |
|---|---|
| Host account, profile, notification settings | Until the account is deleted (see §9 and the caveat there) |
| Push notification token | Until the device is unregistered or the account is deleted |
| Guest name, optional email, written note | Life of the Event (see §8.1–8.2) |
| Message media | Life of the Event, or until the Host deletes the individual message |
| IP address + device identifier in the upload ledger | Life of the Event — these rows are deleted when the Event is deleted. They are not otherwise pruned. |
| Notification/digest queue records (host ID, event ID, guest name) | Life of the recording they refer to |
| Billing records | As long as required by tax and accounting law — [PLACEHOLDER — confirm: retention period, typically 6–7 years] |
| Support emails | [PLACEHOLDER — confirm: retention period] |
| Server and security logs at our hosting providers | Per each provider's own retention schedule — [PLACEHOLDER — confirm the actual windows for Vercel, Supabase, Cloudflare] |
| Database backups | [PLACEHOLDER — confirm: Supabase backup / point-in-time-recovery window. Deleted data persists in backups until they roll off.] |
9. Your rights, and how to actually use them
Depending on where you live you may have the right to:
- Get a copy of the personal data we hold about you, and information about how it is used.
- Correct it if it is wrong.
- Delete it.
- Restrict or object to how we use it, including objecting to processing based on legitimate interests.
- Take it with you in a portable, machine-readable format.
- Withdraw consent at any time, without affecting what happened before.
- Not be discriminated against for exercising these rights (California).
- Complain to your data protection regulator. In the UK that is the Information Commissioner's Office; in the EU it is your national supervisory authority.
Under the CCPA/CPRA, California residents also have the right to know what is collected and why, to delete, to correct, to opt out of sale or sharing (we do neither), and to limit the use of sensitive personal information. You may use an authorised agent.
How to make a request.
- If you are a Host: email [PLACEHOLDER — confirm: contact email]. You can also delete individual messages and Events yourself inside the app.
- If you are a Guest and you want your message removed: email [PLACEHOLDER — confirm: contact email] with the Event name or link and the name you used. You do not need an account. You can also ask the Host directly — they can delete your message with two taps. If you contact us, we will remove it, and we will tell the Host that a message was removed at the recorder's request.
- We will respond within 30 days (extendable where the law allows, and we will tell you if we need longer). California requests: within 45 days, extendable to 90.
- We may need to ask you for enough information to be confident the request is really yours. For a Guest deletion request, the Event and the name on the message are normally enough.
Because the Host controls their Event's content, a request about a Message may be one we forward to that Host as their processor. Where the law places the obligation on the Host, we will help them meet it, and we will act ourselves where we must.
Account deletion — important gap. [PLACEHOLDER — engineering + product, blocking for both app stores: the current build has no in-app "delete my account" function.] Apple requires apps that support account creation to offer account deletion in the app, and Google Play requires an in-app path plus a web-accessible request path, with deletion of the associated data. Until that ships, account deletion is by email request only — and this policy must not promise more than that. Once it ships, replace this paragraph with a description of where the button is and what it removes.
10. How we protect it
- All traffic runs over encrypted connections (HTTPS/TLS).
- Guest Messages live in a private storage bucket. Guests cannot upload directly; every upload must first be authorised by our server, which issues a one-time upload link, chooses the file location itself, and enforces size, format, and volume limits.
- Our database uses row-level security so a Host can only ever read their own Events, and every guest write goes through a server function rather than directly from a browser or phone.
- Passwords are stored only as hashes by our authentication provider.
- Billing details never touch our servers.
No system is perfectly secure, and we cannot guarantee absolute security. If we suffer a breach affecting your personal data, we will notify you and the relevant regulators as required by law. [PLACEHOLDER — confirm: incident-response contact and notification process; GDPR requires regulator notification within 72 hours of becoming aware.]
11. Cookies and local storage
We use very little.
- Session cookies so you stay signed in as a Host. Strictly necessary — the site cannot work without them.
- Local storage on the guest recording page to hold the random device ID described in §2.2, so repeat messages group together and abuse limits work.
- No advertising cookies, no analytics cookies, no third-party trackers.
Because none of this is used for advertising or analytics, we do not display a consent banner. [PLACEHOLDER — confirm with counsel: whether the ePrivacy Directive / PECR "strictly necessary" exemption covers the guest device identifier in local storage, or whether a consent notice is required for EU/UK visitors. The identifier is used for security and abuse prevention, which is a strong exemption argument, but it should be confirmed rather than assumed.]
12. Changes to this policy
If we change how we handle data, we will update this page and change the "last updated" date. For material changes we will tell Hosts by email or in the app before the change takes effect. Because the Service's behaviour is defined by its code, we also commit to reviewing this policy whenever a data practice changes — in particular the retention rules in §8.
13. Contact
[PLACEHOLDER — confirm: legal entity name] [PLACEHOLDER — confirm: business address] [PLACEHOLDER — confirm: privacy contact email] [PLACEHOLDER — confirm: whether a Data Protection Officer is appointed and, if so, their contact details. A DPO is likely not mandatory under GDPR Art. 37 for this scale, but counsel should confirm given the nature of the content.] [PLACEHOLDER — confirm: EU and/or UK representative under GDPR Art. 27, if offering the Service to people in those regions.]
Not legal advice
This document is a draft prepared from the application's actual source code by a non-lawyer. It has not been reviewed or approved by an attorney. It must be reviewed and approved by a qualified attorney licensed in [PLACEHOLDER — confirm: governing jurisdiction] — and, if the Service is offered in the UK/EU, by someone competent in UK/EU data protection law — before it is published, linked from an App Store or Google Play listing, or relied on by anyone.