Privacy notice

Supabase Auth and Postgres

Purpose: account, authentication, subscription and learning persistence

Data: account identifiers, email, sessions, learning activity and billing state

Role: configured infrastructure provider

Legal basis: Contract performance and legitimate interests in secure service operation

Recipients: Supabase as authentication and database processor

Transfers: Provider locations and safeguards described in the Supabase data processing terms

Retention: Account lifetime plus deletion, fraud, tax and legal retention periods

Rights: Access, correction, export and deletion through account controls or support

OAuth providers through Supabase Auth

Purpose: optional OAuth sign-in (Google on Faust; Apple when enabled; GitHub retained for other products)

Data: OAuth account identifiers and the profile data returned by the selected provider

Role: identity provider selected by the account holder; Supabase handles the callback

Legal basis: Contract performance when the user chooses OAuth sign in

Recipients: The OAuth provider selected by the user

Transfers: Provider locations and safeguards in the selected provider terms

Retention: Account lifetime and provider controlled retention

Rights: Disconnect the provider and exercise account data rights through support

Stripe

Purpose: Checkout, recurring billing, receipts and Customer Portal

Data: purchaser identity, address, payment and subscription identifiers

Role: payment and billing provider

Legal basis: Contract performance and legal obligations for billing records

Recipients: Stripe as payment processor

Transfers: Stripe locations and safeguards described in its data processing terms

Retention: Subscription lifetime plus statutory accounting, dispute and fraud periods

Rights: Billing access, correction and cancellation through Stripe Portal or support

Resend

Purpose: authentication, billing and durable contract/action confirmations

Data: email address, message content and delivery metadata

Role: configured email provider

Legal basis: Contract performance, legal obligations and secure account operation

Recipients: Resend and its delivery infrastructure

Transfers: Resend locations and safeguards described in its data processing terms

Retention: Delivery logs for operational, legal and abuse prevention periods

Rights: Email and account rights may be exercised through support

AI model providers selected by feature

Purpose: chat, marking, image generation and generated practice

Data: user prompts, uploaded practice content, tool inputs and generated outputs

Role: OpenAI, Anthropic, Google, Groq or AWS Bedrock/Anthropic is called only for the selected model and configured request

Legal basis: Contract performance when the user requests an AI practice feature

Recipients: Configured AI model providers acting under provider terms

Transfers: Provider locations and contractual safeguards configured for the selected model

Retention: Provider request retention plus Faust account and learning retention periods

Rights: Avoid optional AI features or request access and deletion through support

ElevenLabs

Purpose: speech-to-text for the speaking room and text-to-speech for listening and proctor audio

Data: the audio a candidate records in a speaking room, the exam or proctor text to be spoken, and the requested language and voice settings

Role: sole speech provider; recorded speaking audio is sent to it for transcription and the returned transcript and generated audio are stored with the session

Legal basis: Contract performance when the user starts a speaking or listening feature

Recipients: ElevenLabs as the sole configured speech provider

Transfers: Provider locations and contractual safeguards for the selected voice service

Retention: Transient processing plus bounded account and learning result retention

Rights: Do not submit voice audio or request access and deletion through support

Language reference services used by the chat toolkit

Purpose: dictionary, etymology, pronunciation, frequency, thesaurus and grammar-check lookups requested during chat

Data: only the word or text passage the lookup is performed on, plus the requested language; no account identifier, session identifier or authentication header is sent

Role: LanguageTool, Wiktionary, Wikimedia Commons, DWDS, OpenThesaurus and the Free Dictionary API are public endpoints called per lookup

Legal basis: Article 6(1)(b) GDPR: performing the chat tutoring the account holder asked for. The lookup only happens when the account holder requests a dictionary, etymology, pronunciation, frequency, thesaurus or grammar-check result.

Recipients: LanguageTool, Wiktionary, Wikimedia Commons, DWDS, OpenThesaurus and the Free Dictionary API, each called as a public endpoint for the single lookup requested. No account identifier, session identifier or authentication header is sent.

Transfers: LanguageTool, DWDS and OpenThesaurus are operated in the EU. Wiktionary, Wikimedia Commons and the Free Dictionary API may be served from outside the EEA. Only the word or passage looked up is sent, with no identifier attached to it, so no personal data is transferred by the request itself.

Retention: Faust stores no record of the lookup. The request is made, the result is shown in the chat, and nothing about the lookup is written to the Faust database.

Rights: Access, rectification, erasure, restriction, portability and objection under Articles 15 to 21 GDPR are exercised against Faust at the complaint contact below. Because no identifier is sent, these lookups hold no personal data at the reference services to exercise them against.

