Privacy at Wunschkiste

Last updated: 18 October 2026

Controller

Timon Polley, Gutenbergstraße 5, 51469 Bergisch Gladbach, Germany. Email: dev@timonply.com. Further provider information is available in the legal notice.

Why Wunschkiste processes data

Wunschkiste helps collect and share gift ideas. Lists, wishes and reservations are stored on a server so invited people can view them in the app or browser. Using it without an account is therefore not exclusively local either.

For these features, Wunschkiste processes list titles, dates, descriptions, selected cover images, archive status, wishes with product addresses, image addresses, prices and notes, optional size and colour and up to five custom label/value details, reservations and their status. Optional uploaded cover and wish images are also stored. Only use images you are permitted to share; avoid confidential information, children's portraits or other unnecessary personal content.

The supported own image upload requires explicit confirmation of the upload and use terms, version upload-v1-2026-10-11. A bounded receipt is stored with the current image, containing the version, the image's SHA-256 digest, permission scope, cover, wish or profile purpose and confirmation time. This receipt documents the limited permission and image association; it does not establish independently verified image rights. No unbounded upload-consent history is created. Replacing the image uses the current image's receipt; removing the image or confirming account erasure removes its association. Necessary report evidence and technical backups described below are separate. Processing provides the requested feature under Article 6(1)(b) GDPR and prevents abuse under Article 6(1)(f); parent permission is addressed below.

An optional account adds a display name, internal account identifier and technical device sessions to this data. New accounts use an email address and password through Google's Firebase Authentication. The app sends these details to Google over an encrypted connection; your password is not sent to the Wunschkiste backend. The backend receives and verifies authentication tokens and stores the account association, email address and verification status. Google also processes technical connection data such as IP addresses and information about the client used for authentication and abuse prevention. Further information is available in the Firebase privacy notice.

If Google sign-in is offered, you can alternatively use your Google access. Google and Firebase Authentication process the account and authentication data needed for this; Wunschkiste receives verified proof of authentication, the account identifier, email address and, where available, display name. Your Google password is not sent to Wunschkiste. Signing in does not grant access to your inbox, contacts or files. Google's further processing is described in its privacy policy.

The iOS sign-in providers also receive technical connection data. Google's iOS sign-in guidance states that an IP address may help estimate a device's general location for fraud prevention. Wunschkiste requests no location permission for this and collects no GPS location. The privacy manifests of the included iOS libraries GoogleSignIn 10.0.0 and FirebaseMessaging 12.19.2 also declare device/user identifiers and technical usage, diagnostic and other data, partly for “Analytics” purposes. This is separate from including a Google Analytics SDK in Wunschkiste. With push enabled, FCM processes APNs tokens and installation identifiers in particular; Google explains its iOS libraries' data processing. Provider processing depends on the sign-in or delivery operation used; a library declaration does not mean every listed data type is collected in every use.

If Apple sign-in is configured and enabled in your app version, you can use your Apple access. Apple and Firebase Authentication process authentication; Wunschkiste receives the provider account identifier, email address or Apple's private relay address and, where provided, your shared name. Your Apple password is not sent to Wunschkiste. “Hide My Email” supplies a relay address, not your underlying real email address. Delivery and forwarding depend on Apple, Google and your settings; Wunschkiste does not guarantee delivery. Further information appears in Apple's sign-in privacy notice.

The new Apple/Google sign-in flow requires explicit, initially unchecked consent before each sign-in or renewed confirmation. With the same verified email address, Firebase may use existing email/Google access, associate trusted providers or replace a previously untrusted credential under its provider rules. This consent does not prevent such Firebase associations. Without consent, this new provider operation is not started; email sign-in and guest mode remain available alternatives where offered. Google describes the provider rules.

The Apple browser-to-app return processes technical operation identifiers, verification proofs and necessary authentication/revocation tokens temporarily in the Firebase backend; sensitive handoff data is encrypted there. Email, name and provider identifiers may form part of the sign-in result. The public return address contains only a random operation identifier, never authentication tokens. The backend holds at most 128 Apple operations and 128 Google consent receipts, each valid for ten minutes. Google consent receipts contain technical verification hashes and account/provider associations, never provider or session tokens. Confirmed acknowledgment or cancellation removes held Apple token payloads. Expired technical records are cleaned up when subsequent operations start, so they are not necessarily physically deleted at the instant they expire. A limited provider-consent record is stored for a successfully associated account; further retention details appear below.

