Privacy Policy

Mubashir Ahmed, c/o flexdienst – #21642, Kurt-Schumacher-Straße 74, 67663 Kaiserslautern, Germany. General contact and privacy inquiries: [email protected]. App support and account inquiries: [email protected].

ZUHD is designed to minimize data use. Sensitive protection and usage data generally stays on your device. Online, ZUHD mainly processes data for your account, sign-in, trial, Premium status, support, GDPR requests, abuse prevention, and progress backup. Depending on the process, the legal bases are GDPR Article 6(1)(b) for contract and pre-contractual steps, Article 6(1)(a) for consent, and Article 6(1)(f) for legitimate interests in security, abuse prevention, and stable product operation. Article 6(1)(c) applies only where ZUHD must fulfil a specific statutory consumer duty in the individual case.

The website is currently provided through Hostinger; Cloudflare is used for DNS, proxy, and protection features. Technically necessary connection data such as IP address, timestamp, user agent, and requested resource may be processed to deliver the site, defend against attacks, and analyze errors. ZUHD itself uses no tracking or advertising cookies and no analytics service on the public website. The brand intro writes no cookies or web-storage values. Where Hostinger or Cloudflare use technically necessary cookies or equivalent terminal signals for delivery and security, those signals are not used for ZUHD's own analytics or advertising. Access to the terminal device occurs only where permitted by section 25 TDDDG, in particular where strictly necessary for a service expressly requested by the user. After a successful sign-in to the partner portal, a technically necessary HttpOnly session cookie with a limited lifetime is stored. It contains a random access token; only its hash is stored server-side. For support and partner forms, Cloudflare Turnstile may temporarily process, in particular, the IP address, user agent, browser and device properties, TLS and security signals, website or host details, challenge result, and challenge token, and may use technically necessary cookies or equivalent signals for that purpose. From the verification response, ZUHD evaluates only success and the expected hostname; the response is not stored as support data. The verification result is used solely for security, rate-limit, and deduplication purposes. The legal basis for the subsequent processing of personal data is GDPR Article 6(1)(f); the legitimate interest is a secure and available website.

If you install ZUHD through Google Play Store or purchase Premium there, Google processes Play account, device, store, and payment data as a separate provider. Premium, purchase verification, restore, and subscription management run through Google Play Billing. ZUHD sends an obfuscated account reference and the purchase proof temporarily to Google and the ZUHD backend for verification. The backend processes, in particular, user ID, product and base plan, purchase and entitlement status, timestamps, order reference, and hashes of current or replaced purchase tokens. Real-time subscription events may also store message ID, subscription identifier, token hash, event status, error status, and timestamps. ZUHD does not receive full card or bank details. The legal bases are GDPR Article 6(1)(b) for providing and restoring Premium and, where required, Articles 6(1)(c) and (f) for billing records, fraud prevention, and system security. If you open a personal ZUHD friend-invitation link while the current app is not yet installed, the ZUHD link endpoint redirects to Google Play without displaying an intermediate page. The invitation's random 256-bit secret is sent to Google Play as an install referrer. It contains no email address, username, message, app, domain, or usage history data. Google processes the referrer together with the store and device data needed for the Play installation under its own retention rules. After installation, ZUHD reads the referrer through the Play Install Referrer API. Until the app processes the technical hand-off in the Friends area, it stores only the secret's SHA-256 digest, the start of the hand-off window, and content-free state locally. The digest and start time remain technically usable for recovery for no more than 72 hours. If process termination interrupts the hand-off first, ZUHD may retrieve the unchanged referrer again only on a later true cold start and within that window. The raw secret remains in memory only; the ZUHD backend continues to store only its SHA-256 digest. Once the Friends area processes the hand-off, the app removes the local digest and time reference. Completing this technical hand-off neither accepts the invitation nor creates a friendship and does not consume the server-side invitation. If the 72-hour window expires first, the digest and time reference can no longer be used for recovery and are physically removed only on the first true cold start after expiry. ZUHD's scoped in-app deletion of local content also removes both values and leaves only a content-free suppression marker against re-entry of the same external referrer. Android “Clear app data”, a full app-data wipe, or a reinstall instead removes the entire local app storage, including that marker. Regardless of the referrer's technical availability, the invitation remains limited to 72 hours and can be revoked. Only a separate explicit acceptance in the Friends area consumes the server-side invitation once and creates the friendship. The legal bases are GDPR Article 6(1)(b) for the deliberately selected invitation function and Article 6(1)(f) for secure hand-off, replay prevention, and abuse protection. To review abuse of time-limited referral rewards, newer app versions also use a separate random identifier for the ZUHD installation. Creating or accepting a friend-invitation link sends it to the ZUHD backend even when push notifications are disabled. It remains locally after sign-out or account switching; deleting local account data or Android app data removes it. For an associated referral campaign, the server stores only a SHA-256 check value scoped to the specific invitation ID and generation, rather than the raw identifier. It is used only for reward-abuse review; a missing or matching value never prevents friendship. The check value remains usable until no later than 90 days after the campaign ends and is then deleted through bounded cleanup runs. Successful qualification, a detected match, or account deletion removes it earlier. This resettable identifier is not reliable evidence of a particular physical device. For a time-limited referral campaign, ZUHD may additionally reuse a random Firebase Installation ID already supplied by the client for enabled push notifications solely for a best-effort check of the related Premium reward. The raw ID is not copied into the referral record. Instead, the server combines it with the identifier of the specific invitation generation to create a SHA-256 check value. If the same observed value is present for the inviter and invitee accounts, only the reward is held permanently for review; different observed values allow the reward check to pass. If the optional value is missing, particularly for compatible V8 clients, only the legacy policy selected for that campaign applies. Under the currently expressly allowed automatic policy, the reward is processed without this signal. The check never blocks or reverses the invitation, acceptance, or friendship. The Firebase Installation ID is supplied by the client, is not confirmed by an attestation service, and can be reset or changed. The comparison is therefore not tamper-proof device or fraud evidence. The invitation-generation-scoped check value is used logically for no more than 30 days and is then removed by bounded cleanup runs; it is also removed when the account is deleted. The legal bases are GDPR Article 6(1)(b) for processing the expressly offered campaign reward and Article 6(1)(f) for bounded abuse prevention and fair reward distribution. Google Play Store's separate installation-protection rule may evaluate device-integrity signals and refuse installation on a device that does not satisfy the integrity requirement configured in Google Play. Google makes and enforces that Store decision; ZUHD receives no detailed device-linked decision record from it. For the currently observational in-app Play Integrity API check, the app requests a short-lived integrity token only for a signed-in user and a specific action. Google receives the token request, app package, time and device signals, and a cryptographic request binding; the internal ZUHD user ID is used only inside that checksum and is not sent to Google as a plaintext account identifier. The app sends the token with a random request ID, action, and context version to a ZUHD Edge Function. That function has Google decode the token and checks only app binding, request binding, and freshness. Optional device, app, licensing, Play Protect, activity, or app-access signals do not result in an account, plan, or feature decision in the current test state. ZUHD neither stores nor logs the raw token or its hash, individual Google verdicts, installed-app categories, or an account-linked security result; the response to the app uniformly confirms observational processing only. The legal basis is GDPR Article 6(1)(f); the legitimate interest is data-minimised verification of integration security and preparation of reliable abuse prevention.

