Exposed

Privacy Policy

Exposed: Who’s Most Likely To

Last updated: October 22, 2026

Exposed works without an email or password login or your real name. Online play uses an automatically created guest identity and shares your player card and game activity. Optional usage analytics and Sentry crash reporting depend on your consent. Subscriptions, online play and platform game services involve other processing described below. Deleting local data and deleting server data are separate steps that can succeed or fail independently.

The controller responsible for the processing described in this policy is:

Mustafa Berkay Mutlu
Jerusalemer Straße 43, 10117 Berlin, Germany
Email: privacy@laughter.app

These are also the App provider’s contact details for the legal notice under section 5 of Germany’s Digitale-Dienste-Gesetz (DDG). The full Legal Notice (Impressum) is on its own page. Contact us for privacy questions, complaints or to exercise your rights. The Terms of Service provide further service information. Apple, Google and other recipients may also act as independent controllers for their own services, as explained below.

2. Information and where it comes from

Information on your device

The App stores your chosen player name and avatar, an optional selected photo, saved players, game history and statistics, saved custom-question entries, seen-question records, game and deck preferences, sound and accessibility settings, onboarding choices and your privacy choice. It also keeps technical settings, purchase-access state, cumulative achievement counters and records used to control App prompts and reconnect to games.

Your local profile and game records are not an Exposed cloud account. However, selected information leaves the device when you play online, report a question, use platform game services, make or restore purchases, enable optional telemetry or choose to share an image or export. A one-device game does not mean the App makes no network requests.

Device backup or transfer services can retain copies separately. Android backup remains enabled for most App data, including the pending-deletion records introduced in version 1.6.1; multiplayer credentials are excluded. After a successful local deletion, version 1.6.1 asks Android to schedule a replacement backup. This is not immediate backup erasure: an older backup may remain and restore old data until it is replaced. Uninstalling the App does not delete our server records, store purchase records, exported files or copies held in device backups. Secure device storage may also survive an uninstall, depending on the platform.

App-generated identifiers

The App generates a random device identifier for local records and question feedback. It also creates a Support ID during onboarding, including when analytics is declined, and can create one when consent is later enabled. With consent, the Support ID links analytics and crash reports so we can investigate a support request. Analytics providers may also generate technical identifiers of their own.

Online play uses a separate random multiplayer device identity and a credential stored on your device. Our server keeps a verification value for that credential, an optional link to the earlier App device identifier, platform, App build and creation and last-use timestamps. The credential is sent securely to the multiplayer service when needed to prove control of the identity. It is not an email or password login.

These identifiers are pseudonymous personal data, not anonymous data. In particular, a multiplayer identity can be linked to your player name, photo and activity within a room.

Online multiplayer and photos

Supabase handles rooms, access codes, settings, player names and avatars, optional photo URLs and files, membership and connection records, selected questions, rounds, votes and results. Other participants receive player cards and game information through the multiplayer features. Information about you may also come from other players, for example when someone includes you in a shared-device game or votes for you.

When you enter an online room, the App can upload your saved profile photo for your room player card. Uploaded avatar photos use public URLs. Anyone with the URL can access the photo while it remains available, without joining the room. Clearing the displayed photo removes its reference from the player card but does not itself delete the stored server file. Participants can save photos, results or screenshots. We cannot erase copies independently saved by someone else. Choose a nickname and omit a photo if you prefer. Only share another person’s information when you are entitled to do so, and show them this policy where appropriate.

For reliable processing, the server keeps receipts for multiplayer commands, including an operation ID, acting device, room, action, payload hash, stored response, App build and timestamp. Receipts can contain references to other participants. For abuse prevention, registration and failed room-code attempts use a hash of the network IP address, timestamps and, for failed joins, the multiplayer identity. Hashing does not make this information anonymous. Network providers necessarily process IP addresses to deliver requests and may have their own infrastructure logs; the hashed-IP tables are not proof that raw IP addresses never reach a service provider.

The backend also keeps daily room counts grouped into categories such as player-count and round-count ranges. Those aggregate rows do not contain player or device identifiers.

Optional analytics and crash reporting

