Privacy policy

Privacy Policy - Loup Frères

PRIVACY POLICY – LOUP FRÈRES

1. Data Collection and Local-First Architecture

Loup Frères employs a strict "Local First" architecture. All prompts, generated text, character cards, and user logs are processed via your localized API connection and saved exclusively to your local hard drive. We do not log, intercept, or host your narratives. With the single exception of files that a user chooses to publish to the Character Kitchen, described in Section 3, we do not store information provided by you on our servers and we do not act as a hosting service.

Because you are utilizing a 'Bring Your Own Key' architecture, your prompts and text generations are transmitted directly from your local device to whichever AI provider you have chosen to configure — which may include Google Gemini, OpenAI, Anthropic (Claude), OpenRouter, NanoGPT, a custom OpenAI-compatible endpoint of your own specification, or a local backend running on your own machine. We do not intercept, route, proxy, or view this data. The processing of your prompts by any such provider is governed entirely by that provider's own Privacy Policy and Terms of Service, which you are responsible for reviewing. Where you elect to use a custom or self-hosted endpoint, your data is sent to a destination you have chosen, at your own risk; where you elect to use a local backend, your prompts are processed on your device and are not transmitted off it.

Knowledge-Graph Embeddings: Independently of your selected chat provider, the Application's local memory and knowledge-graph features generate text embeddings using a third-party embedding provider that you select separately under Settings → Providers & Keys. Google Gemini is the default; you may instead direct embeddings to another supported provider or to a custom OpenAI-compatible endpoint of your own specification. Consequently, text passages used to build your local knowledge graph — and, where a message carries images, those images — are transmitted to whichever embedding provider you have configured and processed under that provider's Privacy Policy, even if your conversations are routed elsewhere. Embeddings cannot be generated on your device: selecting a local chat backend does not stop this transmission.

Web Search and Lore Research: The Application includes optional features by which a character may search the open web during a conversation, and by which you may research a subject in order to generate lorebook entries. Both are switched off by default and neither transmits anything unless you enable it. Where you do, the following leaves your device: the search text itself, which is composed by the AI from the conversation and may therefore reflect its subject matter; and, for lore research, the subject and any direction you type. These are transmitted to whichever search-capable provider you have configured — Google Gemini, xAI, Anthropic, OpenRouter, or, on desktop, the Claude Code command-line tool signed in under your own account — and are processed under that provider's Privacy Policy and Terms of Service. That provider may differ from the one handling your conversations: where your chat model cannot search for itself, the Application performs the search using a separate provider you select under Settings, and the search is billed to that provider's key. The provider that will be used is named to you in plain language on the Live Chat settings page before you enable the feature. Search results returned to the Application are stored locally with the conversation in the ordinary way. No search capability exists on a local backend; selecting one does not prevent this transmission, it means the search is performed by the separate provider you configured, or not at all.

2. Licensing Data (UUID vs. Fingerprinting)

To fulfill the EULA and manage update distribution, our validation servers collect the following minimal authentication data, and nothing more:

Your License Key: To verify your subscription status.

Your Patreon Integration ID: To link your subscription status from Patreon.

Your Device UUID: A unique, anonymized mathematical placeholder generated per-device by the Application.

Publisher Status: Where you publish to the Character Kitchen, a record that your publishing identity (your License Key, identified by your Patreon Integration ID or otherwise by a one-way hash of the key; the hash of your Patreon account identifier; or the hash of your Device UUID, as Section 3 describes) may publish, together with the public name you choose, whether you are a Cook or a Chef, and the count of removals described in Section 3. See Section 3.

We explicitly DO NOT use hardware fingerprinting. Your UUID is not tied to your MAC address, IMEI, IP address, device data, or geolocation. It cannot be used to deanonymize you. If the Application is wiped or uninstalled, the UUID is permanently reset. A subsequent reinstallation using the same License Key is technically logged as an installation upon a "new" device. This is our deliberate trade-off for your privacy. Signing out removes the License Key from the device you sign out on, but does not release that device's slot: a slot is released 30 days after its device was last used. The holder of a License Key may also remove their other devices once every 30 days (for a Patreon key, after verifying the Patreon account), and a device count reset can be requested through our support channels. This minimal data is processed strictly under Article 6(1)(b) (Performance of a Contract) and Article 6(1)(f) (Legitimate Interests) of the GDPR to enforce our three-device limit and prevent software piracy.

