Three things first:
| Category | What it is |
|---|---|
| Account | Username, display name, an irreversible password hash, sign-up time, active flag, plan |
| Email address (email route only) | Your email address, used to sign in and to receive the verification code at registration. The other two registration routes store no email address. |
| Third-party sign-in identifier (Google only) | The identifier Google issues for you on this site. It contains no email address and no picture, and it is irreversible — we cannot derive your email address from it. |
| Verification-code records (email route only) | The email address, sha256(address + code), the number of attempts made, whether it was used, and its expiry. The code itself is never written to the database. |
| Quota grants | Kind, amount, source and time of sign-up bonuses and top-ups |
| Your content | Video links you submit or audio files you upload (when you choose a video, only the audio track extracted on your device is uploaded; the video picture never leaves your device); subtitles retrieved or transcribed; translations; summaries; speaker labels; labels you write; your searches. Original uploads and processed results have different retention, described in §§3 and 6 |
| Jobs | Status, time, duration and failure reason for each submission |
| Usage and cost | Type, duration, count and provider-reported cost of each third-party call, used by the operator for cost accounting and quota metering |
| Sign-in records | The time and method of each sign-in (password / Google / email sign-up) and whether it succeeded. No IP address and no browser details are recorded. A failure is recorded only when the account actually exists — whatever you mistype into the username box is never stored. The operator uses this to tell whether an account is still in use and whether someone is guessing passwords; kept for 90 days |
| Traffic statistics | An anonymous browser identifier, page category, referring host name, active time (see §7) |
| Campaign arrival counts | How many times pages were opened from links with controlled campaign labels, summed per hour and normalized label combination; no cookie, IP address, visitor or visit ID (see “Campaign arrival counts” below in this section) |
| Purchase funnel counts | How many times signed-in users opened a processing confirmation or the plans page, or submitted a task using purchased credits, summed per hour and fixed category; no account, video or amount (see “Purchase funnel counts” below in this section) |
| IP and email address for rate limiting | Both are used only as keys of a rate-limit counter in Redis, and only as the first 32 hex characters of a SHA-256 digest. They expire after 120 seconds and are never written to the database. |
| Notify-me address | Only when you type it into the “Top-up pack · in the works” box: the email address and the interface language. Used only to send one message when that feature opens; not linked to an account, not used for anything else; email us to have it removed |
| Collection counters while signed out | A hash of your IP (IPv6 grouped to /64) as the key for "how many new videos you can still process today". It expires after 26 hours and is never written to the database. |
When a page of this site is opened from an address with controlled campaign labels (utm_source, utm_medium, utm_campaign, utm_content), the server adds one to the current hour's count for the normalized label combination (only the fixed values; anything else is counted as other). Browser navigations are counted separately from other requests such as link previews, crawlers and prefetch. This count is kept for every visitor by default. It sets or reads no cookie, writes nothing to browser storage, and stores no IP address, visitor or visit ID, full address or other query parameter. It shows only how many times each campaign link was opened, cannot be tied to a person, and is not linked to traffic statistics or to the optional campaign attribution records below. Requests with a DNT or GPC signal are not counted; because the counts hold nothing about anyone, they cannot be looked up or deleted per person. The hourly counts are kept for at most 90 days.
When a signed-in user opens a processing confirmation (to review the estimated use), opens the “Plans & purchase” page, or submits a task that uses purchased credits or a single pass, the server adds one to the current hour's count, so we can tell whether the free allowances are enough and how many people need to buy more. The counts are summed only by fixed categories: the step, the processing feature (transcription, summary, translation, speaker detection), a reason or outcome category (for example free allowance used up, asset longer than 120 minutes, purchased balance insufficient, first-order price shown), and whether the account is one of this site's internal accounts (administrators and test accounts). No account, video, transcript, amount or order ID is recorded, and the counts are not linked to traffic statistics, campaign statistics or the optional account activity statistics. So that an account counts only once per day, the server hashes the username one way with a random value created for that day; the hash and the random value are kept in the server cache for 36 hours, after which the counts cannot be tied to anyone. The hourly counts are kept for at most 90 days; because they hold nothing about anyone, they cannot be looked up or deleted per person. The administrator dashboard also sums the number and amount of orders, payments and refunds by time, showing totals only, not accounts.
Only after you explicitly enable the separate campaign and conversion option does our statistics script read controlled campaign labels (UTM source, medium, campaign and content) and add them to your visit record. First-touch and current 30-minute session labels are kept in sessionStorage for this tab. We do not store full links or arbitrary query parameters, or put these labels in the statistics cookie. Collection stops when statistics are off or DNT/GPC declines it. Normalized campaign records are retained with visits for at most 90 days. Local browser storage also keeps random consent-state identifiers to enforce withdrawal and synchronize tabs; they contain no account information or link content.
After you accept the current policy and opt in to both campaign and account activity statistics, the server may associate the current visit ID and campaign with authorized activity events to summarize reading, search, export and registration by channel. Reports do not show accounts, raw cookies, IP addresses, transcript or note text, or full links. This association is not created when the option is off.
To diagnose browser security policies, we separately keep daily counts of policy categories and controlled source categories for up to 8 days. We do not retain page addresses, script samples, accounts or query parameters from these reports.
After you explicitly allow campaign attribution, the anonymous visit may record whether registration succeeded, without an account identifier, to measure signup conversion. Linking a visit to account activity still requires separate permission for optional account statistics. Previous statistics choices do not enable the new attribution option.
When traffic statistics are allowed, about 10% of page loads are sampled for LCP, INP and CLS. Only histogram counts grouped by frontend version and device category are retained, for up to 8 days. No page address, account, metric ID or page content is sent. Reports stop when traffic statistics are off or DNT/GPC declines collection. Fewer than 20 samples are not treated as evidence that a target is met.
Separate from anonymous traffic counters, optional account activity statistics use a server-generated HMAC account reference, a minimal video reference, event and operation IDs, controlled action categories, timestamps and a server-assigned subject category. These references are pseudonymous and can link activity within an account; they are not anonymous. No raw video URL, search text, transcript or notes are collected. Authorized visits and account activity may be associated by visit ID only after you opt in to account activity statistics.
Purpose: understand whether reading, quotation delivery and later reuse work. Export delivery means a browser download was initiated or text was copied; it does not prove a file was saved or used. Collection begins only after agreement to the current policy and an explicit optional analytics choice. Turning off traffic statistics also disables account activity collection. DNT and GPC are respected.
Detailed optional events are deleted after 90 days. You may disable collection or delete these events from the statistics controls. Required usage and billing records are separate and are not erased by this optional analytics control. There is no waiting period for this initial rollout. Collection is off by default, and past activity is not backfilled.
When paid products open, we store account-linked order IDs, product and accepted-policy snapshots, the displayed policy language, amounts and currencies, provider payment and refund IDs, payment times, and entitlement reservations and delivery records. A single pass also retains its bound asset identifier and deadlines. These records support fulfillment, payment reconciliation and after-sales service, independently of optional analytics preferences. Waffo checkout and its payment processors handle information needed for payment; Vidleaf does not receive or store full card details. The payment channel receives store, product and random order references, not your transcripts, audio or notes.
Phone number, real name, identity documents, payment card details, precise location, raw User-Agent, contacts, device identifiers. Device class (mobile / desktop) for traffic statistics is decided in your browser and the raw information is not sent back.
Your email address needs saying separately, because it depends on how you registered:
| How you registered | Do we store your email address |
|---|---|
| With email | Yes. It is your sign-in identifier |
| With Google | No. We hold only the irreversible identifier Google issues |
| With an invitation token | No. That route has no email field |
In other words, you can use every feature without ever giving us your email address: register with Google.
This one directly affects what you can delete, so it gets its own section.
Yours alone (invisible to other users): account details, the labels you write, your job list, your usage records, and transcripts, translations and summaries produced from your local audio uploads. Labels are stored per account; different users' labels on the same video cannot see each other.
Shared cache (only for public Bilibili and YouTube videos, keyed per video, not per user): video metadata, subtitle tracks, translations, summaries. Local uploads are keyed by account; two accounts uploading the same file cannot read each other's result. Removing an item from “My tasks” hides the history entry but does not delete a saved upload transcript. Contact support under §8 to request deletion of a processed result.
Three consequences, all stated:
Shared does not mean public. A common pattern among similar products is to publish each video's AI summary on a sign-in-free page that search engines index, reusing the original video's title. Vidleaf does not:
| Common pattern | Vidleaf | |
|---|---|---|
| Reuse across users | Yes | Yes |
| Result page public | Sign-in-free URL | No separate public result page; saved public-video results can be opened through a reader link under guest rules |
| Indexed by search engines | Yes | No |
| Open to AI crawlers for training | Commonly yes | No |
| Cache reuse disclosed | Usually not | This section |
| Takedown route for rights holders | Often none | Terms §12 |
To do what you ask, the following providers receive the corresponding content. Requests carry no account name and no internal user identifier.
| Processor | Purpose | Receives | Destination | Contact |
|---|---|---|---|---|
| OpenRouter | Speech transcription | Original audio files meeting format and size requirements, or transcoded audio segments (16 kHz mono MP3, up to 15 minutes each). OpenRouter does not run models itself: it routes the audio to a model provider — for whisper-large-v3 currently DeepInfra, Together AI or Groq, all in the United States | United States | openrouter.ai/privacy · data collection notes at openrouter.ai/docs/guides/privacy/data-collection |
| pyannoteAI | Speaker detection | The complete audio file (uploaded to their object storage, then submitted as a job) | Europe | pyannote.ai/privacy-policy · retention at docs.pyannote.ai/data-retention |
| DeepSeek | Summaries, translation | Subtitle text, sent in segments | Mainland China | cdn.deepseek.com/policies/en/deepseek-privacy-policy.html |
| Bilibili | Reading subtitle lists | Video link plus a server-held account session (see Terms §8) | Mainland China | bilibili.com/blackboard/privacy-pc.html |
| YouTube | Reading subtitles | The video link only | United States | policies.google.com/privacy |
| Mailtrap (Railsware Products Studio LLC, California) | Sending the registration verification code | Your email address, and the subject and body of that message — the body contains the six-digit code | United States | mailtrap.io/privacy |
| Google (Google LLC) | Google sign-in | When you press "Continue with Google", your browser talks to Google directly: Google sees your IP address, your browser information and the fact that you are on our sign-in panel. Our server only fetches Google's public signing keys, and that request carries nothing about you | United States | policies.google.com/privacy |
Only registration and sign-in involve the last two. Reading subtitles, transcription, translation and summaries never go near them.
Three things worth stating about the Google row:
accounts.google.com/gsi/client) is fetched only when you open the sign-in
panel and Google sign-in is actually enabled. If you are only reading
subtitles and never open sign-in, we do not make your browser contact Google.About the Mailtrap row: it receives your address only if you choose "continue with email", and only that one verification message. It does not receive your password, your content or your usage. How long it keeps that message is in §5.
This is the current default configuration. If you use BYOK, content goes to the provider you configure, governed by your agreement with them.
Exercising your rights with these providers: contact us first (§12) and we will pass on a request to access, correct or delete; or contact them directly using the details above. We will tell you the outcome.
Changing or adding a processor is announced on the site 10 days in advance. If you do not accept a new processor, stop using the corresponding feature or close your account.
Audio leaving your region, stated plainly: transcription and speaker detection both send audio outside mainland China. If you do not want a particular piece of audio to leave, do not use those two features — reading existing subtitles sends no audio at all. For uploaded audio there is no "subtitles only" option: an upload has no platform subtitles, so once you confirm transcription it will be sent to the transcription provider listed above. Do not upload audio you are not willing to send.
We do not know, and we cannot control it. That depends on each provider's own policy and is outside this service. You can read their privacy policies directly. One point deserves separate mention:
OpenRouter receives eligible original audio files or transcoded audio segments. According to its data collection notes, OpenRouter does not store the content sent to it or the model output unless the account turns logging on (we have not), and keeps only request metadata such as duration and token counts. It passes the audio to a model provider; each provider has its own retention policy, which OpenRouter lists per provider on its site. We cannot promise a retention period on their behalf.
DeepSeek receives subtitle text, not audio. Its privacy policy states that data is stored within the People's Republic of China and that, after security processing and de-identification, inputs and outputs may be used to train and improve its models. Requests to it carry no account name.
pyannoteAI receives the complete audio file. For this one we went and read their documentation, so we can give you the actual numbers rather than "it depends on them":
| What they hold | How long |
|---|---|
| The uploaded audio file | Deleted automatically within 48 hours, whether or not a job used it |
| Job results (the speaker segments) | 24 hours after the job completes |
| Audio on the processing servers | Deleted as soon as processing ends |
The source is docs.pyannote.ai/data-retention, which says "automatically deleted
within 48 hours".
We have no way to call a "delete" on their side, because they do not offer one — their design is to expire it on a timer rather than have callers do it. An earlier version of this text said we could not delete it and called that the most worthwhile thing to improve; that was inferred from our own request allowlist without reading their documentation, and it was inaccurate. This is the corrected version.
One more of the same kind, also stated as it is: Mailtrap keeps the verification message, body included, in its sending log, and that body contains the six-digit code. How long depends on its billing tier — per its public pricing page, 3 days on the free tier, 5 on Basic, 15 on Business, 30 on Enterprise.
The practical risk here is smaller than it first looks, and the reason is worth stating: the code itself expires in 10 minutes, so the code sitting in that log is already dead long before anyone could use it. What the log does retain is the fact that this address received a registration message from us at a given time. We state it here anyway, rather than leaving you to go and read a pricing page.
| Data | Retention | After you ask us to delete |
|---|---|---|
| Traffic statistics | 90 days, cleared automatically in batches | Turning collection off stops new records |
| Campaign arrival counts | Summed per hour; expire automatically after 90 days | They hold nothing about anyone, so they cannot be deleted per person; requests with DNT / GPC are not counted |
| Purchase funnel counts | Summed per hour; expire automatically after 90 days; the hashes and random values used to count an account once a day are deleted after 36 hours | They hold nothing about anyone, so they cannot be deleted per person |
| Sign-in records | 90 days, swept on a rolling basis | Deleted when the account is closed |
| Login sessions | 30 days with "remember me", otherwise 12 hours, deleted on expiry | Deleted on sign-out |
| Rate-limit IP hash | 120 seconds | — |
| Cached results | Redis hot cache: 7 days; saved database results are not automatically deleted when that cache expires | — |
| Job state | 24 hours | — |
| Temporary audio on our servers | Deleted as soon as processing ends; it exists only in a temporary directory | — |
| Audio files you upload | Kept for at most around six hours after upload, whether or not it was submitted or transcribed: a successfully transcribed original stays available during that window for speaker detection (which needs the complete audio) and is then cleared by a scan every minute; an original whose transcription failed or was cancelled is deleted at once, and failures are logged and retried. Uploading the same file again restarts the window from that upload; a file already transcribed is not charged again. An outage or storage fault may delay cleanup; a recovery scan follows. The original lives only in a temporary server directory, not in the database or backups. Processed text is stored separately; see §3 | — |
| Your email address (email route) | For as long as your account exists | Deleted on closure; a copy may persist in offsite backups for up to about four weeks (see below) |
| Google sign-in identifier | For as long as your account exists | As above |
| Verification-code records | They expire after 10 minutes; expired rows are deleted the next time anyone requests a code | — |
| Quota grants | For as long as your account exists | Deleted on closure |
| Collection counters while signed out (IP hash) | 26 hours | — |
| Your labels, job records, usage records | For as long as your account exists | Deleted on closure; a copy may persist in offsite backups for up to about four weeks (see below) |
| Subtitles, translations, summaries (shared cache) | For as long as your account exists; we set no deletion date | See §3: not deletable unilaterally; use Terms §12 |
The last row, stated plainly: Vidleaf does not run periodic deletion of business data. Video metadata, subtitles, translations, summaries, labels, job records and call and cost records are kept for as long as your account exists. We would rather not give you a deadline we cannot meet. To have it deleted, use §8.
About "up to about four weeks in offsite backups": the offsite backup keeps,
independently, the latest snapshot of each of the newest seven calendar days
and the latest snapshot of each of the newest four calendar weeks
(deploy/backup/README.md). It deliberately accepts no delete command from the
main site — otherwise compromising the main site would take the backups with it.
The cost of that choice is exactly this: after we delete your data from the live
database, it still exists in those snapshots until newer ones push them out. The
ceiling is therefore the age of the oldest weekly snapshot, about four weeks.
Why the verification-code row is worded so awkwardly: the cleanup happens as part of issuing a code, not on a timer of its own. So the accurate statement is "expires after 10 minutes and is deleted the next time anyone requests a code", not "deleted after 10 minutes". Through a stretch with no registrations at all, the last expired row sits there. Writing "deleted after 10 minutes" would be a falsehood — and it is exactly the kind of falsehood that ends up in a privacy policy.
Three cookies, none for advertising and none shared with third parties:
| Cookie | Purpose | Attributes | Lifetime |
|---|---|---|---|
| Session | Keeps you signed in | HttpOnly, Secure over HTTPS, SameSite=Lax |
30 days / 12 hours |
| Traffic statistics | Distinguishes visitors anonymously | HttpOnly, Secure, SameSite=Lax |
90 days |
| Signed-out access | A random number whose only purpose is to let a job you submitted while signed out be read back by you | HttpOnly, Secure over HTTPS, SameSite=Lax |
30 days |
HttpOnly, so page scripts cannot read it, and it appears in no URL, no
log and no page source. It is not what your quota is counted against —
signed-out quota is counted against a hash of your IP address. A limit counted
against a cookie cannot be enforced in principle: without the cookie, the
server can only issue a new one.accounts.google.com domain rather than ours. Those are governed by Google's
policy; we can neither read nor delete them. As §4 says, that script loads only
when you open the sign-in panel: do not press sign-in and those cookies never
appear.Stated as it is, without promising what we cannot do:
| What you want | Possible today | How |
|---|---|---|
| Change your password | Yes | My account → change password (an account created with Google has no password, so this does not apply) |
| Reset a forgotten password yourself | Yes, for email accounts | Sign-in page → "Forgot password"; we send that address a reset link. Not for Google or invitation accounts: a Google account has no password, and for an invitation account we hold no email address. Email support@vidleaf.app in those cases |
| Change the email address on your account | Manual | As above |
| Unlink Google and switch to a password | Manual | As above. An account created with Google has no password, so one has to be set first |
| Remove a video from "My tasks" | Yes | But this hides, it does not delete — the data stays and simply stops being shown to you |
| Turn off traffic statistics | Yes | Footer → "Traffic statistics" |
| Export your subtitles, translations, summaries and labels | Yes | "Export all" on the reading page |
| Delete all data for a video | Manual | Email support@vidleaf.app |
| Close your account and delete everything | Manual | As above |
| See what we hold about you | Manual | As above |
What we commit to: deletion and closure requests are completed within 15 working days of receipt — your account, labels, job records and usage records deleted, and anything that cannot be deleted anonymised. The public-video shared cache in §3 does not correspond to your account alone; use Terms §12 for its takedown. Local-upload results are account-isolated and included in a manual deletion request. Hiding an item in “My tasks” does not delete the result.
A self-service route is being built. Until it ships, the email route above is the official one and we will not delay or refuse because there is no button.
Vidleaf is not directed to children under 14, and we do not knowingly collect their information. If you are a guardian and find that a child has registered, contact us and we will delete it.
Version 2026-09-30: §3 now describes the “Video submissions” record in the admin dashboard: the operator can see each submitted video link, title, duration and processing result, and whether it was submitted while signed in (a submission made without signing in is shown only as “Guest”); local uploads never show the file name. From 9 October 2026 (Beijing time), a submission made while signed in also shows the account's username, at least seven days after this notice. The kinds of data collected, recipients and retention are unchanged, and the separate audio consent version is unchanged.
Version 2026-09-29.1: Adds purchase funnel counts: when a signed-in user opens a processing confirmation or the plans page, or submits a task using purchased credits, the server counts it per hour and fixed category, without recording the account, video or amount; the one-way hashes and random values used to count an account once a day are deleted after 36 hours, and the counts are kept for 90 days. The administrator dashboard also sums orders, payments and refunds by time. Other data collected, recipients and purposes are unchanged, and the separate audio consent version is unchanged.
Version 2026-09-29: Adds campaign arrival counts: when a page is opened from an address with controlled campaign labels, the server counts opens per hour for every visitor, without a cookie, IP address or visitor ID and without linking them to traffic statistics or optional campaign attribution; requests with DNT/GPC are not counted; the counts are kept for 90 days. The optional campaign attribution section now states that the statistics script reads the labels. Other data collected, recipients and purposes are unchanged, and the separate audio consent version is unchanged.
Version 2026-09-28: Adds a separate, default-off campaign and conversion option, explains visit-to-activity links, signup markers and 90-day retention, and adds sanitized security-policy counts retained for 8 days. The audio notice now covers original audio files meeting format and size requirements as well as transcoded 16 kHz mono MP3 segments of up to 15 minutes each. Recipients and processing purposes are unchanged. Separate audio consent moves to 2026-09-28 and must be renewed before the next transcription or speaker detection.
Version 2026-09-27.1: corrects the processor names in §4. The direct recipient for speech transcription is OpenRouter (United States), which routes audio to a model provider (currently DeepInfra, Together AI or Groq); Groq, named before, is only one of the possible providers. Summaries and translation go to DeepSeek (mainland China), previously misstated as SiliconFlow. Since we began recording third-party calls these two have been the actual recipients, so this is a correction of the notice, not a change of provider. §5 adds their retention notes. Because the audio-recipient notice changed, the separate audio-export consent version moves to 2026-09-27: accounts that consented before will be asked once more before the next transcription or speaker detection. Terms of Service §11 is reworded accordingly. The categories of data, purposes and retention periods are unchanged.
Version 2026-09-27: the English Terms of Service and Privacy Policy now quote interface labels as the English interface shows them (for example “AI-generated”, “Human captions”, “Traffic statistics”) instead of quoting the Chinese labels, and their links back to Vidleaf open the English site. The meaning is unchanged: the kinds of data collected, recipients, purposes, retention and prices are the same, and the separate audio consent version is unchanged.
Version 2026-09-25: §6, “Audio files you upload”: a successfully transcribed original is no longer deleted as soon as its job ends; it is kept for at most around six hours after upload so that speaker detection can use it (previously speaker detection was available only for platform videos). Originals whose transcription failed or was cancelled are still deleted at once. The maximum retention is unchanged (a file never submitted was already kept for at most around six hours); the kinds of data collected, recipients and purposes are the same, and the separate audio consent version is unchanged. Terms of Service: the sentence on speaker detection for local uploads is updated accordingly.
Version 2026-09-24.2: Terms of Service: AAC audio in an m4a file and an AAC audio track extracted on your device from a video are no longer subject to the 60 MiB limit if the average bitrate is at most 320 kbit/s; the per-asset duration limit applies instead. Other audio files remain limited to 60 MiB. An m4a over 60 MiB is first checked on your device, and only its AAC audio track is uploaded. This policy itself is unchanged: the kinds of data collected, recipients, purposes and retention are the same, and the separate audio consent version is unchanged.
Version 2026-09-24.1: uploads are no longer limited to mp3, m4a and wav; common audio formats are accepted. When you choose a video file, its audio track is extracted on your device and only the sound is uploaded; the video picture never leaves your device. The kinds of data collected, recipients, purposes and retention are unchanged, and the separate audio consent version is unchanged.
Version 2026-09-24: adds Pack L, conditional first-order prices and cent-based refund allocations; the account area now separates purchases, orders, usage and security. Orders retain the language and policy accepted at purchase. Previous orders keep their original terms. Audio processors and the separate audio consent are unchanged.
Version 2026-09-23.2: the Terms describe prepared S and single-pass products, their validity and a 14-day refund policy based on unused components. Payment and entitlement records are necessary fulfillment records, separate from optional analytics. Audio processors and the separate audio-export consent are unchanged.
Version 2026-09-23.1: corrects the scheduled cleanup and outage wording for original uploads; clarifies account isolation of processed upload results, that hiding history does not delete results, and that expiration of the Redis hot cache does not erase database results. Current terms must be accepted before new cloud work; the separate audio-export consent version is unchanged because processors, sent data and purposes have not changed.
Version 2026-09-22.1: adds the local audio upload path. Section 1 ("Your content") now names audio files you upload, section 6 states their retention (deleted as soon as transcription ends; an upload never submitted is kept at most 6 more hours), and section 4 states that uploaded audio also leaves mainland China. The list of processors, the purposes and the retention periods are unchanged, so the separate audio-export consent keeps its version and does not need to be given again.
Version 2026-09-20.3: removes the waiting period for the initial rollout of optional account activity statistics. You can opt in after this notice is published; collection is off by default and past activity is not backfilled. This pre-launch update replaces the seven-day wait previously announced for this feature.
Version 2026-09-20.2: introduced optional account activity statistics, their separate storage, opt-in, deletion and 90-day retention.
What changed in v1.2 (2026-09-20): section 1 gained one row, “Sign-in records”; section 6 gained the matching retention line (90 days, swept on a rolling basis); and section 3 now states that the operator can also see per-account sign-in records. What is recorded is the time, the method and whether it succeeded — no IP address and no browser details; a failed sign-in is recorded only when the account actually exists.
What changed in v1.1 (2026-09-19): section 1 gained one row, “Notify-me address” — the email you type into the “Top-up pack · in the works” box on the home page.
Changes update the effective date on this page and are announced on the site.
Changes that widen the use of your data, add a processor or extend retention are
announced at least 7 days before they take effect.
support@vidleaf.app