If you enable “Usage Data & Crash Reports”, Mixpanel receives usage events such as screens opened, game modes, deck selections, game counts, purchase and restoration outcomes, subscription-access status, onboarding choices and connection or platform-game-service outcomes. Events include the Support ID and technical information such as device and operating system, App version and build, platform, SDK details and network characteristics. Platform-game-service diagnostics can include authentication outcomes and Apple’s underage or restriction flags.

Mixpanel can derive approximate country, region and city from the connection’s IP address. Its documentation says it discards the IP address after that derivation. This is approximate IP-based location, not GPS permission or precise location tracking. See Mixpanel’s data-property explanation.

With the same consent, Sentry receives crash and error details, stack traces, App and device context, session information and breadcrumbs describing recent App activity, linked to your Support ID. The App disables default personally identifying fields and filters potentially sensitive error content. That reduces data collection; it does not make a report anonymous or guarantee that every unexpected error is free of personal data.

Purchases and RevenueCat

Apple or Google handles your store account, payment method and purchase. We use RevenueCat to check access, obtain purchase options, process purchase and restore results and maintain subscription status. RevenueCat uses a generated customer identifier rather than an Exposed account login. It processes purchase and entitlement information and associated technical information. We do not receive your full payment card details.

RevenueCat is configured independently of the optional analytics choice, including before a user subscribes. Both the Android and iOS configurations enable RevenueCat SDK performance and debugging diagnostics. These are separate from Sentry crash reporting. The attribution described below is a separate purpose even though it uses the same provider.

Advertising measurement on iOS

The App does not include third-party advertising SDKs or use device advertising identifiers such as IDFA or Android Advertising ID. The App does not display third-party ads. This does not mean there is no advertising measurement:

The iOS “Personalized Ads” setting is not a switch that disables every attribution mechanism above.

Platform game services

The current App integrates Apple Game Center and Google Play Games for achievements and leaderboards. Google Play Games initialises at Android startup. On iOS launches after onboarding has been completed, the App installs a Game Center authentication handler and can present Apple’s sign-in screen. Android also has a platform sign-in path. You can play the party game without signing in to these services. Their initialisation and authentication checks are independent of optional analytics consent.

The App checks platform authentication and submits achievement progress and leaderboard scores, including games played and times exposed, when authenticated. Cumulative local counters can support synchronisation when you later sign in. Apple can also supply underage, multiplayer gaming restriction and personalised communication restriction flags. These flags are used in game-service diagnostics; they do not enforce an Exposed age check or parental consent. Related analytics are subject to the optional telemetry consent described above. Apple and Google link achievements and scores to the relevant platform account and handle their account data under their own policies. You can manage these services through the platform’s settings.

Reports, support and sharing

When you report a question, Supabase receives a report ID, question reference, report reason, optional comment of up to 1,000 characters, timestamp, App device ID, language, platform, App version and build, content-release reference, category and question type, display context and a question-text fragment. Please avoid including other people’s personal information in a comment.

If you email us, we receive your email address, message and any attachments or identifiers you choose to include. Our contact mailbox is hosted by Google. If you choose to export or share content, the destination you select may receive player names, photos, results or other information included in the file. Those copies are outside the App’s deletion controls.

This table sets out the information required by GDPR Article 13. “Contract” means processing necessary to provide the feature you request. “Legitimate interests” means the specific interest stated in the row, subject to your rights and the required balancing assessment. It is not permission for unlimited collection. Retention below refers to our processing; independent store and platform records follow their controllers’ policies and applicable law.

Some records are removed by App functions or scheduled backend cleanup. Other periods depend on provider settings or individual requests. Where the implementation has no automatic expiry, the table says so. Such records can remain until separately deleted; this is not a claim that indefinite retention is necessary or lawful. We must honour applicable storage limits and erasure rights.