The app processes authentication data, email address, user ID, username, trial status, Premium/entitlement status, purchase status, and account-backed progress data. Signing in with Google OAuth may process the Google account ID, email address, and basic profile data supplied by Google/Supabase, such as name or profile image. To document account creation, ZUHD also stores the version of the accepted terms of use, the version of the acknowledged privacy policy, the confirmation method, a random one-time nonce, and the server confirmation time. Existing account-bound, content-free core progress includes server-confirmed, idempotent XP receipts with amount, broad source, pseudonymous reference and timestamp, derived XP and level, achievements and badges, the numeric attribute matrix, rank and title state, unlocked or equipped title ID, banner, frame and aura, seen reward IDs, and aggregate statistics required for progression. This core progress is synchronized and restored for accounts aged 13 to 17 as well. It contains no task text or quest titles, schedules, Side Quest state, or local protection, URL, or app-usage histories. To prevent two devices from earning parallel XP, ZUHD also processes only a random session ID, mode, planned minutes, server start/end, and status for XP-eligible focus sessions. This reservation contains no focus profiles, apps, domains, keywords, or content. Title, category, difficulty, estimated duration, recurrence, weekdays, deadline, status, and completion details of custom Side Quests are processed only for accounts aged 18 or over after optional account backup is explicitly enabled and are deleted from the cloud when consent is withdrawn. Account, trial, Premium, and required progress processing is based on GDPR Article 6(1)(b) and (f); optional Side Quest backup is based on Article 6(1)(a). Focus profiles, screen-time totals, screen-time categories, per-app usage minutes, apps, domains, keywords, VPN decisions, and app-usage histories are not generally synced. A narrowly limited exception applies only when you request a specific support or safety action: the single target value required for that command may then be processed as described in section 7; ZUHD does not derive a list or usage history from it.

ZUHD does not require a clear name for outward-facing use of Friends, Social, and Community features. Friends through exact-username search or invitation are available from age 13 under the applicable safety rules; private messages, Community, and full public profiles are available only from age 18. Depending on the permitted feature, other users see the chosen @username, a neutral server-derived avatar by default, and only deliberately shared profile values. From age 18, a user may replace the neutral avatar on the full profile with a deliberately uploaded profile image or GIF and separately choose its recipient group. The email address internally required for authentication, account security, and recovery is not displayed to other users as profile information. A name or profile image supplied through Google OAuth may be processed internally during sign-in but does not automatically become the Social identity or uploaded profile medium. The account remains attributable to ZUHD through the user ID and email and is therefore not anonymous in relation to ZUHD, but pseudonymous outwardly.

For the product minimum age and age-dependent access, ZUHD processes the date of birth you enter yourself. It does not come from Google OAuth or Google Play and is not confirmed by those services. The server uses it transiently during the declaration to determine whether the minimum age of 13 has been reached and to calculate derived age data including the 18+ date. The raw date of birth is not stored as a separate field in the ZUHD application database. ZUHD stores the derived unlock data, policy version, declaration time, and required safety acknowledgements; these derived values also remain sensitive age data. The encrypted Google OAuth handoff, valid for no more than five minutes, contains state, PKCE, and legal-acceptance bindings but no date of birth. If an age declaration is still required after Google sign-in, it is entered only in the following age screen and transmitted for server-side derivation; it is not stored in that local OAuth handoff. For email registration, the raw date of birth is kept locally, separately from the longer-lived date-of-birth-free legal-acceptance handoff, using AES-GCM encryption with a non-exportable Android Keystore key. The age handoff is bound to the normalized email address, random consent nonce, and signup time and remains usable for no more than 60 minutes. For a matching confirmed email or permitted session, it is removed before being returned once to the authentication flow. Expired, invalid, or unbound material is removed on the next relevant access or cleanup; repository startup also runs that cleanup. Once the related legal acceptance has been recorded successfully, the password handoffs are removed; a complete local account-data erasure clears the pending-auth store. Accounts without a valid age status remain unavailable, including for advertising; below age 13 no usable account is enabled. Accounts aged 13 to 17 are treated globally and conservatively as children without collecting a country or parent contact for that purpose. The purposes are enforcing minimum access, child safety, 18+ gates for private messages, Community, full public profiles, server-side profile media, and optional task cloud, age-dependent advertising treatment, and preventing a plan from bypassing those limits. Reaching the stored 18+ date can establish age eligibility without another date-of-birth entry, but it enables no optional cloud backup and uploads or publishes no medium automatically. The legal bases are GDPR Article 6(1)(b) for contract-related access control and Article 6(1)(f) for child safety, abuse prevention, and consistent safety boundaries. This does not replace consent required for optional processing.