Faust first-party aggregate funnel measurement

Purpose: measuring which acquisition channels and product steps lead to practice, signup and paid activation so Faust can improve conversion and advertising relevance

Data: a closed coarse acquisition channel may be attached to an existing profile, guest identity or learning session; event occurrences are reduced at write time to a UTC day, templated route, external or unknown traffic class, closed product, level, plan, interval, surface, outcome and experiment values, and an aggregate count. Landing URLs and referrers are inspected only transiently to select the coarse channel. No IP address, user agent, full URL, query value, referrer, click or campaign identifier, analytics visitor identifier, account, guest or session identifier, email, answer, prompt, content or free text is stored in the aggregate

Role: processed by Faust in its own Supabase database with no analytics or advertising recipient; internal and test-channel traffic is excluded and no browser measurement storage is created

Legal basis: Article 6(1)(f) GDPR: Faust has a legitimate interest in understanding whether acquisition and the core product path work, preventing internal tests from distorting decisions, and improving advertising relevance. The processing is limited to closed coarse values, aggregate counts and one-time milestone receipts, uses no analytics visitor identifier or browser measurement storage, and excludes internal and test-channel traffic.

Recipients: No analytics or advertising recipient. Faust processes the coarse actor fields and aggregate counts in its own Supabase Postgres instance; Supabase is already identified as the configured infrastructure processor.

Transfers: No transfer beyond the Supabase infrastructure and safeguards already stated for the Supabase data flow. Raw landing URLs, referrers and click identifiers are not forwarded to Supabase or another measurement provider.

Retention: Daily aggregate cells and their daily ingest counters are automatically deleted after 24 months. A coarse acquisition channel and one-time signup or paid-activation receipt remain only for the lifecycle of the existing profile, guest identity, learning session or subscription to which they belong.

Rights: Access, rectification, erasure, restriction and objection under Articles 15 to 18 and 21 GDPR are exercised against Faust at the complaint contact below. Article 21 objection is available because this flow rests on legitimate interest.

PostHog EU Cloud

Purpose: consented product-funnel analytics with automatic click, heatmap, dead-click, web-vital and error capture, plus session replays of a sampled minority of advertising landings, for finding usability and conversion problems

Data: external visitors only: pseudonymous browser and session identifiers, page paths carrying campaign parameters and page-variant parameters but no other query values, referrer path, device/browser facts, automatically captured element text and interaction geometry, named funnel events, web-vital and error events, and an opaque account UUID after sign-in; every input field is masked and no network bodies, headers, console logs, canvas content, learner answers or chat text are sent

Role: EU analytics processor at eu.i.posthog.com; replay never runs on account, auth, billing, chat, checkout, login, payment, register, settings, tutor, unlock or writing routes; Faust currently presents no analytics choice during normal browsing, so the SDK loads only when an existing valid consent choice is present and only for traffic classified as external

Legal basis: Article 6(1)(a) GDPR: optional product analytics and replay run only after the visitor actively accepts analytics and advertising. Withdrawing or clearing that choice stops future collection.

Recipients: PostHog EU Cloud at eu.i.posthog.com acts as the product-analytics processor. It receives only the categories in the code data-flow registry and never receives learner answers, chat text, unmasked page text or form values from this integration.

Transfers: The PostHog project and ingest endpoint are in the EU region. Any support or subprocessor access outside the EEA is governed by the PostHog data-processing terms and their documented transfer safeguards.

Retention: Browser analytics state expires after 180 days. Faust must configure raw product events for no more than 12 months and session replays for no more than 30 days, then delete or aggregate them.

Rights: Consent may be withdrawn for future processing. Access, erasure, restriction, portability and complaint rights under Articles 15 to 20 and 77 GDPR are exercised against Faust at the complaint contact below.

Google Analytics 4 and Google Ads; Meta Pixel only when configured

Purpose: consented acquisition attribution, aggregate audience measurement and verified signup or purchase conversion measurement

Data: external visitors only: first-party analytics or advertising identifiers, advertising click identifiers, page and referrer paths without query values, browser/device and approximate location data, and named signup or purchase conversion events; no learner answers, chat text or form values are sent

Role: Google and, only when a Meta pixel id is configured, Meta act as measurement or advertising recipients; Faust currently presents no analytics choice during normal browsing, so neither script loads without an existing valid consent choice or for internal or unknown traffic

Legal basis: Article 6(1)(a) GDPR: Google and optional Meta measurement scripts load only after the visitor actively accepts analytics and advertising. Necessary-only visitors are not measured by these providers.

Recipients: Google receives GA4 and Google Ads measurement data. Meta receives pixel measurement data only if Faust configures a Meta pixel id. Neither recipient receives learner answers, chat text or form values from this integration.