Purpose Personal data GDPR legal basis Retention or deletion criterion Recipients
Provide local play, preferences and reconnection Local profile, photo, saved players, history, saved custom-question entries, settings and App identifiers Art. 6(1)(b), necessary App functions Stored on the device until cleared or replaced. The deletion tool has the exclusions in Section 5. Secure credentials, device backups and exported copies have separate lifecycles. Primarily your device; chosen backup, export or sharing services where used
Deliver question content and requested online functions Network request and connection metadata, platform, App build and requested content-release identifier Art. 6(1)(b); Art. 6(1)(f), securing and maintaining delivery Requests are processed to deliver the content. Infrastructure logs follow provider retention settings, not an App-enforced expiry. Cached content remains until updated or cleared. Supabase and its hosting providers
Connect multiplayer participants and restore their session Player cards, optional photos, room and membership data, questions, votes, results and connection activity Art. 6(1)(b) Rooms normally become cleanup candidates four hours after creation; an empty lobby can become a candidate after two hours. Active or recoverable sessions can be retained longer. Photos follow successful cleanup. See Section 4. Supabase; room participants; anyone who obtains a public photo URL
Recognise a multiplayer installation Random multiplayer ID, credential verifier, linked legacy device ID, platform/build and timestamps Art. 6(1)(b) Deleted through a successful identity-erasure request, or selected by a daily check after 90 days without recorded activity. Active or recoverable sessions are protected; failures can delay erasure. See Section 4. Supabase
Prevent repeated commands and diagnose multiplayer faults Command receipts, acting identity, room and action, payload hash, response, build and timestamp Art. 6(1)(b) for reliable requested actions; Art. 6(1)(f) for diagnosing faults and preventing duplicate operations Receipts older than 30 days are selected for scheduled deletion; the caller’s receipts are also removed on successful identity deletion. Cleanup failures can delay removal. Supabase
Prevent registration abuse and room-code guessing Hashed IP, timestamps, failed-join device ID Art. 6(1)(f), protecting players and service availability Rows older than 24 hours are selected for cleanup. Failed-join rows also cascade on identity deletion. Unlinked registration hashes are not erased by the in-app identity deletion. Supabase and relevant infrastructure providers
Check and document room cleanup Room IDs, avatar-path references, object fingerprints, job timestamps, status and removal outcomes Art. 6(1)(f), completing and troubleshooting deletion safely No automatic expiry is implemented for these cleanup records. Completing room deletion does not itself remove them. Supabase
Resolve question reports Report and question context, optional comment, device ID and technical fields listed above Art. 6(1)(f), correcting and moderating game content No automatic report expiry is implemented. Reports remain until separately removed, including by a successful deletion request. Supabase; developer reviewing the report
Prevent erased question reports from returning One-way digest of the erased App device ID Art. 6(1)(c), giving effect to erasure; Art. 6(1)(f), preventing restored or queued data from reappearing No automatic expiry while queued submissions, restored backups or older clients can reintroduce reports. Necessity is reviewed yearly. This suppression record is pseudonymous. Supabase
Understand and improve App use Usage events, Support ID, provider identifiers, device/App data, subscription status, approximate location and game-service diagnostics Art. 6(1)(a), consent Provider event/profile settings and deletion requests determine retention; the App imposes no fixed period. Our server tracks an accepted deletion task until Mixpanel reports success or it needs manual action. Acceptance alone is not completed erasure. Withdrawal alone does not erase past events. Mixpanel
Investigate crashes and errors Support ID, errors, stack traces, breadcrumbs, sessions and technical context Art. 6(1)(a), consent Provider retention settings apply; the App imposes no fixed period. Erasure requires manual review, including provider limits for different data types. The automated in-app steps do not send a deletion request to Sentry. Email is available for this scope. Sentry
Provide and restore paid access RevenueCat customer ID, transaction/receipt and subscription information, App/device metadata Art. 6(1)(b), providing and restoring the purchase For the access, restoration and reconciliation purposes that remain necessary. App deletion does not remove these records automatically. Further retention depends on provider records and any specific legal duty, not a blanket ten-year rule. RevenueCat; Apple or Google
Diagnose subscription SDK operation on Android and iOS SDK performance and debugging information Art. 6(1)(f), identifying billing faults and maintaining reliable subscription access Provider diagnostic settings apply; there is no App-enforced expiry or automatic in-app diagnostic-erasure step. Individual erasure requests require assessment with the provider. This collection is independent of the analytics toggle. RevenueCat
Measure Apple Ads acquisition AdServices token and attribution results associated with RevenueCat customer/purchase records Art. 6(1)(a), consent Retention of tokens and linked attribution is controlled by RevenueCat’s service, with no App-enforced expiry. Contact us for erasure. Launch-time consent and withdrawal limitations are in Section 5. RevenueCat; Apple
Measure iOS campaigns through SKAdNetwork Install/engagement and broad purchase-value signals; Apple-managed attribution postbacks Art. 6(1)(f), measuring campaign effectiveness with limited conversion information, to the extent this involves personal data for our purposes Apple manages attribution windows; recipients control received reports. The App has no individual postback deletion mechanism. Apple and participating ad networks, including configured Meta, TikTok and Google networks
Provide platform achievements and leaderboards Authentication state, progress, scores and Apple restriction flags Art. 6(1)(b) for requested game-service features; Art. 6(1)(f), checking availability and supporting platform authentication at startup Platform records follow Apple/Google controls. Delete All My Data clears local cumulative achievement counters in version 1.6.1; versions 1.5.x and 1.6.0 leave that separate table in place. Consented diagnostics follow the Mixpanel/Sentry rows. Apple Game Center; Google Play Games; consented diagnostic providers
Answer support requests Email address, correspondence, attachments and identifiers supplied Art. 6(1)(b) for contractual assistance; Art. 6(1)(f), answering other enquiries As needed to resolve the request and relevant follow-up or claims. The App does not automatically erase email correspondence. Developer; Google mailbox service
Handle privacy requests and legal duties Encrypted working identifiers and contact details; request reference, dates, scope, verification method and outcomes Art. 6(1)(c), GDPR duties; Art. 6(1)(f), establishing, exercising or defending legal claims Working details are removed as described in Section 4. The minimized pseudonymous accountability record is kept for 12 months after closure, with a documented hold only for a concrete dispute. Temporary protection against reference misuse has a separate 60-day/closure rule. Particular retained data and any refusal must have a specific reason. Developer; Supabase; relevant processors; authorities or advisers where lawfully necessary