Existing private messages, Community content, full public profile projections, profile media, or optional Side Quest/task-cloud data of an account under 18 is not deleted solely because of that age band, but it is supplied neither to the account nor to other ordinary users. Permitted, tightly limited moderation, deletion, and statutory retention access remains purpose-bound. ZUHD does not promise that an already issued short-lived signed media URL can be invalidated retrospectively and immediately; new URL issuance and ordinary retrieval remain blocked. The server-authoritative 18+ date may later establish age eligibility without another date-of-birth entry. Optional task cloud backup must still be deliberately enabled at that point; no profile medium is uploaded or republished automatically.

Focus profiles, custom Side Quests, schedules, block and allow lists, and protection settings are stored locally on your device by default. Optional Side Quest backup does not change that focus profiles and all app, domain, keyword, VPN, and history data remain local. Usage Access, Accessibility, VpnService, notifications, and Photo Picker are used only for the explained app function. For local keyword rules, Accessibility checks only the known visible address bar of supported Chrome and Firefox variants. App name, domain, and address path are evaluated without the search query. Only after separate, versioned, affirmative consent that is independent of both Accessibility and short-video consent may ZUHD transiently decode a search value and compare it with your locally saved keywords. The only allowed exact hosts are the Google base hosts google.com, google.de, google.at, google.ch, google.co.uk, google.fr, google.es, google.it, google.nl, google.be, google.pl, google.se, google.no, google.dk, google.fi, google.ie, google.pt, google.com.au, google.ca, google.co.nz, google.co.jp, and google.co.in, each both bare and with www.; bing.com and www.bing.com; duckduckgo.com, www.duckduckgo.com, html.duckduckgo.com, and lite.duckduckgo.com; search.brave.com; ecosia.org and www.ecosia.org; startpage.com and www.startpage.com; qwant.com and www.qwant.com; search.yahoo.com, de.search.yahoo.com, uk.search.yahoo.com, and fr.search.yahoo.com; youtube.com, www.youtube.com, and m.youtube.com. Exact combinations are Google and Bing /search with q; DuckDuckGo /, /html, or /lite with q; Brave Search and Ecosia /search with q; Startpage /sp/search or /do/search with query; Qwant /, /search, or /web/search with q; Yahoo /search with p; YouTube /results with search_query. No wildcard or suffix matching is used. Unknown hosts, paths, parameters, overlong or undecodable values, and ambiguous browser states fail open. Search text may reveal particularly sensitive interests; the legal basis is your consent under GDPR Article 6(1)(a) and, where special-category data may be involved, your explicit consent under Article 9(2)(a). The search text, full address, and intermediate values stay only in memory, are discarded immediately, and are not stored, logged, exported, synced, sent to Supabase, analytics, crash, or advertising services, or displayed on the block screen. ZUHD does not read keystrokes, search suggestions, arbitrary UI text, or page content for this. When saving a setup with a keyword, you may explicitly choose “Save base rule only”: the local keyword is stored for app-name, host, and path matching while query checking stays off. “Not now”, Back, or Close persists neither the draft nor consent. Starting a setup that contains a keyword remains stopped without current affirmative consent. Consent is withdrawn immediately on sign-out or account change. It can also be withdrawn at any time under Privacy & data > Permissions, independently of protection strength, cooldown, partner approval, or an active session; runtime withdrawal stops search-query checking before the next decision while app-name, domain, and path rules remain. Social media blocks selected apps and related websites in full. The separate Short videos category blocks pure short-video apps in full and detects YouTube Shorts, Instagram/Facebook Reels, and Snapchat Spotlight on a best-effort basis in supported mixed-purpose apps; normal areas remain usable. Only after a new versioned disclosure and your affirmative consent, the optional Accessibility service processes the minimum current UI signals on-device in memory and discards them immediately. Previous app-blocking consent is not sufficient. You can withdraw this separate consent at any time under Privacy & data > Permissions; in-app detection then stops immediately. Pure short-video apps and exact short-video paths in supported browsers remain separate category rules until you turn the category itself off. Node trees, UI labels, page content, videos, messages, input, screenshots, full URLs, and viewing histories are not stored, transmitted, or logged. ZUHD does not click or scroll; unknown app versions, languages, or UI states fail open. The local VPN filter checks domains on the device; blocked requests stay local. Allowed DNS queries are forwarded to the DNS resolver currently used by the device or network and may be visible there like ordinary DNS queries. They are not sent to a ZUHD server. There is no external ZUHD VPN server and no HTTPS man-in-the-middle.