3. The Character Kitchen

The Character Kitchen is an optional, in-app catalog of character and world files that users ("Publishers": Cooks, who are anyone who enrolled, and Chefs, whom the Provider approved) have chosen to publish. Nothing described in this Section happens unless you open the Character Kitchen or the Application's welcome screen shows you its shelf of recent Kitchen characters (which fetches the catalog and those characters' preview pictures exactly as browsing does), sign in to it, or publish to it.

Browsing: When you open the Character Kitchen, the Application retrieves the catalog, preview images and page text from storage operated for the Provider by Cloudflare, Inc. Like any request over the internet, this discloses your IP address to Cloudflare, which processes it under its own Privacy Policy; the Provider neither receives nor stores it. Browsing sends no identifier of yours and nothing about your own characters or conversations.

Downloads, Hearts, and Reports: When you download a file, leave or remove a heart, or report a page, the Application sends your Device UUID (the same per-device placeholder described in Section 2) to the Provider's server. The server stores only a keyed, one-way hash of it, never the UUID itself, and uses that hash for three purposes only: to count each download once per device, to allow a heart only from a device that downloaded the file, and to accept one report per device per page. The hash cannot be reversed into your UUID. You should know, however, that because the Provider also holds the Device UUIDs attached to each License Key for licensing purposes, the Provider is technically able to associate Character Kitchen activity with a License Key where the device is a licensed one. The Provider does not do so except where necessary to investigate abuse of the Character Kitchen or a breach of the EULA. Your IP address is used by the server only to limit the rate of requests and is never stored. Download and heart counts are shown publicly on each page as totals only.

Reports: A report consists of a reason you choose from a fixed list and an optional note you write. It is stored on the Provider's server until a moderator resolves it and for 180 days afterwards, and a notification of it is delivered to a private channel operated by the Provider via a Discord webhook, so that the report is also processed by Discord Inc. as a sub-processor under Discord's own Privacy Policy. Please do not put personal data in a report note.

Automatic hiding: A Cook's file that receives several reports for sexual content involving minors or for illegal content, from devices that downloaded it, is hidden automatically until a moderator reviews it. The decision uses only the report reasons and the download records described above.

Publishing without a License Key: If you publish without a License Key, your publishing identity is, for as long as the Provider allows it, the keyed, one-way hash of your Device UUID described under Downloads, Hearts, and Reports above, and the Application stores on your device a note that it has enrolled. With every request to the Character Kitchen that carries your Device UUID, the Application also sends a random token generated once for this installation and kept on your device. Where you publish under your Device UUID, the server stores a one-way hash of that token with your profile, never the token itself, so that only this installation can change the profile. The Provider may require a Patreon sign-in instead, at any time, and the Application tells you when it does. You may also sign in by choice, so that your public name survives a reinstallation, which resets the Device UUID. If you later add a License Key on an installation that holds that note, the Application also sends your Device UUID and that token with every request it makes to the Character Kitchen with the License Key, for as long as it holds the note. The first time such a request reaches the server while the License Key has no profile of its own, the server moves your profile, with your public name and the files you published, from the Device UUID hash to the publishing identity of the License Key, unless the profile is tied to the token of a different installation; any withdrawal of the right to publish recorded against the device hash extends to the License Key's identity, and the device hash stays linked to the profile. Once the License Key has a profile, the server no longer uses the Device UUID sent with it.

Signing in: To sign in you use a Patreon account. You do not need a pledge, and no subscription is created. Patreon asks you to authorize the Provider's application, and then tells the Provider's server the identifier of your Patreon account; the server asks Patreon for nothing else, and in particular does not receive or store your name, email address or pledge status through this sign-in. The server stores a keyed, one-way hash of the identifier, which cannot be reversed into it, as your publishing identity, and issues your device a Kitchen pass, of which it likewise stores only a hash. Where you sign in from a device that already publishes under its Device UUID hash, the profile and its files move to the Patreon identity, any withdrawal of the right to publish recorded against the device hash extends to it, and the device hash stays linked to it. A pass is deleted when you sign out on that device, when it goes unused for a year, when you erase your profile, or when your right to publish is withdrawn. Where the Provider also holds a License Key for the same Patreon account, the two are linked as one publishing identity.