Information necessary for multiplayer or purchases is required to provide those features. You can use available local play without giving your real name, email or photo. Optional analytics and attribution consent is not required for core play or premium access. A necessary device identifier is not an advertising identifier.

Where consent is required for storing or accessing information on your device, this includes Section 25(1) of Germany’s TDDDG. Necessary storage or access for a service you expressly request is assessed under Section 25(2). A GDPR legitimate-interest basis does not itself remove a device-access consent requirement.

We do not use personal data to make solely automated decisions that produce legal or similarly significant effects about you. Game results, access checks and abuse limits are automated functions. We analyse consented usage patterns; we do not describe identifiable analytics profiles as anonymous data.

4. Retention, providers and international processing

Retention and room cleanup

Room expiry and actual erasure are different. The default expiry timestamp is four hours after creation; an empty lobby becomes a cleanup candidate after two hours. The cleanup job is scheduled every six hours. It checks whether players are online, recently active or protected by reconnection and recovery rules, and can defer removal. It removes associated stored photos before finalising room deletion. Worker failures can require retries or manual intervention. These conditions mean that a room and photo can remain beyond four hours after creation or after a game ends. Contact us if you need earlier erasure.

The backend selects command receipts older than 30 days, and registration and failed-code attempts older than 24 hours, for purging during cleanup batches. A daily check selects multiplayer guest identities after 90 days without recorded activity and uses the identity-erasure process, while protecting active or recoverable sessions. These are cleanup thresholds, not exact deletion deadlines; failed jobs can delay removal. Routine room deletion does not delete every identity or operational record. The separate room-cleanup evidence described in Section 3 still has no automatic expiry.

After question-report erasure, we keep a pseudonymous suppression record, also called a tombstone, containing a one-way digest of the App device ID. It stops reports for that erased identifier returning through queued submissions, restored backups or older clients. It has no automatic expiry while those routes can reintroduce data; we review the need for it yearly.

For a deletion request, working identifiers and contact details needed to finish the request are encrypted with keys held separately from the database. Step-specific targets are cleared when no longer needed; other operational contact, locating and action details are cleared at closure, except necessary encrypted details of a documented concrete dispute. We then keep a minimized accountability record of the reference, dates, scope, authorization method, operator, outcomes and reasons for any retention or refusal, including the encrypted rationale, for 12 months after closure. Although it no longer contains the working identifiers or contact details, it is pseudonymous, not anonymous. A justified hold for a concrete dispute may extend that period and is removed when no longer needed. Separately, a keyed digest that binds a reference to its original targets prevents misuse of that reference. It is cleared at the later of 60 days after receipt or request closure; it is not a field retained for the full 12-month accountability period.