When you select an image or GIF through Android Photo Picker, that selection initially remains in ZUHD app storage on your device and is not uploaded to ZUHD automatically. Before age 18 it remains local only. From age 18, you may send a technically prepared copy as profile media through a separate, deliberate action. Reaching age 18 does not automatically upload, republish, or change the visibility of any existing local or server-side copy. The app checks technical limits before transfer, and the server validates the bytes actually received again. A technical check confirms only the file type, structure, and defined size, image, or animation limits; it is not content moderation. The local original and server-side copy are separate data sets: removing the online copy does not delete the local original, and deleting local app data does not automatically remove an online copy that was deliberately uploaded earlier.

If you use support, account deletion, GDPR access, or similar help, we process the text you provide, category, status, email address, user ID, and processing notes. Support requests are stored through Supabase; confirmation and system emails currently run through Hostinger. For the electronic withdrawal function for the free ZUHD usage contract, ZUHD processes your name, the contract description you provide, the email address for the acknowledgement, the exact declaration, a random submission ID, a content-bound receipt reference derived from it, and the date and time of receipt. The declaration and consumer-email work item are stored atomically and access-restricted at Supabase before delivery is attempted. Delivery to the address you provide runs through Hostinger; a mail-provider failure does not delete the declaration. ZUHD separately stores consumer-delivery state, attempt count and times, a short technical error class, and a short-lived processing lease. Successfully completed outbox operational data is deleted after 30 days. An uncertain SMTP outcome is not automatically resent to you but is held for manual review. The declaration, receipt reference, receipt time, proof of a successful acknowledgement, and internal handling record are generally retained until the regular limitation period expires and are technically deleted on 1 January after the third calendar year following receipt. For bounded abuse prevention, ZUHD processes only HMAC values of the email address and, where available, network address, using a secret server key; raw IP addresses are not stored and these quota values are deleted within no more than 48 hours. An email-derived value that a third party can trigger does not by itself block intake. Only authorised administrators who have renewed MFA may view the private handling queue and mark a case as processed with a note; that action is audited. Withdrawal neither automatically deletes an account nor withdraws or cancels a separate Google Play subscription. A normal support request about a Google Play purchase is support only and is not a withdrawal declaration addressed to Google Commerce Limited. The legal bases are GDPR Article 6(1)(b) for the requested contract handling, Article 6(1)(c) for the statutory electronic acknowledgement, and Article 6(1)(f) for the necessary receipt, delivery, handling and legal record and bounded abuse prevention. If you are signed in and have enabled app notifications, ZUHD uses Google Firebase Cloud Messaging to notify you promptly of a new support reply even while the app is closed. This processes a random Firebase Installation ID, a hashed random ZUHD installation identifier, language, active status, and update time. The push contains only the technical type “support reply” and language—never message text, subject, ticket content, user ID, apps, domains, keywords, or usage history. Registration is removed on sign-out, when notifications are disabled, or on account deletion; stale targets are disabled after 90 days. The legal bases are GDPR Article 6(1)(b) and (f) for requested support communication and reliable delivery. ZUHD uses two separate command channels, each limited to predefined settings. For an account-bound support-unblock action, an administrator acting after renewed MFA verification may specify one target type and value, such as a domain, app package, focus profile, protection category, schedule, or all-target command. The data comprises user ID, target type and value, action type, status, creator and timing data, any expiry, reason and linked support case, and reduced audit events. This channel is technically account-bound; not every such command is required to be linked to a support ticket or a particular installation. The separate remote emergency-shutdown channel is ticketless. The acting administrator must expressly confirm that the affected user requested the shutdown; the server neither accepts a support ticket for this route nor checks ticket assignment. It processes the user ID, a hash of the latest active app installation, an authorised reason code, audit reason, confirmation of the user request, the confirmation phrase submitted for verification, actor, attempt and status data, timestamps, and the 15-minute expiry. It may be initiated only by an active owner-administrator who has re-authenticated at AAL2. Both channels allow the app only to retrieve and locally execute the predefined ZUHD command intended for the account. No list or usage history is transferred; ZUHD receives no general remote access and cannot freely inspect the device, local content, or history. The legal basis is GDPR Article 6(1)(b) where the action provides assistance expressly requested by the user, and Article 6(1)(f) for narrowly authorised support action, audit, abuse prevention, and system security. To prevent spam, Cloudflare Turnstile, the temporarily transmitted client IP, a keyed HMAC of the IP or email, and a short-lived content fingerprint may be processed. A normalized sender email may remain in a support denylist until manual unblocking or review after documented abuse. Review or removal can be requested through the privacy contact; the restriction is removed when its security purpose no longer applies. Delivery events are logged in reduced form, for example channel, status, and related case instead of unnecessary user history. Critical admin actions are logged in reduced form to support security, traceability, abuse prevention, and legal obligations. User-facing access exports are redacted before delivery so that no third-party IDs, tokens, or internal admin details are disclosed. When account deletion completes successfully, account-related support cases, messages, and processing notes are removed immediately from the active ZUHD database unless a specifically documented legal hold applies. This does not automatically remove a copy already transmitted to the external support mailbox. That copy requires a separate, documented deletion process or is retained with restricted access under a specific legal hold; technical backups held by the email provider lapse only through its regular rotation. To avoid accidentally restoring a deleted account after a backup restore, the account deletion function also sends a versioned HMAC of the user ID plus deletion status and timestamps to a separate Cloudflare Worker with D1. The receipt contains neither the raw user ID nor email or usage content and is deleted by default 35 days after it is created. Depending on the process, the legal bases are GDPR Article 6(1)(b), (c), and (f).