You can upload, replace or remove your own profile photo. It is stored as a private account image and retrieved only through authenticated account access. It does not automatically appear on public invitations or reservations. When removed, the selected photo can no longer be retrieved. A limited number of unused upload fragments may remain stored until a later upload after the technical protection period or until account deletion; they cannot be retrieved through the profile. Language and notification preferences are stored to implement your choices. Product names and other content you enter yourself are not sent to a translation service.

You can request a verification link or a link to reset your password. These messages are sent to your email address through Firebase Authentication. Successful email verification is required before the new access is associated with your Wunschkiste account. A stored device session and local authentication tokens enable continued use without entering your password every time you open the app. These credentials are confidential and are not displayed to other guests.

Older accounts initially retain their username and password sign-in. The Android app derives proof of authentication from the password on the device, and the backend processes it as a verifier with its own salt. Such proof remains confidential despite this processing. From your signed-in older account, you can set up verified email access; this additionally requires your previous password or, for accounts without a password, your previous account key to be checked. Lists and reservations remain associated with the same account. Older Wunschkiste accounts using usernames or account keys are not merged solely because names or email addresses match. The Firebase provider association described above is separate from this. After linking, email access replaces the previous authentication and recovery methods.

Older accounts may also have a private account key. This is an optional existing access method and is not required for new registration. Account keys, session permissions and guest permissions are credentials and do not belong in public messages.

Passkeys for the former app address do not apply to the new Firebase address. Passkey sign-in is disabled during migration; if offered again, the new address requires explicit new enrollment. Wunschkiste stores the public key, technical identifier, creation time and information used to securely verify authentication. Private keys and any biometric verification remain with the device or passkey provider; Wunschkiste receives no fingerprint or facial data. A synchronised passkey is also subject to your chosen provider's terms. If you configured a recovery code in an earlier version, the server stores it as a verifier. The Android app may keep a code encrypted until you confirm that it has been saved. Resetting an older account consumes the code and invalidates existing sessions, passkeys and old access credentials. This version does not offer passkey sign-in for email accounts.

Providing the requested list, account and gift features is based on Article 6(1)(b) GDPR. Technical measures against abuse and unauthorised access serve the legitimate interest in a secure service under Article 6(1)(f) GDPR. Required details are identified in the relevant form; the corresponding feature cannot be provided without required authentication or list data.

Guest mode and data on your device

The first native iOS version uses Firebase email, Apple and Google sign-in where each provider is configured. The older username, account-key and passkey methods described above concern existing Android access; this iOS version does not offer them. An older account can be prepared for the new sign-in through the email-linking feature offered there.

Without an account, permission to edit your own lists or reservations is kept locally on your device or in your browser. This permission is separate from the public invitation link. Android protects local credentials with the Android Keystore; they are excluded from normal device backups. The web version uses local browser storage for necessary management and reservation permissions.

Storage serves the feature you requested and recognises your permission; it is not used for advertising or tracking across devices. If you clear app data or browser storage, lose your device or uninstall the app, guest access may be lost. Previously uploaded lists are not automatically deleted from the server as a result. Save any management access you need, or link your lists beforehand through the available account feature.

Whether you have seen or skipped the optional introduction is stored locally, separately from your credentials. This setting remains after you sign out. The introduction can be reopened in Help; your learning progress is not analysed.

On iOS, Wunschkiste stores session and Firebase authentication tokens, guest permissions, unconfirmed drafts and the proofs needed for sign-in and deletion recovery in the device-bound Apple Keychain. These entries use protection after the first unlock of this device; the app does not configure them for synchronisation to other devices. Language and introduction status are stored separately in local app preferences. Signing out removes account access; local guest permissions may remain. Uninstalling is neither account deletion nor a reliable promise that all Keychain data is removed. Apple describes the protection technology.

For custom cover, wish or profile photos, iOS uses the system photo picker. Wunschkiste processes the selected image rather than uploading your entire photo library. Before upload, it is rendered as a new JPEG with limited dimensions and file size. An unfinished box or wish draft, or a pending image upload, may retain the selected image locally for recovery. With content review enabled, guests see a preset cover until the exact uploaded version is approved; its authorized creator can preview the pending image. Profile photos remain within authenticated account access. Own wish photos are also replaced by neutral visuals for guests until their exact image digest and stored image revision are approved; a replacement requires new review.

Invitations, reservations and product images