Daily aggregate room counts contain grouped counts without player, device or room identifiers and have no automatic expiry. Infrastructure logs, caches and backups follow separate provider lifecycles. Deleting live records does not immediately erase every copy. For backups we control, restored data must remain isolated until erasures recorded after the snapshot have been reapplied; unresolved affected data must not be returned to service. Device backups in your own account and copies independently saved by others have separate controls. The App does not erase those copies or enforce a universal provider retention period. Contact us for information about retained records or to exercise your rights.

Service providers and other recipients

We use Mixpanel for analytics, Sentry for diagnostics, RevenueCat for subscriptions and specified attribution, and Supabase for hosting, multiplayer, content, feedback and privacy-request functions. For processing they perform on our behalf, they must act under the applicable data-processing agreement and our instructions. We remain responsible for our own obligations.

Recipient Location and role information Further information
Mixpanel App events are configured to use its EU ingestion endpoint. EU ingestion does not exclude international support access or subprocessors. Privacy and data-processing terms
Sentry Handles consented crash and error reports. Project storage region and service operations depend on provider account configuration; this policy makes no EU-only processing claim. Privacy and trust information
RevenueCat Subscription, attribution and enabled diagnostic processing involves the United States and its service infrastructure. Privacy and data-processing terms
Supabase Hosts backend data and storage and runs server functions. Its current data-processing terms identify Supabase Pte Ltd in Singapore. Database storage, edge execution, file delivery and support can involve different locations; this policy makes no EU-only processing claim. Privacy and data-processing terms
Apple and Google Independent controllers for relevant store, payment and platform-account services; international processing under their policies. Apple privacy and Google privacy
Google mailbox service Processes correspondence sent to our support email address; its own service and account processing is governed by the applicable Google terms. Google privacy
Other players, chosen sharing destinations and attribution networks Recipients for the specific actions and mechanisms described in Section 2, not a blanket permission to reuse your data. Their own services and policies apply to independent processing.

Some processing can occur outside the EEA, including in the United States and Singapore. Using an EU collection endpoint does not exclude international support access or subprocessors. Transfers requiring protection under data protection law must be covered by an adequacy decision or appropriate safeguards, such as the European Commission’s Standard Contractual Clauses, with supplementary measures where needed. A Data Privacy Framework adequacy route applies only to a recipient with a valid certification covering the relevant processing. UK transfers require the applicable UK mechanism, such as an eligible adequacy route or contractual safeguards with a UK Addendum or IDTA.

The linked provider data-processing terms describe available contractual safeguards and subprocessors. They do not mean that every destination has an adequacy decision. Contact us for the mechanism relevant to your data or a copy of the applicable safeguards, subject to necessary redactions.

5. Your choices and data deletion

“Usage Data & Crash Reports” is off by default. You can change it in Settings under Privacy. Declining it does not prevent you from using the core game. Switching it off stops new App usage events and Sentry reporting through the App’s consent controls. The App attempts to send a consent-change event before those services are shut down. Withdrawal does not make earlier lawful processing unlawful, and it is not a request to erase information already received.

Apple Ads token collection is enabled at App launch when consent is on. The current integration does not disable an already enabled attribution session immediately when you change the setting. Fully close and reopen the App so the next launch uses your updated choice. This does not erase attribution already received or cancel a request already in progress. Contact us for help with withdrawal or erasure. SKAdNetwork, RevenueCat subscription processing and diagnostics, online play and platform game services are not switched off by the analytics toggle.

Download My Data

Settings, Privacy, “Download My Data” creates a PDF containing available local profile information, game summaries, selected preferences, question reports and identifiers. It also has an “Online Rooms” section. If the device has a multiplayer identity, the App asks the server for that identity’s data and shows the online device ID, the registration and last-use dates, each room joined with its date and the player name used, and the number of game actions sent. If the device has no multiplayer identity, the section says so. If the server cannot be reached, the section says the data could not be loaded.

The PDF is a useful access summary. It is not a complete export of every provider’s records and is not by itself a machine-readable portability response. It does not embed every local photo or custom question. It does not list the linked earlier device ID, platform, App build or the content of individual command receipts. Email us for additional access information or, where the right applies, a structured, commonly used, machine-readable copy such as JSON or CSV.

Delete All My Data