Where the existing Hardcore/trusted-person feature is used, partner email, status, hashed access tokens, time-limited portal sessions, abstract approval requests, and revocations may be processed. The feature is available from age 13 under its applicable safety rules and is not a parent or legal-representative approval process. Partners do not receive personal app, domain, focus profile, keyword, or usage history data. The legal bases are GDPR Article 6(1)(b) for the requested partner feature, Article 6(1)(a) for voluntary approvals, and Article 6(1)(f) for security and abuse prevention.

Automated-translation notice: This service may contain translations powered by Google. Google gives no express or implied warranties regarding those translations. This includes, in particular, warranties concerning accuracy or reliability and implied warranties of merchantability, fitness for a particular purpose, and noninfringement. Friends through exact-username search or invitation are available from age 13 under the applicable safety rules. Private text conversations, Community, and full public profiles are available only to accounts whose server-authoritative age status is at least 18. Public Community posts and replies are displayed unchanged in their original language by default. The reporting interface follows the selected app language; reporting and moderation continue to use only the unchanged original content. Only after you expressly tap “Translate with Google” does Google ML Kit identify the language of that specific Community content and create a transient on-device display translation into the current app language. It does not alter the contribution and is not written to Supabase, Room, DataStore, logs, crash or analytics data, report or moderation context, or the clipboard. Sharing, replying, reporting, and moderation use the original content. If the required language is not yet available, ML Kit may first download a dynamic language model from Google and may also contact Google servers for bug fixes, model updates, and hardware-accelerator compatibility information. According to Google, ML Kit processes input and output text entirely on the device and does not send those texts to Google. The SDK does, however, transmit diagnostics and utilization metadata. This may include device and app information, depending on SDK delivery a device identifier, installation identifiers not intended to uniquely identify a user or physical device, performance metrics, input and output size, feature version, event and error codes, and the identified or configured source and target languages. Translation results are identified immediately as “Translated by Google.” Automated translations may contain errors; no warranty is provided for accuracy, reliability, or fitness, and the original text remains authoritative for reporting and moderation. If you use the optional Social features, ZUHD processes, depending on the action, your user ID and @username, a neutral server-derived avatar, friend requests and relationships, blocks and mutes, the selected visibility of your public profile projection, and deliberately shared level, title, badge, and aggregated attribute values. Conversations and the shared moderated Community room process text, reply references, limited reactions, room, author, and time. ZUHD also processes the accepted Community-rules version and time, report reason and optional short details, handling status, measures, and reduced audit and anti-spam signals such as rate-limit events and non-reversible content fingerprints. Protection rules, apps, domains, focus profiles, private tasks, and usage histories are not transferred to Social profiles or the Community. Private text conversations are visible only to both participants and are not provided to administrators as a live feed. Only a specific report makes the reported message and no more than one immediately preceding and one immediately following message available as limited context. Private messages and private report context must expire server-side no later than 30 days after creation, must no longer be delivered after that point, and must then be physically removed by the designated cleanup process; users and moderators cannot extend the period. Public release requires technical proof that this cleanup process runs as intended. Removed public posts are no longer delivered and must be technically removed by the designated cleanup process no later than 30 days after removal. If notifications are enabled, the same random Firebase Installation ID may be used for data-minimised Social signals. The push contains only a technical type, event type, and language—never message text, profile content, user ID, or protection data. Free text in messages, posts, support, or Community reports may exceptionally contain special categories of personal data or information relating to offences about senders, affected people, or third parties; submit such information only where it is required for a specific report. Before use beyond technically necessary receipt and triage, ZUHD documents the specific condition under GDPR Article 9(2) or Article 10; without a valid basis, the information is promptly redacted or deleted unless a lawful retention duty applies. The reporting user's consent does not provide a blanket basis for third-party data. Where ZUHD obtains affected people's personal data indirectly from such content and GDPR Article 14 applies, information is provided within the statutory period, no later than the first communication with the affected person or before the first disclosure to another recipient, whichever occurs first, unless a documented exception under Article 14(5) applies. The legal bases are GDPR Article 6(1)(b) for communication and profile features deliberately selected by the user, Article 6(1)(f) for security, abuse prevention, and proportionate rule enforcement, and Article 6(1)(c) where a specific statutory moderation, information, or record-keeping duty applies. Account-bound Social data is removed under the described deletion rules when the account is deleted.

ZUHD treats the content of private messages between friends and the related circumstances as confidential. ZUHD does not obtain knowledge of them beyond what is required for transmission, delivery, and protection of the technical systems, unless a statutory provision permits a further purpose that expressly relates to telecommunications. A GDPR legal basis alone does not broaden that access. A specific user report may make the selected message available for handling; additional immediate context may be accessible only where legally permitted and necessary in the individual case and restricted through roles and access records. There is no administrator live feed and, in the current feature design, no end-to-end encryption. Before public activation, the private messaging function will be classified on a service-specific basis either as a number-independent interpersonal communications service or as an inseparable subordinate ancillary feature; all applicable duties under section 3 TDDDG and the German Telecommunications Act must first be implemented technically and organisationally.