Anyone who knows a valid invitation link or code can view the corresponding available box and its contents, including description and date. Share this access information only with intended people. With content review enabled and in the new iOS/web interface, gift-givers’ names remain hidden. Older Android versions and boxes without content review may offer explicit name sharing; only the signed-in guest’s own agreement can make their display name visible on reservations and related notifications there. Email addresses and profile photos are not published. Technical associations still allow changing your own reservations; this is not complete anonymity towards the service provider.

The “Hide reservations from me” setting hides details about reserved or purchased wishes from the creator in the signed-in app and related notifications. It is a display preference and does not provide secrecy from people who can open the public guest view. Guests still see wish availability.

Product details are entered by you. The prepared link helper may derive a possible name solely from the path of an HTTPS link you provide. It does not fetch a retailer page or import a retailer photo, price or description. The suggestion may be wrong and needs your review. Without an approved own wish image, neutral gift visuals are used. The wish address and details you enter are stored to provide the box.

Opening a shop link calls the retailer externally, under its own privacy notices. Older Android versions may still display external image addresses of previously saved wishes, giving the image provider connection data, particularly your IP address. A price you entered is not a current shop quote. A click or reservation does not trigger a purchase in Wunschkiste. Any later automatic importer will require a separate review of merchant permission and its data processing.

Notifications

Push notifications about new guests or purchased wishes are off by default. You can enable and disable them individually. Independently of these switches, a limited activity overview of the latest, up to 20 events is stored in the account. It comes from actual actions in your lists, remains available with push switched off and is not used for analytics or advertising.

Push messages are only offered if delivery is configured. After you enable them, the app may additionally request your device's notification permission. To send through Firebase Cloud Messaging, technical device identifiers and delivery tokens are associated with your signed-in device; at most ten device sessions are considered. Messages contain no gift-givers' names or profile images and no private credentials. Google processes the data required for delivery. The connection is encrypted; Firebase Cloud Messaging itself does not provide end-to-end encryption. See the Firebase privacy notice and FCM message security guidance.

Turning off push messages or device permission does not automatically remove notifications already stored in the account. After signing out or revoking a device session, that session is no longer used for delivery; deleting the account removes stored notifications, settings and device associations. Voluntary name sharing and push activation are based on your consent under Article 6(1)(a) GDPR; you can withdraw it for the future.

On iOS, delivery uses Firebase Cloud Messaging and Apple Push Notification service (APNs). Google and Apple process installation/delivery identifiers and technical delivery data. iOS banners use the title “Wunschkiste” and a generic message about a new guest or purchased wish; they contain no item, box or person names. The technical payload contains public event and box identifiers that do not grant editing permission. The app initialises FCM only for enabled, signed-in use with device permission. Previously confirmed activation can be restored on a later launch without prompting for permission again.

Generic messages already handed to the delivery service may still be displayed by the operating system after sign-out, disabling notifications or session revocation. iOS delivery requests a short five-minute expiry; this guarantees neither delivery nor immediate recall of accepted messages. Signing out or disabling notifications removes the Wunschkiste device association for future delivery and attempts to remove the local FCM token and delivered device notifications. The service and operating system may still retain identifiers or processed messages under their own rules. See the FCM guidance for Apple platforms.

Hosting and recipients

These documents are provided through GitHub Pages. GitHub processes technical connection data when you open a page; further information is available in the website privacy notice. The migrated web interface uses Google Firebase Hosting; the backend uses Cloud Functions for Firebase. The new app web address is Wunschkiste. Cloudflare Workers and D1 are not used for this version. Former app addresses are not redirected; invitation and management links must be shared again. An Android download is offered only after the replacement version is approved.

Firebase Authentication manages email access. Cloud Firestore stores account profiles and associations, lists, wishes, invitations, reservations and technical permission and security data, including credential verifiers for older accounts, bounded sign-in operations, parent requests and abuse limits. Uploaded cover, wish and profile photos are stored in a private Google Cloud Storage bucket and retrieved through authorized backend functions; no public image-store or download-token links are provided. Firestore, the private image store and the backend functions use Frankfurt am Main, region europe-west3. Google describes the locations for Firestore, Cloud Storage and Functions. This location choice does not limit all provider services to the EU: Google states that Firebase Authentication processes data exclusively in the USA; Firebase Hosting and other provider services use global infrastructure. Further information is available in the Firebase privacy notice.