Open Settings, Privacy, “Delete All My Data” to initiate deletion, including your automatically created multiplayer guest identity. This attempts to clear local player and game records, preferences, custom questions, seen-question records and the selected local photo, and turns off optional analytics and crash reporting. It also requests erasure of question reports linked to the App device ID and Mixpanel data linked to the Support ID. Local deletion, server receipt and completed erasure are different outcomes.

Version 1.6.1: After you confirm, the App captures the original identifiers, immediately opts out of optional telemetry before sending remote requests, and writes a pending-deletion record before clearing local data. That record preserves the original request targets and reference code. Local cumulative achievement counters are also cleared. If a remote step can be retried, the App tries on a later launch when online, at most once per launch and once per 24 hours, for up to 30 days from the request. Retries target the original identifiers and any separately protected old multiplayer credential, never a new identity created after onboarding again. The pending record remains separate from the local data being cleared. Missing or unreadable credentials, authorization problems and expiry can require action instead of automatic retry; Settings provides the reference and support route. Contact us with that reference if deletion needs action or remains unconfirmed. You do not need to enable analytics.

Installed versions 1.5.x and 1.6.0: These versions do not have the 1.6.1 journal, persistent reference or daily retry. Clearing local identifiers prevents the App from repeating a failed question-report or Mixpanel request. Their local-completion message does not establish server completion, and they leave the separate local achievement-counter table in place. Version 1.6.0 can retain its multiplayer credential when deletion is unconfirmed so you can try that step again. Contact us for older, skipped or unsuccessful requests. The server can still continue a request it has durably received, even when the older App cannot retry it.

Multiplayer erasure requires proof of control through the stored credential or separately verified operator authority. It does not require a Support ID or analytics consent. Successful erasure removes the guest identity, its room-player memberships, dependent failed-join records and command receipts created by that identity, and handles departure from a live room. Version 1.6.1 keeps old credentials apart from new play while erasure is pending and attempts to discard them after confirmation or when its 30-day retry window expires. Protected-storage failures can require further help. If a credential is lost or unreadable, use the email path below rather than sending the credential to us.

Once our server has durably received work, it continues independently of App launches and the client’s 30-day retry window. Mixpanel acceptance means a deletion task was accepted and its tracking ID saved. Our server checks that task until Mixpanel reports successful completion or manual action is required. The current App treats acceptance as completion of its submission step; even a successful App result does not report final provider erasure. Contact us for confirmation. Broad requests also need the manual checks described below; an automated step does not close those other scopes.

Current limitations: The App’s question-report and Mixpanel submission path needs both its App device ID and Support ID. A missing ID can leave those steps unsent, even when no analytics was enabled. A normal onboarding creates a Support ID without requiring consent, but you do not need to reinstall, repeat onboarding or enable analytics to request erasure. Email us with any reference, Support ID, export or other locating information you already have. If you have none, describe the request and we will explain what can be located and what further proportionate verification is needed. Do not email your multiplayer credential.

This action does not automatically:

These limitations do not remove your right to request erasure. Our manual process checks stored avatar files, Sentry data, RevenueCat customers and aliases, support correspondence, relevant attribution and other records within the request’s scope. Removing a photo URL is not deletion of its stored file. Sentry issue deletion does not necessarily remove sessions or every other data type; limitations require further assessment or provider assistance. Deleting a RevenueCat customer does not cancel an Apple or Google subscription. Manage cancellation through the store. We assess retained data individually and explain the specific reason, remaining scope and available remedies. Technical inconvenience, a missing provider API or the existence of a subscription is not a blanket exemption from erasure.

Uninstalling alone does not request server deletion and does not guarantee removal of secure storage or backups. You can request deletion without reinstalling at our support page or by emailing privacy@laughter.app. Email is also available for requests the App cannot complete. A new request reference or a later manual follow-up does not restart the deadline for an existing request.

6. Your privacy rights

Where applicable under the GDPR, you can request access and a copy, correction, erasure, restriction of processing and data portability. You may object to processing based on legitimate interests because of your particular situation. We will stop that processing unless we can demonstrate an overriding lawful ground or a need for legal claims. You may withdraw consent at any time without affecting earlier lawful processing.