Server-side profile media is available only to accounts whose server-authoritative age status is at least 18; reaching age 18 does not automatically publish or reactivate an existing medium. For a deliberately uploaded profile image or GIF, ZUHD processes the technically prepared media file together with the user and owner link, a random non-speaking media ID, content or MIME type, file size and image or animation characteristics, a cryptographic content hash, selected visibility, review and moderation status, timestamps, and limited security, audit, and deletion data. The Supabase Storage bucket is not public. Media is served only after an authenticated server-side authorisation check. Every new upload begins with “Only me”. “Friends” permits display only to confirmed ZUHD friends. “Community” permits display only to signed-in users who meet the age- and rule-dependent requirements for that profile view; anonymous web access is not intended. Profile media appears only on the full profile. Friend overviews continue to use the neutral avatar; private messages and Community posts remain text-based and have no image, GIF, or file attachments. Visible profile media can be reported in the app and reviewed, restricted, or removed by authorised people when a specific reason exists; technical validation signals do not decide a content measure by themselves. An image may reveal appearance, surroundings, or other sensitive information. ZUHD does not use profile media for face recognition, biometric identification, advertising, data trading, or training general-purpose AI models. The legal basis is GDPR Article 6(1)(b) for the profile feature deliberately selected by the user and Article 6(1)(f) for technical security, abuse prevention, moderation, and accountability. Where specific content includes special-category data or information about third parties, that does not create a blanket authority for further purposes; any such use requires its own valid legal basis.

The dedicated electronic mechanism under DSA Article 16 may be described as available only after submission, acknowledgement, case access, decision communication, delivery retry, and decision-bound review have passed end-to-end release gates. Where the mechanism has been released, ZUHD processes independently of a user account and according to the information actually submitted the party type, name and email address of the reporting person or organisation, the precise electronic location, the explanation of the alleged illegality, and the good-faith declaration that the information is accurate and complete. The mechanism must permit submission without identification. For a notice containing every element listed in DSA Article 16(2), a name and email are ordinarily among the listed elements; they are statutorily omitted for notices concerning offences referred to in Articles 3 to 7 of Directive 2011/93/EU. Outside that exception, identity may be required for substantive assessment only where it is necessary to determine the alleged illegality. The form, backend, and email path must implement this identity minimisation consistently before release. Once technically released, ZUHD may additionally process random notice and ticket references, access tokens stored only as hashes, receipt and handling timestamps, status, decision, reasoning, legal or contractual basis, whether the decision arose from a notice or ZUHD's own initiative, information about automated means used, delivery and redress status, and reduced security, rate-limit, and deduplication signals. This data is used to receive, assess, decide, communicate, and document notices under DSA Articles 16 and 17, provide available redress, and protect the mechanism from abuse. The legal basis is GDPR Article 6(1)(c) in conjunction with the DSA duties specifically applicable; GDPR Article 6(1)(f) additionally applies to necessary security measures and the establishment, exercise, or defence of legal claims. The currently intended email path transmits the ticket reference, subject and category, the sender email entered, and the notice text through Hostinger to the access-restricted support mailbox; name and location are not output there as separate fields. A notice may contain data about the notifier, the affected user, and third parties. Information about affected people may originate from the notifier and from the specifically identified ZUHD content. Where GDPR Article 14 applies, ZUHD informs the affected person within the statutory period, no later than the first communication or before the first disclosure to another recipient, whichever occurs first, unless a documented exception under Article 14(5) applies. A statement of reasons under DSA Article 17 may exceptionally contain information about the notifier's identity only where this is strictly necessary to establish the illegality or incompatibility of the specific content; such a disclosure to the affected user is documented case by case. Do not submit files or personal data unnecessary for assessment. Free text may exceptionally contain special categories of personal data or information relating to offences. Before any use beyond technically necessary intake processing, ZUHD documents the applicable legal basis and, where required, the specific condition under GDPR Article 9(2) or Article 10. Without such a basis, the information is promptly redacted or deleted unless a lawful retention duty applies. The legal basis and safeguards for the technically necessary intake itself must be legally determined and technically implemented before release.

Where publicly disseminated content is removed or disabled under an enforceable removal order or a specific measure pursuant to Regulation (EU) 2021/784, ZUHD must separately preserve the affected content and the related data necessary for authority, judicial, or complaint proceedings and for preventing, detecting, investigating, and prosecuting terrorist offences. The statutory base period is six months from removal or disabling; longer preservation occurs only following a specific request from a competent authority or court and only for as long as necessary for the ongoing proceeding. Preserved material is segregated from normal delivery, access-restricted, and usable exclusively for those purposes. This specific duty takes precedence over the general 30-day cleanup of removed public posts. It does not cover private messages between friends because interpersonal communications are not disseminated to the public. The legal basis is GDPR Article 6(1)(c) in conjunction with Article 6 of Regulation (EU) 2021/784, together with the technical and organisational safeguards required there.

From 18 August 2026, where the specific service and cross-border offering fall within scope, ZUHD may be required under a valid European Preservation Order or European Production Order to preserve or produce specified electronic evidence for particular criminal proceedings. Only data already stored by ZUHD when the order is received is covered. This creates no general or indiscriminate data-retention duty, no duty to collect additional identity data, and no duty to decrypt data. Under a European Preservation Order, the specifically identified data set is generally preserved for 60 days; the issuing authority may extend that period by a further 30 days or require preservation to continue for as long as necessary to handle a subsequent request for production. The data set is segregated, access-restricted, and protected by state-of-the-art measures for confidentiality, secrecy, and integrity. The legal basis is GDPR Article 6(1)(c) in conjunction with Regulation (EU) 2023/1543 and the German EBewMG, insofar as they actually apply. The issuing authority is generally responsible for informing the affected person and may delay, restrict, or omit that information where the statutory conditions are met. ZUHD does not inform the person on its own where an order or the law requires confidentiality.