Google also processes technical connection data for hosting and backend delivery. Google states that Firebase Hosting uses IP addresses, including for abuse detection, and retains them for a few months; Cloud Functions retains IP addresses temporarily to provide the function. This provider processing is separate from the app’s bounded technical abuse counters and from an integrated Google Analytics SDK. Further details are in the Firebase privacy notice.

These providers may process data outside the European Economic Area. Information on their processing and transfer mechanisms is available in GitHub's privacy statement, the Firebase privacy notice and Google's privacy policy. Google mentions, among other measures, the EU-US Data Privacy Framework and contractual data protection provisions. You can ask the controller about safeguards applicable to this service and, where relevant, request a copy of the corresponding agreements.

The first iOS version contains no FirebaseAnalytics SDK; this does not exclude the providers' technical analysis described above. Wunschkiste sends no marketing emails. Verification and password emails serve only the access you requested. Processing for available Premium purchases is described below. There is no decision based solely on automated processing that produces legal or similarly significant effects.

Advertising and voluntary extra capacity

The iOS app includes Google Mobile Ads 13.11.0 and User Messaging Platform (UMP) 3.1.0. Android has a separate AdMob integration. SDK inclusion alone does not enable advertising. A server-verified active Premium membership is ad-free. The web view has no advertising SDK.

Advertising requests and reward videos remain off while the app lacks its store association, provider approval, consent configuration or technical readiness. The iOS AdMob provider review is not yet complete. The German/English consent message is associated with Android and iOS; publishing it alone does not enable ads. The app does not explicitly initialise UMP or start advertising requests when disabled. SDK inclusion alone does not prove that a provider performs no technical processing; compiled SDKs and their processing must be considered before activation.

The current clients ask neutrally for “Under 13”, “13–17” or “18+”, without a preselection. Own accounts at 13–17 require documented parent approval; younger children use a parent's account. Advertising requests are restricted to explicitly declared adult use, and authenticated advertising additionally requires current adult account eligibility. No advertising SDK startup or requests are offered to declared minors or when age eligibility is unknown. A broad category is not verified age. The account eligibility category is stored on the server as described below; it is no longer accurate to describe the new account policy as solely local. Older Android versions may require an update to follow the new account policy.

When ads are enabled for eligible adult use, the lists and gifts overviews may each show a banner. Sign-in, reservations and account deletion are not interrupted by ads. Required consent choices appear before requests, with advertising privacy options available later. The app requests non-personalized ads capped at Google's “G” content rating; this does not independently verify age or certify every creative. Google may process IP addresses, coarse location, device identifiers, consent, advertising and interaction data, and technical crash/performance diagnostics. The iOS Mobile Ads privacy manifest declares some identifiers as linked and used for tracking and other data for analytics; requesting non-personalized ads alone does not establish absence of provider tracking. UMP also declares technical functionality data. These provider declarations must be assessed with the exact configuration and compiled app. See the Google privacy policy and iOS AdMob privacy guidance. Where consent is required, processing relies on Article 6(1)(a) GDPR and can be withdrawn for the future.

Optional videos may offer extra capacity when a limit is reached. A random, short-lived operation identifier is sent to Google; it contains no name, email address, product links or list titles. Google sends a signed reward confirmation with operation, ad and transaction identifiers and a timestamp to the backend. Only after verification is extra capacity assigned to the account or selected list. Firestore stores the capacity association and technical evidence to prevent duplicate grants. Account deletion cleans up these associations. Completing a video dialog alone does not guarantee a grant.

Premium purchases

Premium is offered in supported native versions through Apple StoreKit or Google Play Billing. A purchase is possible only when the relevant store provides the product and purchase dialog and purchase verification is available. Standard euro plans are €1.99 per month or €14.99 per year; the price, currency, period and renewal terms displayed in the relevant store purchase dialog are binding. A server-verified active membership is ad-free and has no Wunschkiste-imposed count limit on boxes or wishes. Technical overall capacity, abuse protection, request, file and image limits remain and may temporarily prevent actions. A preview or an unverified purchase message does not unlock Premium.

Store test purchases in Apple’s sandbox or Google Play licence testing are accepted only for explicitly server-allowlisted technical test accounts. Installing a beta or joining a test group does not automatically grant that permission. Test and production purchases are verified separately; a test confirmation does not confer a paid production membership.