Email privacy@laughter.app. You can correct your local name, avatar and photo in the App; contact us about other records. For the limited purpose of deleting question reports, we accept possession of the random App device ID; for Mixpanel analytics erasure, we accept possession of the random Support ID. This is proportionate for those pseudonymous records because there is no email login or reliable additional ownership link, and the deletion response does not reveal whether matching records existed. Intake is rate-limited to reduce abuse. Those identifiers do not establish authority over multiplayer identities or every other record. For other scopes, they can help locate data, while a credential or proportionate operator verification establishes authority. Email arrival alone is not proof of ownership. We protect other people’s information and ask only for information reasonably needed for the specific request, without requiring government ID, reinstallation or analytics consent as a routine condition.

We respond to GDPR requests without undue delay and normally within one calendar month of receipt. If legally permitted because of complexity or the number of requests, we may extend by up to two additional months, explaining the extension within the first month. Requests are normally free; any lawful exception, partial refusal or necessary retention will be explained. An email address is optional for an in-app request; without a contact channel we may be unable to send an individual notice, so keep any reference to ask for an update.

You can complain to a supervisory authority, particularly where you live or work or where an alleged infringement occurred. You need not complain to us first. The authority responsible for us, based on our Berlin address, is the Berliner Beauftragte für Datenschutz und Informationsfreiheit, Alt-Moabit 59-61, 10555 Berlin, Germany. Its official contact page provides contact and complaint information. Your right to approach another competent authority remains unaffected. UK users can contact the ICO.

7. Children and teenagers

The App is not intended for children under 13. Store ratings describe content suitability and may differ between countries or stores. They are not an age-verification or parental-consent system. Exposed does not ask you to enter a birth date or independently verify a parent’s consent.

For consent-based processing, Germany’s age of digital consent is 16. Other countries have different rules. If you are under the applicable age, do not enable optional analytics, crash reporting or Apple Ads attribution unless the legally required parental authorisation has been obtained. The App’s toggle alone does not verify that authorisation. Until an appropriate process is available, leave optional consent off.

If you believe a child has provided data that we should not process, contact us. We will investigate and take the steps required by law, including stopping processing and deleting data where appropriate. We do not claim that a statement in this policy or a platform game-service restriction flag fulfils every children’s privacy or age-assurance obligation.

8. California and other regional rights

Where the California Consumer Privacy Act, as amended by the CPRA, applies, California residents can request to know and access personal information, delete it, correct it, and exercise applicable rights to opt out of sale or sharing and limit certain uses of sensitive personal information. You may use an authorised agent and must not be unlawfully discriminated against for exercising these rights.

Current categories include identifiers and IP-related data; internet or network activity and diagnostics; commercial information about purchases; approximate location derived from an IP address; and information you provide, such as player names, photos, reports and correspondence. Sources, purposes, recipients and retention are described in Sections 2 to 4. A photo is not used by the App to perform biometric identification. Please do not submit sensitive information in free text.

We do not sell personal information or use it for cross-context behavioural advertising. Apple’s attribution mechanisms described above still operate; this statement is not a claim that no information reaches advertising measurement systems. The categories above describe current App processing. You may also request information about collection and disclosures during the legally applicable reporting period.

Send a request to privacy@laughter.app, or use the in-app tools for the functions described in Section 5. We may verify your identity and an agent’s authority proportionately. Where the CCPA applies, we normally respond within 45 calendar days; a permitted extension of up to another 45 days will be explained. Applicable opt-out requests follow their own deadlines and verification rules. We will handle any applicable recognised opt-out preference signal as required by law.

UK users retain their rights under applicable UK data protection law. Where Brazil’s LGPD applies, you can ask for confirmation of processing, access, correction, applicable anonymisation, blocking, deletion or portability, information about recipients and consent choices, and withdrawal of consent. Contact us at the address above; you can also contact Brazil’s ANPD. Other mandatory regional rights remain available. We do not claim an automatic exemption from local privacy law because the developer is a small business.

9. Security and changes

The App uses secure network connections and protected storage for multiplayer credentials. Access controls, data minimisation and diagnostic filtering help protect information. No system can guarantee complete security. Public photo URLs and other players’ copies have the specific limitations explained above.

We may update this policy when the App or its data practices change. We will state the effective date and give notice of material changes as required by law. Where a new purpose requires consent, we must obtain that consent before processing for that purpose. Continued use of the App alone is not consent to new optional processing.

This policy is written in English. Mandatory local-language and privacy protections remain unaffected.