After the free trial ends, the Free version may show ads through Google Mobile Ads. Google and the advertising partners named in the consent message may process an approximate region inferred from the IP address, interactions with ads, diagnostic and performance data, consent and privacy signals, and device, advertising, App Set, or, where applicable, other account identifiers. This data is used to provide and measure advertising and to detect fraud, misuse, and security issues. Where consent is required, the app asks for it through Google UMP before making the first ad request. The legal basis is then GDPR Article 6(1)(a) and, where information is stored in or read from the terminal device, section 25(1) TDDDG. Necessary security and fraud-prevention processing relies on GDPR Article 6(1)(f) only to the extent permitted by law; this does not replace consent required under section 25 TDDDG. Depending on the region and choice, personalized, non-personalized, or limited ads may be permitted; refusing consent therefore does not automatically make the app ad-free. If UMP does not establish permission to request ads, ZUHD makes no ad request. The choice can be changed or withdrawn later in the ad privacy options. Trial and Premium remain ad-free. ZUHD also shows no ads during active focus sessions or in protection, block, privacy, support, account, or payment flows. The app does not request location permission for advertising and does not build its own advertising profile history. The applicable choice for the region and the participating advertising partners are shown in the UMP consent message before any permitted ad request. ZUHD makes no ad request while the server-backed age status is missing or unclear. The raw date of birth and derived age dates are not sent to Google AdMob/UMP. Accounts aged 13 to 17 are treated worldwide as children for advertising: only child-appropriate, non-personalized Free banner advertising on Home may be requested, with Google's child-directed and under-age-of-consent treatment signals and only through an advertising SDK and configuration approved for that use. App Open ads are not requested for these accounts. If this child-ad configuration or the required consent state cannot be established, ZUHD makes no ad request. For accounts classified as adults, ZUHD sends Google no proof of age; the regular regional UMP and advertising flow applies. Premium does not override an age or advertising-protection boundary.

Operational account, cloud, progress, partner, and account-related support data is removed from the active ZUHD database once account deletion completes successfully; separate formal DSA and moderation records and specific statutory retention grounds follow the rules below. Deleting the database record does not automatically remove a copy already transmitted to the email provider; that copy requires a separate, documented deletion process, and technical email backups lapse only through the provider's regular rotation. Renewable sign-in sessions are revoked; short-lived access tokens already issued may technically remain valid until they expire, but the account has been deleted. The app then deletes its data in ZUHD app storage on the device currently being used. ZUHD cannot remotely wipe other devices; local data there must be deleted in the app or by uninstalling it. Copies exported or shared by the user are outside ZUHD app storage and must be deleted there by the user. A Google Play subscription must be cancelled separately in Google Play. Ordinary closed support cases and technical support-mail-ingest records are generally cleaned up no later than 90 days after closure or receipt. Requests for supplementary Google Play withdrawal assistance and related support, acknowledgement, and email records generally follow that support period. Only where a specific record is required to establish, exercise, or defend legal claims or because a statutory retention duty actually applies is it kept separately with restricted access until that purpose ends; the maximum period is then generally aligned with the end of the standard three-year civil limitation period unless a specific shorter or longer duty applies. Formal DSA notices under section 10 and their decisions are not ordinary support cases and do not depend on account deletion. Where DSA Article 20 applies following the service-size classification that must be documented before release, electronic complaint access must remain available for at least six months from demonstrable notification of the decision. A backend record becomes eligible for deletion only after a required decision was delivered or delivery lawfully did not apply, the actually applicable redress period has expired, no redress remains open, and no documented legal hold applies. The full-text copy transmitted through Hostinger is not automatically deleted with the backend record and requires a separate documented deletion process once it is no longer needed; technical provider backups may remain until their regular rotation ends. Statements of reasons for Community moderation decisions are retained only for as long as necessary for delivery, an active measure, an actually available review, a specific statutory record, or a documented legal hold. On account deletion, the account reference and other attributable details are removed or anonymised unless a specific statutory ground permits continued attribution. ZUHD-controlled technical operations and security logs are generally cleaned up after 30 days, and short-lived abuse, rate-limit, and deduplication records after two days. A legal hold is permitted only for a specific legal dispute, authority order, or comparable documented legal basis, remains segregated and access-restricted, and must be reviewed again no later than 90 days after it is set or renewed. Reduced local activity events are limited to roughly 30 days on the next write or cleanup operation. For on-device statistics, ZUHD may store daily aggregated usage minutes per app label on the device for up to 365 days. These daily aggregates are not a chronological app-usage history and are not uploaded to the cloud. Data previously included in technical backups may remain until the regular rotation ends; after a restore, previously deleted accounts are deleted again or blocked before the service is made available. Google, AdMob, advertising partners, Hostinger, and Cloudflare additionally apply their own retention rules.

The electronic withdrawal declaration for the free ZUHD usage contract described in section 7 is not an ordinary support request and therefore follows the specific periods stated there: HMAC-based abuse signals for no more than 48 hours, successful outbox operational data for 30 days, and the minimised declaration record with receipt reference, receipt time, delivery evidence, and handling status until 1 January after the third calendar year following receipt. Separate supplementary assistance concerning a Google Play purchase remains an ordinary support process and does not alter those periods.