Transfers: Google and Meta may process data outside the EEA under their applicable data-processing terms and transfer safeguards. Faust enables the integrations only under an accepted processor agreement.

Retention: The browser cookies expire as stated in the storage table: GA identifiers after 180 days without refresh and advertising identifiers after at most 90 days. User-level analytics data must be configured for no more than 14 months; non-identifying aggregate campaign totals may remain longer.

Rights: Consent may be withdrawn for future processing. Access, erasure, restriction, portability and complaint rights under Articles 15 to 20 and 77 GDPR are exercised against Faust at the complaint contact below.

Guest allowance limits (no third-party recipient)

Purpose: enforcing the free reading paper and chat-turn allowance for signed-out visitors

Data: a first-party guest identifier and a keyed HMAC-SHA-256 hash of the client IP address; the IP address itself is never written to storage

Role: processed by Faust in its own Supabase database and disclosed to no one; the hash is keyed so it cannot be reversed to an address without the server secret

Legal basis: Article 6(1)(f) GDPR: the legitimate interest in stopping one visitor from consuming the free allowance repeatedly. The interest is limited by never storing the address itself.

Recipients: No one. The guest identifier and the keyed hash are processed by Faust in its own Supabase database and disclosed to no third party.

Transfers: None beyond the Supabase Postgres instance already described in the Supabase data flow. The record leaves no other system.

Retention: Kept for the allowance window the limit is enforced over, then deleted. The IP address itself is never written to storage at any point.

Rights: Access, rectification, erasure, restriction, portability and objection under Articles 15 to 21 GDPR are exercised against Faust at the complaint contact below. Objection under Article 21 GDPR is available because this flow rests on legitimate interest.

sb-<project>-auth-token

Purpose: Supabase Auth session. Strictly necessary: without it a signed-in request cannot be authenticated.

Lifetime: until sign-out or session expiry

faust_guest

Purpose: signed httpOnly identifier for a signed-out visitor so the free reading paper and chat-turn allowance can be counted. Strictly necessary for the free allowance.

Lifetime: 400 days

faust_oauth_redirect

Purpose: remembers where to return after an OAuth sign-in or reauthentication round trip. Strictly necessary.

Lifetime: 10 minutes

faust_reauth_challenge

Purpose: binds a pending reauthentication to this session and origin before an account export or deletion. Strictly necessary security cookie.

Lifetime: 10 minutes, or until the challenge is consumed

faust_reauth_grant

Purpose: proof that this session reauthenticated, required to export or delete an account. Strictly necessary security cookie.

Lifetime: 5 minutes; cleared as soon as the operation completes

faust_recovery_proof

Purpose: binds a password recovery link to the browser that opened it. Strictly necessary security cookie.

Lifetime: 10 minutes, or until recovery completes

faust_account_delete_continuation

Purpose: lets an interrupted account deletion resume instead of leaving the account half-deleted. Strictly necessary.

Lifetime: until the deletion completes

faust_coach_tour (and its faust.coachTour localStorage mirror)

Purpose: records that the onboarding coach marks were completed or skipped, so they are not shown again.

Lifetime: 400 days

faust.account.pendingReauth (sessionStorage)

Purpose: holds the export or deletion request across an OAuth reauthentication redirect so it can resume on return. Cleared on use and never sent to a server.

Lifetime: until the browser tab is closed

exam_roster and goethe.examDatePromptDismissed (localStorage)

Purpose: the exam roster a visitor entered and whether they dismissed the request for an exam date, so the countdown works before sign-up and the card asks once rather than after every paper. A signed-in account stores the roster in its profile as well.

Lifetime: until the visitor clears site data

faust_consent (localStorage)

Purpose: records whether the visitor accepted analytics and advertising or chose necessary storage only. Measurement providers read this one shared choice.

Lifetime: until the visitor changes the choice or clears site data

ph_faust_posthog* and faust_posthog_consent (localStorage)

Purpose: after consent only, keeps PostHog pseudonymous session continuity and its local opt-in state. It is never created for internal or unknown traffic.

Lifetime: analytics state expires after 180 days; the opt-in record remains until the choice changes or site data is cleared

_ga and _ga_<id> (first-party cookies)

Purpose: after consent only, distinguishes browsers and preserves Google Analytics session state for aggregate measurement.

Lifetime: 180 days from the first consented visit; it is not refreshed

_gcl_* and _fbp (first-party advertising cookies, when configured)

Purpose: after consent only, attributes an advertising click and a verified signup or purchase to the campaign that brought the visitor.

Lifetime: up to 90 days