The relevant store handles purchase payments. Wunschkiste receives no complete payment-card or bank-access credentials. For verification and restoration, the backend processes a random purchase-account identifier, internal account association, store and test/production environment, product or plan, original and current transaction identifiers or Google purchase tokens, a linked purchase identifier where applicable, and status, expiry, check and provider data including revocation and refunds. These details are checked through authenticated Apple or Google server interfaces. The purchase-account identifier is sent to the store for association. Current purchase records and this identifier are removed on account deletion, except for the anti-reuse record described below. Processing serves the requested membership and protection against duplicate or another account's purchase use under the legal bases explained above.

Retention and deletion

After a Premium purchase, account deletion retains a private anti-reuse record: a SHA-256 digest of the store, environment and original purchase identifier, the deleted internal account identifier, a provider timestamp and, where applicable, the identifier of a revoked transaction. It contains no name, email address, raw Google purchase token or random purchase-account identifier. It cannot sign in to or restore the deleted account. The current flow has no automatic expiry for this record, so deletion after a fixed further period is not promised. Contact the controller with questions about its continued necessity or erasure.

Accounts, lists and wishes are retained to provide the ongoing service until deleted through the available features or following a justified request. Archiving hides a list from the active overview and does not delete data; invitations and reservations remain accessible. Removing individual wishes may initially allow restoration. Uninstalling the app or clearing local data does not replace server deletion.

The new provider sign-in flow stores the latest limited consent record in the account, including the explanation version, provider, consent time and acknowledgment time. An additional bounded proof per device session supports safe retry after a lost server response and includes technical verification hashes. No unbounded consent history is created. The account record remains until replaced by a newer record or account deletion. The session proof remains until replaced, cleanup of the relevant session or account deletion. They are separate from the technical operations described above that are usable for only ten minutes.

Deleting an account removes its associated lists, wishes, uploaded cover, wish and profile photos, device sessions, delivery associations, settings, stored notifications and invitations; its reservations in other people's lists are released. For Firebase accounts, deletion of the associated Firebase Authentication account is also initiated. An Apple-associated account requires fresh Apple confirmation for the same account and confirmation of provider revocation. Your general Google or Apple Account is not deleted. Other people's independent lists are retained. Deletion may require several steps; the app confirms completion only after successful server confirmation. Minimal technical deletion and blocking identifiers may remain to prevent old credentials from being reused. Details and a contact method outside the app are available under Delete account and data.

After confirmed image removal, the private image store may retain empty objects with zero image bytes and bounded technical deletion fences. They prevent a delayed upload from restoring a removed image under the same object identifier. These records may include internal owner, list/account, resource and object identifiers and bounded status and capacity data; the fence contains no image content, names or email addresses and cannot sign in to or restore a deleted account. Historically occupied object slots are not released by removing an image. These technical fences currently have no automatic expiry, so complete removal of every technical reference or later release of all capacity is not promised. Contact the controller with questions about their continued necessity or erasure.

Google states that Firebase Authentication retains logged IP addresses for a few weeks. Other authentication data is kept until user deletion is requested and then removed from live and backup systems within 180 days. For Firebase Cloud Messaging, Google retains installation identifiers until an explicit identifier-deletion request; a provider period of up to 180 days then also applies. Removing the Wunschkiste device association is separate from deleting this identifier. The app's completion confirmation does not promise immediate removal of all provider identifiers or backup copies. Source: Firebase privacy notice.

Security data and support messages are retained only while necessary to handle requests, protect the service or fulfil legal obligations. Technical backups may contain deleted data until they are overwritten normally. You can ask the controller for specific information about retention of your data.

Your rights

Subject to the legal requirements, you have rights of access, rectification, erasure, restriction of processing and data portability. You can object to processing based on legitimate interests on grounds relating to your particular situation. Where processing is based on consent, you can withdraw consent with effect for the future.

Contact dev@timonply.com to exercise your rights. Do not send passwords, account keys or complete identity documents. Appropriate verification of permission may be required to protect your data and other people's data. You can also complain to a data protection supervisory authority, such as the North Rhine-Westphalia Commissioner for Data Protection and Freedom of Information.

Children and shared planning

Own photo uploads at 13–17 require explicit parent permission in addition to account approval. The photo declaration and its version are associated with the existing parent/child relationship as a bounded permission record; earlier general account approval does not retrospectively grant photo permission. The parent can grant or withdraw photo permission in the supported family flow. Photo withdrawal blocks future own photo uploads but does not automatically erase previously stored images. To remove existing images, use the available functions or contact the controller. This recorded declaration establishes neither independently verified parental authority nor rights to a particular image. The upload and use terms apply; photo permission for minor use relies on Article 6(1)(a), read with Article 8 GDPR, and can be withdrawn for the future.