The encrypted Google OAuth/PKCE/legal-acceptance handoff remains usable for no more than five minutes and contains no date of birth. For password registration, the separate encrypted date-of-birth handoff, bound to the email address, consent nonce, and signup time, remains usable for no more than 60 minutes. It is removed before being returned once for an allowed use; expired, invalid, or mismatching handoffs are removed on the next relevant access or cleanup, which also runs at repository startup. Once the legal acceptance has been recorded successfully, the related password handoffs are removed; a complete local account-data erasure clears the pending-auth store. The longer-lived password legal-acceptance handoff itself contains no date of birth. The derived 16+ and 18+ dates from the existing technical contract, policy version, and declaration metadata are generally retained for the lifetime of the account and removed from the active database when account deletion completes successfully. Under the selected target model, the 16+ date does not unlock private messaging, Community, full public profile projections, server-side profile media, or optional cloud features; age 18 is decisive for those features. Friends and the existing Hardcore/trusted-person feature remain unaffected. Earlier copies may remain only until the general technical backup rotation ends.

Uploaded profile media and its required metadata are generally retained until replacement, separate removal, or successful account deletion. After such removal, the medium is no longer served as active profile media; physical object deletion occurs immediately or, if a temporary technical error prevents it, through the designated access-restricted cleanup process. Limited technical security and audit data follows the periods in section 13. A specifically required moderation or legal-defence record may remain only separately, with restricted access, and under an actually applicable legal basis. Earlier copies in technical backups may remain until regular rotation ends and must not be restored as active profile media.

ZUHD does not store full browser history, full URLs with query parameters, search history, search text or query values transiently extracted from visible search addresses, keystrokes, plaintext passwords in the app or ZUHD application database, screenshots, contacts, its own location history, contents of third-party device notifications, VPN traffic contents, visited adult domains as a user history, Accessibility node trees, UI labels, or short-video/viewing histories. The raw date of birth is not stored as a separate field in the ZUHD application database. From the observational Play Integrity check, ZUHD neither stores nor logs the raw token, a token hash, an individual Google verdict, an installed-app category, or an account-linked security result. Credentials are transmitted securely to Supabase Auth; the ZUHD app does not store the password in plaintext. ZUHD requests no precise-location permission and stores no precise location. Uploaded profile media is not processed for facial measurement or biometric identification. For advertising, Google may infer an approximate region from the IP address as described in section 11.

Transfers to backend, store, and email services are encrypted. Local protection decisions block apps or websites based on your rules and protection categories, but they do not constitute solely automated legal decisions within the meaning of GDPR Article 22. From the date of birth provided, ZUHD automatically calculates whether the product minimum age of 13 has been reached and the date on which the 18+ band applies. This fixed rule may enable or restrict account, private-messaging, Community, full-public-profile, profile-media, optional-cloud, and advertising-protection features; it does not assess personality, reliability, or interests. Reaching age 18 establishes age eligibility without another date-of-birth entry, but it does not automatically upload, republish, change profile visibility, or activate optional cloud backup. Rectification can be requested through the contact routes in section 16. The current in-app integrity observation makes no account, plan, or feature decision. Technical spam, rate-limit, or abuse signals may prioritise or temporarily limit notices. Removal, a warning, a Community restriction, or the legal assessment of a DSA notice must not result solely from those signals. Where qualified human supervision is required by law or promised in these rules, demonstrable organisational and technical operation of that supervision is a condition of public release.

Subject to the applicable statutory conditions, you have in particular the rights of access, rectification, erasure, restriction of processing, data portability, and objection, and the right to withdraw consent at any time with effect for the future. Withdrawal does not affect the lawfulness of processing carried out before it. Where processing is based on GDPR Article 6(1)(f), you may object on grounds relating to your particular situation; ZUHD then stops that processing unless compelling legitimate grounds or the establishment, exercise, or defence of legal claims prevail. ZUHD does not use this data for its own direct marketing. You also have the right to lodge a complaint with any competent data protection supervisory authority, in particular the Rhineland-Palatinate Commissioner for Data Protection and Freedom of Information. Contact us at [email protected] or through the support form under the Privacy category. Email/authentication data, a username, and the self-declaration required for age status are required for an account; verified purchase data is required for Premium. Without this data, the respective account or Premium service cannot be provided. Support text, partner features, Side Quest backup, Photo Picker, profile-media upload, and sensitive Android permissions are optional. Side Quest cloud backup and server profile-media upload additionally require an adult server-backed age status; without the respective optional data or eligibility, only the corresponding optional feature remains unavailable.

ZUHD receives personal data mainly from you. This includes profile media only where you are at least 18 and deliberately start the separate upload; selecting it locally through Photo Picker does not transmit it, and reaching age 18 does not trigger an upload or republication. The date of birth used for age access comes exclusively from your entry; Google OAuth and Google Play neither provide nor verify it, and purchase status proves neither legal adulthood nor consent from a legal representative to ZUHD. In addition, account confirmation and sign-in data come from Supabase Auth or Google OAuth, purchase and entitlement status from Google Play, voluntary partner or friendship details from the person who deliberately starts the respective process, and necessary connection or security metadata from Hostinger, Cloudflare, Google Play Integrity, or the device used. ZUHD does not buy address lists, import contacts, or obtain user profiles from data brokers. Data processed only in local memory or app storage is not transmitted to ZUHD merely because it is processed on the device.

ZUHD publishes material changes to purposes, data categories, recipients, or legal bases as a new, dated version. A published version is not silently overwritten or used to reinterpret earlier events after the fact; earlier release states are retained in a traceable form to the extent legally and technically required. Where optional processing requires consent, new or updated consent is obtained before that processing begins. Acknowledging this privacy policy is not blanket consent to every process described in it.