Publishing: If you are a Publisher, the following is stored on the Provider's infrastructure and shown to every user of the Application: your public name, biography and picture as you enter them, whether you are a Cook or a Chef; each file you publish and the preview images, page text and version notes the Application derives from it; and the download and heart counts of each. Your publishing identity is recorded as your Patreon Integration ID, as a one-way hash of your License Key, as the hash described under Signing in, or as the Device UUID hash described under Publishing without a License Key; none is shown to other users. Publishing, updating, unlisting, deleting, moderation and enrollment actions, including your confirmations that you are 18 or older and have read the rules, are recorded in an audit log that names your public name and is kept for one year. Content you publish remains stored until you unlist or delete it within the Application, or the Provider removes it under Section 7 of the EULA; copies that other users downloaded before then remain on their devices.

Moderation records: Where a moderator hides your content, the reason they give is stored with it and shown to you. Where a removal is counted against you, the count is stored with your profile. Where your right to publish is withdrawn, the Provider stores the publishing identities it applies to, the reason, any note the moderator wrote, your public name at the time, who decided it, when, and until when. This record is kept for as long as the withdrawal lasts, indefinitely for a permanent one, and survives the erasure of your profile, so that it can be enforced. Where the Provider believes published content constitutes a criminal offence, it may disclose the content and the records it holds about its Publisher to law enforcement or judicial authorities, as the law requires or permits.

Where it is stored: The Character Kitchen runs on Cloudflare, Inc. infrastructure (Workers, D1 and R2) in Cloudflare's Western Europe region. Cloudflare acts as the Provider's sub-processor under its data processing terms.

Legal bases: The Provider processes a Publisher's identity, sign-in and published content under Article 6(1)(b) GDPR (performance of the publishing arrangement between the Publisher and the Provider); download, heart, abuse-prevention and moderation data, including records of withdrawn publishing rights, under Article 6(1)(f) GDPR (the Provider's legitimate interest in operating an honest, abuse-resistant catalog and in keeping out those it has excluded); reports under Article 6(1)(a) GDPR, your consent, given each time you choose to send one; and disclosures to authorities under Article 6(1)(c) GDPR where the law requires them.

4. Diagnostic Data and Bug Reports

The Application includes an optional, manually-initiated bug reporting feature. This feature is strictly opt-in: no diagnostic data is ever transmitted unless you personally open the report screen, write a description, and submit it. Nothing is sent automatically or in the background.

When you submit a bug report, the following information is transmitted: the application name, version, and build number; your operating system name and version; your device locale; a timestamp; and the description you typed. If, and only if, you leave the "attach debug log" option enabled, recent runtime and background execution logs are also attached to help diagnose the fault. Before any log leaves your device, API keys, bearer tokens, and similar secrets are automatically stripped from it by the Application, and attached logs are size-capped. Be mindful that these logs may contain your prompts and chat history.

Device Specifications: The Application also records a short description of the machine it is running on — device manufacturer and model, chipset or processor, processor core count and instruction set, total and available memory, total and free storage, operating system version, screen resolution, and locale. This is retained locally in the Application's own crash log and is transmitted only as part of a bug report you choose to submit. Its sole purpose is to make a fault diagnosable: without it, a report that the Application was closed by the operating system for memory pressure cannot be distinguished from ordinary behavior on a memory-constrained device. Memory and storage totals are deliberately rounded, and this description expressly excludes serial numbers, IMEI, advertising or Android identifiers, MAC addresses, hardware UUIDs, computer or user account names, and any other value capable of identifying a specific machine or person. It therefore describes a class of device rather than yours in particular, consistent with our commitment above not to employ hardware fingerprinting. This collection is enabled by default and may be switched off at any time under Settings → Report a Bug, where the exact text that would be sent is displayed to you in full before you send anything.

Memory Usage: The Application also records how much memory it is itself using while running, together with a count of what it is holding open at that moment — how many conversations are loaded, how many messages that amounts to, how large its picture and log caches have grown, and how many records exist in its local database. On Android this includes the operating system's own breakdown of that figure. These readings are sizes and counts only: they contain no message text, no conversation or character names, no file names, and no identifiers of any kind. They are written to a log file held on your device, which is transmitted only if you attach it to a report you submit, and a short summary line accompanies any report you send. Their sole purpose is to establish whether the Application was closed by the operating system because it had grown too large or simply because the device needed the memory — a distinction the operating system's own record cannot make on its own. A reading is taken when you press the capture control, when the Application is sent to the background, when the operating system reports that it is short of memory, and — only where doing so would record a new maximum for the current session — after a conversation turn completes or a conversation is opened. No reading is taken on a timer. This collection is enabled by default and may be switched off at any time under Settings → Report a Bug, where the exact text that would be sent is displayed to you in full before you send anything; switching it off also stops the readings being recorded on your device at all.