Children under 13 use a responsible parent's account. For own accounts at 13–17, the supported registration flow requests parent approval before collecting the child's account name, email or password or beginning a new provider registration. It shares a short-lived parent review link and a comparison code. The parent must sign in with a verified adult-declared account, confirm the matching code, and explicitly state adult status and parental authority. Verified email and these statements are documented assertions; they are not independent identity or guardianship verification. No date of birth or identity document is requested.

Cloud Firestore stores bounded request records with hashed parent and child capabilities, age category, comparison code, policy version, status and a 24-hour expiry. The parent link contains a sensitive review capability: share it only with your parent. It is removed from the displayed web address after opening; it can still exist in the initial request or browser history. Firestore stores adult declarations or approved minor eligibility, parent/child account and Firebase UID bindings, approval and revocation times, and a bounded family association. These records implement consent under Article 6(1)(a), read with Article 8 GDPR, and security under Article 6(1)(f). An adult's ordinary account service relies on Article 6(1)(b).

The web family/sign-in flow stores Firebase access and refresh tokens, the application session capability and pending approval capabilities in sessionStorage for this browser tab. This is separate from native device Keychain protection. Browser session restoration can retain tab data. Sign out on shared devices; do not share the tab or parent link. No password is saved there. Withdrawal blocks ordinary content operations; sign-in for recovery, logout and account erasure remains available.

Parents can withdraw an approval in Family after fresh sign-in. Withdrawal blocks the child's application access, new data changes and future push admission. It does not erase previously shared lists or copies held by others, recall accepted operating-system messages, or delete the account. Account erasure is separate. This version does not promise restoration of a withdrawn approval. Deleting a parent account also withdraws its associated approvals; deleting a child account removes its identity associations. A minimal hashed anti-replay receipt may remain until the original 24-hour request expiry, then is reclaimed on access. Bounded approval/withdrawal records otherwise remain with the family/account until erasure or applicable expiry.

Existing accounts without eligibility can sign in for recovery, logout and erasure, but cannot use ordinary content features before confirming adult eligibility or a valid parent approval. Guest use in the new supported flows requires an explicit adult declaration; this is not proof of age. Public invitation links can be forwarded and do not independently verify a viewer's age. Share only necessary information, without a child's full name, address, birth year or photo. The current app implementation does not globally block Firebase's public registration API: the supported client flow and Wunschkiste backend enforce application eligibility. If a child creates a Firebase identity after approval but abandons verification or the request expires, expiry does not automatically erase that identity. Contact the controller for help with deletion; no automatic background cleanup is promised.

Questions and changes

For questions, contact dev@timonply.com. These notices will be updated if features or data processing change. The date at the beginning indicates the document revision.

Reports, blocks and content review

The iOS app’s safety features use the existing Firestore backend. A report contains a reason, optional description, the affected box or wish identifier and a bounded content excerpt. Technical request identifiers support retrying the same report after connection problems. Raw passwords, authentication tokens and private invitation keys are not included in reports. Blocks are associated with your account or a server-hashed guest capability; other users do not receive the reporter’s identity. Management may show the already known box title if it remains allowed.

A word and link filter limits objectionable content but does not replace complete review. Guests continue to see a preset cover until an operator approves the exact uploaded cover version. Replacements require new approval. Uploading therefore does not mean a photo is already publicly visible. Blocking applies to the particular access identity; anonymous guest capabilities are not verified person identities and can be replaced. Previously shared copies cannot be recalled.

The queue and receipts are bounded. New requests are rejected at capacity; capacity is not automatically expanded. Closed reports are intended for manual cleanup after 90 days; open reports remain until handled. There is no automatic deletion job. Own blocks are removed upon confirmed account deletion, and a bounded pseudonymous reporter reference remains in received reports after account deletion until handling or manual cleanup; it cannot be used to sign in. Necessary evidence about another user’s reported content may remain to handle reports and defend legitimate claims. The legal bases are providing the safety functions and legitimate interests in preventing abuse under Article 6(1)(b) or (f) GDPR.

The browser retains at most one pending report draft with a hashed access association and bounded description in the current tab. iOS retains a bounded number of pending drafts in the device Keychain for exact retries. A report is not shown as delivered before the backend confirms receipt. Confirmed account deletion removes local iOS drafts associated with that account. Activation and the actual operator response process must be checked before public availability.