Fault Records: When the Application closes unexpectedly, it records why. On Android this includes the internal error and the position within the Application's own program code at which it arose (a "stack trace"), the name of the internal task that was running, and whether the Application was on screen or in the background at the time. It also keeps a short trail of its own recent background activity — which scheduled internal task woke up, and when. This trail names internal tasks only: it contains no message text, no conversation or character names, and no identifiers. Separately, where the operating system itself captured a low-level record of a failure occurring inside a system or third-party component, that record is retained as the operating system supplied it; such a record is produced by the operating system rather than the Application and may contain fragments of the Application's working memory at the moment of failure. All of these are written to files held on your device. They are transmitted only as part of a report you choose to submit, and they are size-capped. Records kept as text pass through the same automatic stripping of API keys, bearer tokens and similar secrets described above. Binary records cannot be stripped in that way and are attached exactly as captured: the operating system's record described above and, on Windows, the memory dump the Application writes when it closes unexpectedly, which may likewise contain fragments of the Application's working memory at the moment of failure. Their sole purpose is to make a fault diagnosable: without them, the operating system's own record states only that the Application closed unexpectedly and gives no indication of the cause.

Optional Contact Address: The Application provides an optional field in which you may enter an email address so that the Provider can ask you follow-up questions about a fault you have reported. This field is empty by default, is never populated on your behalf, and is used for no purpose other than corresponding with you about the report you submitted. It is stored locally on your device, is transmitted only with reports you submit while it is filled in, and may be erased at any time using the adjacent Clear control. You are under no obligation to provide it, and a report submitted without one is processed in exactly the same way. Where you supply an address, we process it on the basis of your consent under Article 6(1)(a) GDPR, which you may withdraw at any time by clearing the field.

Bug reports are sent to a server operated by the Provider on Cloudflare (named as a sub-processor in Section 3), which relays them to a private channel operated by the Provider on Discord. As a result, the data you submit is transmitted to and processed by Cloudflare, Inc. and Discord Inc. as sub-processors, and is subject to their own privacy policies in addition to this one. The Provider's server keeps no copy of a report and does not read your License Key or Device UUID from it. Where that server is unavailable, the Application instead hands the report to your operating system's standard share sheet, so that you remain in control of how and to whom it is sent.

For the avoidance of doubt, a bug report does NOT include your License Key, your Device UUID, or any other persistent user or device identifier, and does not include an email address unless you have personally chosen to enter one in the optional contact field described above. We process this diagnostic data on the legal bases of your consent under Article 6(1)(a) GDPR — given afresh each time you choose to submit a report — and our legitimate interest in diagnosing and fixing software faults under Article 6(1)(f) GDPR. It is used solely to investigate the issue you reported.

5. The Right to Erasure and Friendly Fraud Defense

Under Article 17 of the GDPR, data subjects possess the right to obtain the erasure of their personal data without undue delay (the "Right to be Forgotten"). You may request the deletion of your licensing data at any time.

Publishers may delete any of their published entries at any time from within the Application (My uploads → Delete). Deletion removes the file, its previews, its page and its counts from the Provider's infrastructure without undue delay, save for the audit record described in Section 3 and copies that other users had already downloaded. Once every entry is deleted, a Publisher may erase their profile from within the Application (My uploads → Remove my profile), which removes their public name, biography, picture and sign-ins; the audit record, and any record of a withdrawn right to publish, remain as described in Section 3. A request to erase Character Kitchen activity data associated with your device may be made through the contact address in Section 6.

However, to combat first-party misuse and "friendly fraud" (chargeback fraud), Loup Frères explicitly invokes the statutory exemption provided under GDPR Article 17(3)(e). Upon receipt of an erasure request, we reserve the absolute right to retain your Device UUIDs, License Keys, and license activation timestamps for the maximum duration of the applicable financial statute of limitations, specifically for the establishment, exercise, or defense of legal claims regarding payment disputes. All such retained data is stored securely and solely accessed for dispute resolution.

6. Contact Information

If you have any questions regarding this Privacy Policy, or if you wish to exercise your data rights, you may contact Saint Aurelius of Loup Frères directly at:

Email: [contact@loupfreres.com]