تم التحديث قبل 4 ساعات

ConKarma — Privacy Policy

Effective Date: April 25, 2026 Last Updated: September 25, 2026

This Privacy Policy explains how XTZ Group, Inc. ("ConKarma", "we", "us", "our") collects, uses, shares, and protects personal information when you use the ConKarma mobile application, related websites, and APIs (the "Service"). It applies globally and is supplemented by region-specific notices where noted.

By using the Service you acknowledge that you have read this Policy. Where consent is the legal basis for processing (for example, for sensitive data, marketing, or cookies outside strict necessity), we will ask for it separately.

1. Who We Are and How to Reach Us

• Controller: XTZ Group, Inc., 2261 Market Street #4524, San Francisco, CA 94114, USA.
• Privacy contact: legal@conkarma.app
• EU / EEA representative: to be appointed prior to EU launch (GDPR Art. 27) (appointed under GDPR Art. 27).
• UK representative: to be appointed prior to UK launch (UK GDPR Art. 27) (where applicable).
• Data Protection Officer: not appointed (no statutory trigger under GDPR Art. 37) (where appointed).

2. Information We Collect

We collect the following categories of personal information.

2.1 Information you provide directly.

• Account data: email address, password hash, display name, birthday (used to calculate age and to gate adult features), optional profile avatar.
• Cell / family data: Cell name, role in the Cell (parent, partner, child), relationships you choose to record.
• User-generated content: journals, annals, missions, duties, experiences, rules, penalties, fantasies, kinks, desires, stories, moments, mood check-ins, goals, templates, images, comments, voice notes, and reactions.
• Communications: direct messages with other Cell members, feedback you send us, customer-support correspondence.
• Purchase data: we do not receive card details; Apple and Google provide us with a transaction identifier and purchase status.

2.2 Information collected automatically.

• Device and technical data: device model, operating system, app version, language, time zone, coarse network type, crash logs and stack traces, performance metrics.
• Usage data: features opened (via feature_opened events), actions taken, pages viewed, session timestamps, authentication events, haptic / sound / density preferences. Usage analytics for the everyday (Serene) zone flow to Google Analytics 4; adult-zone (Ember) usage metadata flows to GA4 only if you turn on the separate adult-analytics opt-in described in §2.4, and then only as anonymised, surface-level, no-content metadata under a pseudonymous identifier.
• Identifiers: a ConKarma user ID, Firebase installation ID, Firebase Cloud Messaging token, and — only where you grant OS-level permission — the advertising identifier (IDFA on iOS, AAID on Android). For free accounts, Google AdMob serves banner, interstitial, and rewarded-video ads using these identifiers, per a BE-owned ad policy: free adult accounts may receive personalised ads unless you exercise Do-Not-Sell / Do-Not-Share (including Global Privacy Control); free teen (13-17) accounts receive only non-personalised ads. No advertising of any kind is shown on child accounts, and no ad identifiers are collected from them. Premium / family-plan subscribers see no ads.
• Approximate location: derived from your IP address for anti-fraud, localisation, and legal compliance (including US-state child-safety gating). To resolve it, we send your IP address to our GeoIP sub-processor, freeipapi.com (operated from Germany), which returns a coarse country / region / city; only the IP is sent, and the result is cached briefly. We do not collect GPS-level location. See the sub-processor list.
• Cookies and similar technologies on the web version: strictly-necessary authentication cookies and (with consent where required) analytics storage.

2.3 Information from third parties.

• Authentication providers: if you sign in with Apple or Google, ConKarma's backend acts as the OpenID Connect client and communicates with the provider directly — there is no third-party authentication broker in the path. We receive only the provider's subject identifier, your email address (or Apple's private-relay address if you choose to hide it), and the email-verified flag; we then issue our own access and refresh tokens.
• Platform vendors: Apple and Google may share transaction and abuse-signal data.

2.4 Adult-zone configuration data.

For users who have access to the adult zone ("Ember"), we additionally collect:

• Per-device adult-zone enable state. Default is OFF on every device except the primary one; you opt in per device on the first adult-zone access on that device. We store the flag and an audit log of changes (device_id, enabled, changed_at).
• Retention preference. A user-configurable adult-zone retention window (default 3 years; user-selectable from 90 days up to 10 years). Stored as a single integer.
• Backup-exclusion preference. Local pref recording whether you have asked us to set NSURLIsExcludedFromBackupKey on adult-zone files (default OFF).
• GDPR-export preference. Server-side flag recording whether your /me/export response embeds adult-zone rows (default OFF — exports stay sharing-safe).
• Adult-zone usage analytics (separate opt-in, default OFF). If — and only if — you give the separate, explicit adult-analytics consent (Settings → Ember privacy; default OFF, distinct from the age gate), we send anonymised, quantitative, surface-level metadata about your adult-zone feature usage to Google Analytics 4 (GA4): which Ember feature or pillar you opened and a coarse action verb (for example opened / started / completed / abandoned), together with non-identifying cohort buckets and experiment-exposure records. This stream carries a pseudonymous GA4 client identifier only — never your ConKarma user ID, name, contact details, or device identifiers — and never any user-generated content, free text, or content/act-level detail: we record that a feature was used, never which specific content, act, or scene. Because it can imply a special category of data, we process it only under your explicit consent (Art. 9(2)(a)), as a separate opt-in you can withdraw at any time in Settings → Ember privacy. Google Signals, ads-personalisation, and Google data-sharing are switched OFF for this stream — adult-zone metadata is never used for advertising. If you do not turn this on, the adult zone sends no analytics to GA4.

These preferences let you control the security posture of your adult-zone data; we do not change them on your behalf.

2.5 Health & Fitness data (opt-in only).

If you choose to connect ConKarma to your platform health store — Apple HealthKit on iOS, Google Fit or the Health Connect API on Android — and you grant the system permission for specific categories, we read only the categories you pick from the following list, only the daily totals, only while the app is in the foreground:

• Steps
• Distance (in metres)
• Active minutes
• Sleep hours
• Mindful minutes

We use these read values to auto-complete fitness-tagged missions, duties, or experiences when your daily total crosses the threshold you set on the entity. We do not write back to the platform health store. We do not keep raw health data on our servers — only the derived "did the threshold cross today, yes/no" signal. You can revoke any category at any time from the system Settings (iOS: Settings → Privacy & Security → Health → ConKarma; Android: Settings → Apps → ConKarma → Permissions → Physical activity / Health Connect), and the auto-complete flow simply stops working for that category. Categories you never grant are never read.

3. Children's Privacy

We apply heightened protections to accounts belonging to users under 13 (under COPPA) and to users under 16 or the local "digital consent" age under GDPR / UK GDPR.

• A child account can only be created or claimed via a verified Parent (see Section 4 of the Terms of Service).
• We collect the minimum data needed to operate the child's in-Cell experience: display name, age bracket, avatar, and the in-app activity they produce.
• We do not serve advertising of any kind — personalised or non-personalised — to child accounts. The Google AdMob SDK is not initialised on child accounts; the BE-side ads-config endpoint returns all ad-format flags as false for child callers (Apple Designed for Children + Play Families Policy compliance).
• We do not enable third-party analytics personalisation on child accounts; Firebase Analytics is configured for the child account with ad-storage and analytics-storage disabled except for strictly necessary service telemetry.
• We do not sell ConKarma DNA or accept real-money payments on child accounts; in-app purchases (subscriptions, cosmetics) are gated server-side. A child must ask a verified parent / guardian to subscribe from their own account.
• We do not sell or "share" (as defined in the CCPA/CPRA) personal information of any user under 16.
• Parents can at any time review their child's data, correct it, export it, or delete it by going to in-app Settings → Child Accounts, or by emailing parents@conkarma.app (the dedicated COPPA §312.5(b)(1)(iv) contact). We will honour verified requests promptly and in any case within the timeframes required by law. General privacy questions, DSARs, and state-law rights (CCPA, GDPR, etc.) continue to route to legal@conkarma.app.
• A parental delete-on-request on a child account triggers our immediate PII-erasure pathway, not the standard 30-day tombstone used for normal account deletion. We confirm COPPA §312.5(b)(2)(ii) compliance: the child's personal information (name, date of birth, contact details, photo URLs, journal entries, parent contact, and any other PII fields) is nulled in a single transaction the moment the request is verified. The request is gated by a super-admin two-eye review so that parental identity is verified against the on-file Parent record (COPPA §312.5(b)(2)), preventing fraudulent erasure by a non-parent.
• After erasure, the verified parent receives an email confirmation describing the scope of what was erased and the limited retention exceptions: the audit log of the erasure event itself is retained for 7 years for regulatory inspection, and any historical financial ledger entries (DNA / EGO transactions) are anonymised via re-attribution to the cell-system user rather than deleted (IRS 7-year retention floor for transactional records). Cell-level co-owned artifacts (shared missions, family experiences, cell history) remain visible to former cell members under the cell-co-ownership invariant — these are not the erased child's personal data once the child's identity attribution has been removed.
• AI features that send a child's data to a third-party provider require separate, per-class parental consent. Some optional features described in §4 and §6 transmit content to a third-party AI provider. For a child account, each class of such processing is off unless a verified parent has granted consent for that class in the Parent Dashboard, and each may be revoked there at any time: image of child (a photograph of the child is sent to a provider), voice of child (a recording of the child, or its transcript, is sent to a provider), conversational (the child holds a back-and-forth exchange with a model), and text helper (a one-shot generation from structured app context such as a mood or a chore). Consent to one class is not consent to another. Where an image-generation feature is offered on a child account, the photograph the child chooses is transmitted to the selected provider only under the image of child consent, solely to produce the image asked for; the provider does not use it to train its models and does not retain it beyond the request, the source photograph is discarded within 24 hours on our side, and no biometric template, face template, or faceprint is derived from it — the same terms as §6. Parents can see which classes are granted, and revoke any of them, at Settings → Child Accounts.
• Parents may withdraw consent at any time, which will result in deletion of the child's account via the same immediate PII-erasure pathway described above. Withdrawing the overall parental consent also withdraws every AI consent class described above at the same moment; the two controls are not independent, and a parent who has revoked consent to the Service does not leave any AI permission standing.

For the complete child-account retention schedule, see our Children's Data Retention Policy at /legal/coppa-data-retention.

4. How We Use Personal Information

We use personal information to:

• Create and operate your account and your Cell.
• Provide core features: tasks, gamification, messaging, adult features for eligible adults, rewards, notifications.
• Authenticate you and protect the Service against abuse, fraud, and unauthorised access (including TLS pinning telemetry, App Check signals, rate-limit enforcement).
• Send transactional communications (push notifications via FCM, in-app notifications via SSE, email for password reset and security events).
• Diagnose crashes and performance issues (Crashlytics).
• Measure feature usage at an aggregate level to improve the Service (feature_opened, feature_action).
• Generate content you ask us to generate, using third-party AI providers behind our vendor-neutral AI Gateway — written content (weekly recaps, coaching prompts, voice-memo and voice-journal summaries), transcripts of audio you record, and, where offered, an image generated from a photograph you upload. AI generation always runs on content you submit for that purpose; we do not generate from your content without you asking. See §6 for the providers and the data each one receives.
• Screen user-submitted content for child-safety before it is shown to others (AI safety-moderation), covering free text you submit and images you upload. See §6 for what is transmitted and what is retained.
• Auto-complete fitness-tagged missions, duties, or experiences from your platform health data (HealthKit / Google Fit / Health Connect), when you have opted in to the relevant categories. The threshold check happens locally on your device against the daily total returned by the platform — we don't store raw health values server-side.
• Enforce our Terms of Service and comply with legal obligations.
• With your separate opt-in, send product updates or research invitations.

Persona inference (for surface ordering, never targeting). When you answer the persona question during onboarding (parent, couple, sandwich-generation, self, kid, co-parent, grandparent), we store the answer to decide which feature areas surface first inside the app. We do not share the persona with any third party, sell it, or use it for cross-context behavioural advertising. If the app ever infers a persona from your behaviour (rare; only used for surface ordering inside the app), the inference is visible in Settings → Persona with a one-tap correction. Changing your persona re-orders surfaces; it does not destroy data. The full transparency narrative lives at /how-we-onboard.

5. Legal Bases (GDPR / UK GDPR)

Where GDPR or UK GDPR applies, we rely on the following legal bases:

You may withdraw consent at any time without affecting the lawfulness of prior processing.

6. How We Share Personal Information

We do not sell personal information. We share it only as follows.

• With other Cell members — this is the point of the Service. Content you post to the Cell is visible to Cell members you address it to. Direct messages are visible to the recipient.
• With service providers acting on our instructions ("processors"), under written contracts:
  • Google LLC / Google Ireland Ltd. — Firebase Cloud Messaging, Firebase Crashlytics, Firebase App Check, Firebase Installations, Google Analytics for Firebase / Google Analytics 4. Purpose: push, crash reporting, anti-abuse, aggregate analytics. Under your separate adult-analytics opt-in (§2.4), GA4 additionally receives anonymised, surface-level adult-zone (Ember) usage metadata — pseudonymous client identifier only, no PII and no user content; Google Signals, ads-personalisation, and Google data-sharing are OFF for that stream, which is never used for advertising.
  • Apple Inc. — App Store billing, Sign-in with Apple, APNs for push delivery.
  • IONOS SE — hosting of the ConKarma backend API and web front-ends (Germany, EU).
  • DigitalOcean, LLC — application hosting (managed Kubernetes) and container registry for the ConKarma backend API and web front-ends (United States).
  • Transactional email (SMTP relay) — account, consent, and security emails (activation, password reset, magic links, parental-consent) are delivered through a standard SMTP relay service configured for ConKarma. ConKarma does not use Postmark.
  • Supabase, Inc. — backend platform and, following the 2026 re-adoption of Supabase Auth, an authentication and session processor: Supabase Auth is the social-login broker that exchanges a Google / Apple social sign-in for a ConKarma app session (processing your email address, the provider authentication identifier, and a short-lived session token), and it delivers SMS one-time codes (to a phone number in E.164 format) for adult two-factor authentication; ConKarma's own email / password sign-in and direct OpenID Connect remain available in parallel, and Firebase Authentication is not used. Supabase also provides the managed PostgreSQL database (with the Supavisor connection pooler) and object storage for user-uploaded media. Children under 13 are routed to the COPPA parental-consent flow before account creation, and phone numbers are never collected for under-13 accounts. Supabase runs the underlying compute and storage on Amazon Web Services as its own infrastructure sub-processor. See the canonical sub-processor list at https://conkarma.app/legal/subprocessors.
  • Google LLC / Google Ireland Ltd. (AdMob) — ad serving, fill, and impression measurement on free accounts only. Free adult accounts may receive personalised ads unless you exercise Do-Not-Sell / Do-Not-Share (including Global Privacy Control); free teen (13-17) accounts receive only non-personalised ads; child accounts receive no ads at all; premium / family-plan subscribers see no ads. AdMob's data handling is governed by Google's Ads Data Processing Terms.
  • Upstash, Inc. — managed Redis for the goia_api backend. Used as an ephemeral key-value cache for abuse-prevention rate-limit counters (keyed by email address or IP address), short-lived single-use codes (activation, password-reset, magic-link), and a JWT refresh-token denylist (revoked-token hashes). Retention: rate-limit and code entries expire on a short TTL (seconds to minutes); denylist entries persist until the token's natural expiry. No habit, content, relationship, or child-account data is written to Redis. Upstash runs its underlying compute on hyperscale cloud infrastructure (AWS / Google Cloud) as its own infrastructure sub-processor.
  • freeipapi.com — GeoIP resolution. We send your IP address to freeipapi.com to resolve an approximate country / region (US-state) / city, used for account-security alerts (new-device / unknown-location sign-in), sign-in risk checks, US-state child-safety gating (Family Shield and state-specific controls), and geo-targeted feature flags. Only the IP address is sent — no account, content, or relationship data — and results are cached briefly. The provider is based in Germany (EU/EEA). This replaced our former self-hosted GeoIP database, which involved no data flow to a third party.
  • AI features and safety moderation (Anthropic, OpenAI, Google — via our vendor-neutral AI Gateway) — certain optional features use third-party AI providers to (a) generate content you request — weekly recaps, coaching prompts, voice-memo and voice-journal summaries, transcripts of audio you record, where the feature is offered, an image generated from a photograph you upload (OpenAI 'DALL·E 3' or Google 'NanoBanana', selected by the same gateway), and, if you opt in to Cosmic, horoscope, numerology, birth-chart and couples-compatibility readings generated from your first name and the birth date you enter for that purpose (and, for a couples reading, your partner's first name and birth date, which your partner must have opted in to themselves) — and (b) automatically screen user-submitted content for child-safety before it is shown to others (content moderation): free text is screened for child-safety, and uploaded images are classified for child-safety by Google Cloud Vision SafeSearch (with OpenAI moderation as a fallback). For text moderation we transmit only the text being checked plus a fixed safety instruction (no account, profile, or relationship data) and retain only a one-way hash of the text and the safety verdict, never the raw text; for image moderation we transmit only the image being checked and retain only the safety verdict, not the image. This moderation ledger (hashes plus verdicts) is retained for at most 90 days and is purged when you delete your account. Image generation from a photograph you upload. Where an image-generation feature is offered, the photograph you choose is transmitted to the selected provider solely to produce the image you asked for. The provider processes it only to return that result, does not use it to train its models, and does not retain it beyond the request. On our side the source photograph is discarded within 24 hours of the generation request; only the generated image is kept, as your own cell-private content, retained and deleted on the same terms as anything else you create. No biometric template, face template, faceprint, or voiceprint is derived from it, and we do not use it to identify or authenticate you or anyone else. Cosmic readings from your birth date. The birth date you enter for Cosmic is held separately from the birthday on your account, which we use only to check your age; it is transmitted to the selected provider solely to generate the reading you asked for, under the same no-training, no-retention terms as the other AI features, and the readings are kept as your own cell-private content. Clearing the Cosmic birth date in Settings withdraws that consent and deletes the readings derived from it — including the couples readings and your partner's couple chart that were generated from your birth date. Conflict-resolution features are deliberately never AI-mediated. Where you use an AI-powered adult (Ember) feature, or where child-safety moderation applies to Ember content you submit, that processing occurs only under the explicit consent you give for adult features (Art. 9(2)(a)); we do not perform automated processing of Ember content for any other purpose without your explicit consent. See https://conkarma.app/help/ai-privacy for how AI features handle your data, https://conkarma.app/help/ai-transparency for which surfaces are AI-assisted and which are deliberately not, and the canonical sub-processor list at https://conkarma.app/legal/subprocessors.

Voice intents (Apple Siri / Google Assistant). If you choose to use ConKarma's optional voice intents on iOS (Siri / App Intents, including CarPlay) or Android (Google Assistant / App Actions, including Android Auto and Driving Mode), the audio you speak is captured and transcribed by Apple Siri or Google Assistant on your device, governed by Apple's or Google's own privacy posture. ConKarma never receives the raw audio. The transcribed text reaches the ConKarma app the same way a typed equivalent would, and we treat it identically: cell-private, encrypted at rest, not scanned by an automated content model on our side, except for the limited child-safety moderation described under AI features (which screens text you submit before it is shown to others and keeps only a hashed fingerprint, never the raw text), and never sold or shared with third parties for advertising. For details on how Apple Siri or Google Assistant handle the audio before transcription, see Apple's privacy policy (https://www.apple.com/legal/privacy/) and Google's privacy policy (https://policies.google.com/privacy). You can disable voice intents for ConKarma at any time in your device's Siri or Google Assistant settings without affecting the rest of the app.

Adult-zone (Ember) voice creation. Creating adult-zone content by voice is held to a stricter posture. Where your device supports on-device speech recognition, the spoken words are transcribed on-device and the audio never leaves your device; where on-device recognition is unavailable, the words may be transcribed by your device assistant's speech service (Apple Siri / Google Assistant) under that platform's own privacy posture, exactly as for any other voice intent — ConKarma still never receives the raw audio. Adult voice creation additionally requires biometric authentication (Face ID / Touch ID / Android biometric) before it can be used in a session. Because spoken adult content can concern your sex life, it is treated as a special category of data, processed only under the explicit adult-features consent you give (Art. 9(2)(a)), consistent with the Ember terms in your regional addendum. You can disable ConKarma's voice intents at any time in your device's Siri or Assistant settings.

Smart-home voice surfaces (Amazon Alexa / Google Home / Samsung SmartThings). If you choose to link ConKarma to an Amazon Echo, Google Nest, or Samsung SmartThings device, voice intents and routine triggers are captured and transcribed by the respective platform on the device side, governed by that platform's own privacy posture. ConKarma never receives the raw audio.

• Amazon.com, Inc. (Alexa) — voice intents from Echo devices are captured and transcribed by Amazon Alexa per Amazon's privacy posture (https://www.amazon.com/alexaprivacy). The transcribed intent metadata reaches ConKarma via our /webhooks/alexa endpoint. Once the metadata reaches ConKarma it is treated identically to typed input — cell-private, encrypted at rest, not scanned by an automated content model on our side, except for the limited child-safety moderation described under AI features (which screens text you submit before it is shown to others and keeps only a hashed fingerprint, never the raw text), and never sold or shared with third parties for advertising.
• Google LLC (Google Home / Assistant on Nest devices) — voice intents from Nest speakers and displays are captured and transcribed by Google Assistant per Google's privacy posture (https://policies.google.com/privacy). The transcribed intent metadata reaches ConKarma via our /webhooks/google-home endpoint. Once the metadata reaches ConKarma it is treated identically to typed input.
• Samsung Electronics Co., Ltd. (SmartThings) — routine triggers and metadata from SmartThings reach ConKarma via our /webhooks/smartthings endpoint. Where present, voice audio is captured and transcribed by Bixby or SmartThings on the user device per Samsung's privacy posture (https://www.samsung.com/smartthings/privacy); ConKarma never receives raw audio. Once the metadata reaches ConKarma it is treated identically to typed input.

You can disable any of these smart-home links at any time from the respective platform app or from ConKarma's Settings without affecting the rest of the app.

In-app voice notes (recorded inside ConKarma). Separately from the device-side voice intents above, you can record a voice note inside ConKarma and attach it to your own content (for example a journal entry, a moment, a check-in, or a message). Unlike voice intents, here ConKarma does receive and store the audio you record: the recording is stored on our behalf by our storage provider (Supabase) as cell-private, encrypted-at-rest user-generated content, retained and deleted on the same terms as your other content. If you turn on the optional voice-transcription setting, the recording is also sent to a speech-to-text provider behind our vendor-neutral AI Gateway — OpenAI ('Whisper') or Google Cloud Speech-to-Text — solely to produce a text transcript of that note; the provider processes the audio only to return the transcript, does not use it to train its models, and does not retain it beyond the request, and the transcript is treated as cell-private content. Transcription is off unless you enable it. Deleting a voice note removes both the recording and its transcript. For a child account, recording voice notes additionally requires the parental permission described in our Children's Privacy notice; with that permission off, no child audio is captured or transcribed.

Voice journal (spoken entries transcribed and summarised). ConKarma offers an optional voice-journal feature that turns a spoken entry into a written journal entry for you. When you use it, the audio you record is sent through our vendor-neutral AI Gateway to a speech-to-text provider (OpenAI 'Whisper', with Google Cloud Speech-to-Text as a fallback) to produce a transcript, and the transcript is then sent to a large-language-model provider (Google, OpenAI, or Anthropic — the same gateway) solely to produce a short summary that becomes your journal entry. Each provider processes the audio or transcript only to return its result, does not use it to train its models, and does not retain it beyond the request. The recording itself is stored as cell-private, encrypted-at-rest content in a dedicated audio bucket subject to a retention / auto-purge policy, and deleting the entry removes the recording, the transcript, and the summary. The feature is off unless you choose to use it. For a child (under-13) account it is blocked entirely unless the feature is expressly COPPA-eligible and a parent has given consent; with no parent consent, no child audio is captured, transcribed, or summarised.

Memory resurfacing ('On This Day'). ConKarma may occasionally resurface one of your cell's own past memories — for example a journal entry, moment, or milestone from a year ago — to your cell's Memories surface. Resurfacing only ever shows a memory to people who already had access to it; it never widens who can see anything. You can hide any individual memory, mute a specific person or a date range, or turn memory resurfacing off entirely, and content you have deleted or that has been erased is never resurfaced.

User-controlled third-party integrations (OAuth-grant only). ConKarma can optionally connect to a number of third-party services so they can power specific features inside the app. None of these are enabled by default. Each one requires you to explicitly grant access through the third party's own OAuth consent screen, each grant is scoped to the narrowest read-only permission the feature needs, and each can be revoked one-tap from ConKarma's Settings — revoking deletes the token on our side and stops all further calls. We never read more than the feature requires, we never write your data back to the third party except where you initiate it (e.g. creating a playlist), and the OAuth tokens are encrypted at rest under the same per-cell vault key used for other sensitive material.

• Spotify AB — playlist read + a "tonight's vibe" playlist generation feature. We receive only the Spotify access token (encrypted on our side), the user's playlist metadata (titles, track lists, owner display name) for the feature surfaces, and the user's Spotify user-id for idempotency. We never receive payment data, listening history outside the playlists you connect, or any other Spotify account data. Disconnect at any time from ConKarma Settings → Integrations → Spotify. Disconnecting revokes our token and clears the cached playlist metadata within minutes.
• Apple Inc. (Apple Music via MusicKit) — same playlist-read + ceremony-music-fire contract as Spotify, via MusicKit. We receive only the MusicKit user token and the playlist metadata for the surfaces you connect. We do not receive listening history. MusicKit access is granted per-device by Apple's authorisation prompt; revoking the prompt in iOS Settings → Privacy → Media & Apple Music ends our access immediately.
• Signify N.V. (Philips Hue) — scene-transition control for ceremony moments and family-rituals lighting. We receive only the Hue bridge access token (encrypted on our side) and the light + scene IDs you authorise; we send scene-fire commands. We never read raw motion / sensor data, room layout, or any other Hue account data. All calls are events-only, never streamed — that's our Integration Hub safety commitment. Disconnect any time from ConKarma Settings → Integrations → Philips Hue.
• Sonos, Inc. — speaker playback fires for music ceremonies. We receive only the Sonos access token and the household + speaker IDs you authorise; we send playback-start commands. We never read playback history outside the events we triggered, microphone data, or any other Sonos account data. Same one-tap disconnect as above.
• Nanoleaf Inc. — lighting-scene transitions for ceremony moments. We receive only the Nanoleaf device access token and the panel + effect IDs you authorise; we send effect-fire commands. Same minimal-scope + one-tap-disconnect contract.
• Apple Inc. (Photos via PhotoKit) — read-only access to user-selected albums for the photo-related features. We receive only the photo and album identifiers + the user-selected thumbnails for the album-IDs you explicitly authorise (scoped_album_ids enforcement). We never receive full photo libraries, location EXIF beyond what's in the chosen thumbnail, or any photos outside the albums you scoped. PhotoKit access is granted per-device by Apple's authorisation prompt; revoking in iOS Settings → Privacy → Photos ends our access immediately.
• Google LLC (Google Photos API) — same scoped-album read-only contract as PhotoKit. We receive only the access token, the album IDs you authorise, and the thumbnails for the photos in those albums. We do not receive your full photo library. Disconnect at any time from ConKarma Settings → Integrations → Google Photos or from your Google Account permissions page.
• Google LLC (Google Calendar API) — opt-in two-way calendar sync for cell-shared events. We request only the narrowest scopes Google offers for this purpose: https://www.googleapis.com/auth/calendar.calendarlist.readonly to enumerate the user's calendars (so they can pick which one to sync) and https://www.googleapis.com/auth/calendar.events to read and write events on the single calendar they pick. We never request calendar.readonly (full read across all calendars), calendar.acls, calendar.settings.readonly, contacts, gmail, drive, or any other Workspace scope. From the synced calendar we read: title, start / end / timezone, location (only if the cell member opts in to location sync), description (with Google Meet URLs stripped), recurrence rule, attendee list (rendered as avatars only — never emailed or notified), reminder offsets; we skip any event flagged "private" on Google's side entirely. On the write path we only write events the cell authored (events created outside ConKarma stay read-only on the ConKarma side). The integration is per-cell-member, adult-only, and gated by COPPA verification for cells with under-13 members (under-13 cell members cannot connect external calendars at all). One-tap revocation from ConKarma Settings → Integrations → Google Calendar or from myaccount.google.com → Security → Third-party apps with account access → ConKarma. Disconnecting deletes our stored OAuth tokens on our side and revokes our grant on Google's side. Full posture: /help/google-calendar-sync.
• Apple Inc. (Family Sharing) — suggested-cell-member read used only on the COPPA-parental-consent flow and the family-cell suggestion screen. We receive the names and ages of family members in your Family Sharing group, gated by the OS-level parental-approval prompt. The data is used only at suggestion time and is not retained on our servers after the suggestion is accepted or dismissed. Disconnect by removing the Family Sharing link from iOS Settings.
• Google LLC (Family Link) — same suggested-member contract as Apple Family Sharing, via Google Family Link. Same retention contract: read-at-suggestion-time, not retained.
• Apple Inc. (Screen Time API) — kid-account daily-budget read for the family-shield and screen-time-aware mission features. We receive only the boolean "did the kid's daily budget cross threshold today" signal — never raw usage logs, never per-app breakdowns, never the apps the kid used. The Screen Time entitlement is granted by Apple per-device with a separate consent screen and is independent of all other permissions.
• Google LLC (Android Usage Stats API) — same boolean-only kid-budget read on Android. We never receive raw usage events or per-app breakdowns. The Usage Stats permission must be granted per-device in Android system Settings and can be revoked there at any time.
• Discord, Inc. — outbound webhook + bot integration for share targets that opt into Discord delivery. When you link a Discord channel as a share target, we receive the webhook URL or the bot's per-server token and the channel ID; we send the share payloads you trigger. We never read Discord message history, server member lists, or any other server data. Disconnect at any time from ConKarma Settings → Integrations → Discord, which revokes our webhook URL or bot token.
• iMessage / SMS / WhatsApp / Telegram (share-out only). When you share content from ConKarma to one of these messaging apps via the native Share Sheet, we hand the payload to the OS share-sheet — the destination app then delivers it under its own privacy posture. We don't receive read receipts, the recipient list, or any reply traffic; the message leaves our service the moment the Share Sheet receives it.

Connecting an AI assistant (Model Context Protocol / MCP). You can optionally connect your own AI assistant to ConKarma through the Model Context Protocol (MCP). This is a connection you set up and authorise. Once connected, your assistant can read the ConKarma data that is already visible to you in the app — including content shared within your cell — and relay it to the large-language-model (LLM) provider your assistant uses. The assistant sees no more than you can: the connection is bounded by your existing in-app permissions. It is a new outbound flow (egress) of your in-app-visible data to an LLM provider that you choose and control, which you consent to at the moment you connect. Because you — not ConKarma — select and control that provider, it is not a ConKarma sub-processor and does not appear on our sub-processor list; ConKarma does not choose it, contract with it on your behalf, or receive your assistant's traffic. Your use of that provider is governed by its own terms and privacy policy.

Cell-privacy note: because a connected assistant can read the cell content shared with the member who connected it, another member's shared data is reachable through that member's assistant. If someone in your cell connects an AI assistant, the cell content shared with them can be read by their assistant and sent to their LLM provider. Connect an assistant only if you are comfortable with your in-app-visible data — including shared cell content — flowing to your chosen provider, and be aware that others in your cell may do the same. You can disconnect an MCP-connected assistant at any time from ConKarma Settings, which revokes its access and stops further reads.

The current canonical sub-processor list is published at https://conkarma.app/legal/subprocessors. If we change vendors, we update that list and (for material changes) notify users via in-app notice.

• With law enforcement or regulators when we are legally required, or when we reasonably believe disclosure is necessary to prevent imminent harm. We scrutinise requests and push back on over-broad ones.
• In a corporate transaction (merger, acquisition, reorganisation, sale of assets), in which case any successor will be bound by this Policy or will notify you of material changes.

If you pair an Apple Watch or Wear OS watch with the device on which the Service is installed, the same data we already process for you is mirrored to your watch via Apple's or Google's own pairing channels. We do not collect new categories of data from the watch, and the watch surface is a UI surface only — taps on watch complications either route you back into the phone app or queue actions that the phone app processes on next foreground.

Emergency check-in geolocation (opt-in). When you (or, for a child under 13, a verified parent on the child's behalf) turn on Emergency location sharing in Settings, the app may include latitude and longitude on a specific emergency check-in if you toggle "Share my location with this alert" before tapping I'm safe or I need help. Both the standing consent and the per-checkin toggle must be on for any coordinates to be collected — the app does not track your location in the background. Coordinates are visible only to other members of your cell, attached only to the specific check-in they were sent with, and age out automatically after a per-region retention horizon (US / Australia / RoW: 30 days; California: 14 days; Canada / Quebec / EEA / UK: 7 days). Revoking consent in Settings deletes any coordinates we still hold within minutes; the check-in itself stays as a "safe" or "need help" record without location.

Hearth proximity (opt-in, event-triggered). A separate, opt-in geolocation scope (home_proximity) backs the optional address you can attach to a Hearth on the /features/hearths surface — useful for cell logistics like which-house-tonight prompts or quiet check-ins when a kid moves between two homes. The address itself is encrypted at rest. The stored latitude / longitude is rounded to three decimal places (≈ 100 metres) on the server side — we deliberately do not retain the exact street-level position you typed in. Proximity checks fire only on an explicit cell action (a member tapping a "which house?" prompt, a kid initiating a check-in), never continuously and never in the background. When a check fires, we receive the kid's current latitude / longitude from the device, compute the distance to the relevant Hearth, store only the resulting distance bucket on the cell timeline, and discard the raw coordinates within the same request — the kid's reported position is never persisted. Retention of the distance-bucket record follows the same per-region horizon as Emergency check-in: US / Australia / RoW 30 days; Brazil 14 days; Canada / Quebec / EEA / UK 7 days; California 14 days. Clearing a Hearth's address removes both the stored approximate location and any historical distance-bucket entries within minutes. This scope is independent of Emergency location sharing — turning one on does not turn the other on.

Health data is not shared with any third party for any purpose, including advertising. This is a hard rule: data read from Apple HealthKit, Google Fit, or Health Connect is processed locally on your device for the threshold check; the only signal that reaches our servers is the boolean "did the user's daily total cross the threshold today" attached to the relevant mission/duty/experience. Apple HealthKit's terms of service forbid sharing health data with third parties for advertising or any unrelated commercial purpose, and we honour that rule across both platforms (iOS and Android) regardless of which platform sourced the data.

A current list of sub-processors is available at https://conkarma.app/legal/subprocessors and is updated when it changes.

7. International Data Transfers

We operate globally and may transfer personal information to countries other than the one in which you reside, including the United States and other jurisdictions. When we transfer personal data out of the EEA, the UK, or Switzerland, we rely on recognised transfer mechanisms:

• European Commission Standard Contractual Clauses (2021 set) with supplementary technical and organisational measures.
• The UK International Data Transfer Addendum where applicable.
• The Swiss FDPIC addendum where applicable.
• Where available and relevant, vendor participation in the EU-US Data Privacy Framework, UK Extension, and Swiss-US DPF.

You may request a copy of the relevant transfer mechanism (with commercial terms redacted) by writing to legal@conkarma.app.

8. Data Retention

We retain personal information for as long as needed to provide the Service and to meet our legal obligations. Retention treats serene-zone (family-tier) and adult-zone (Ember) data differently — see the table below.

8.1 Serene-zone (family) data

• Active account data: for the life of the account.
• User-generated content: until you delete it or close the account, subject to backups that are overwritten within 30 days.

Account deletion pathways

Deleting your account. When you delete your account (or request erasure of your personal data), we make it immediately inaccessible and schedule permanent deletion after a 30-day recovery window. You can cancel any time within that window by signing back in — after it, the data is permanently erased (some records with a legal retention obligation, e.g. financial or child-safety audit records, are kept for the required period). Court-ordered or child-safety removals are actioned immediately.

The rest of this section sets out the two deletion pathways behind that summary, with materially different retention semantics. Pick the one that matches your intent.

• Standard account deletion (user-initiated via Settings → Delete account). Triggers a soft-delete plus 30-day tombstone: the account is immediately disabled and removed from every cell-mate-visible surface, but the row is retained in a recoverable form for 30 days. You can cancel the deletion yourself at any point in that window simply by signing back in; if you prefer, an accidental deletion can also be reversed by writing to legal@conkarma.app within the grace window. After 30 days, the tombstone-purge worker hard-purges the row.
• Immediate PII-erasure (GDPR Article 17 right to erasure / CCPA right to delete / COPPA parental erasure request). Available on request — write to legal@conkarma.app for general accounts or parents@conkarma.app for child accounts — and governed by our hard-delete approval policy. The request requires a typed confirmation phrase and a written reason, and is gated by a super-admin two-eye review (operator A initiates, operator B approves) to defend against fraudulent erasure. Once approved, every PII column on the user row (email, name, date of birth, phone, address, photo URL, bio, journal entries, parent contact) is nulled in a single atomic transaction. No 30-day tombstone — the PII is gone the moment the second-eye approval lands.
  • What is not erased. Cell-level co-owned artifacts (missions you participated in, shared experiences, cell history visible to former cell members) are not deleted, because they are not solely your personal data under the cell-co-ownership invariant — after erasure, your attribution on those artifacts is replaced with the cell-system user. Historical financial ledger entries (DNA / EGO transactions) are anonymised via the same cell-system re-attribution rather than deleted, because IRS recordkeeping rules require us to keep transactional records for at least 7 years. The audit log of the erasure event itself is retained for 7 years for regulatory inspection.
  • Backup propagation. Hard-delete applies to the active database immediately. Backups age out within their own 30-day retention window, so any PII that existed in a recent backup expires within 30 days of the erasure event.

8.2 Adult-zone (Ember) data

• Default retention: 3 years from creation. When the window closes, the row is hard-deleted (no soft-delete tombstone).
• User-configurable. You can set the window to any value from 90 days to 10 years in Settings → Ember privacy. Lowering the window deletes already-aged-out rows immediately on save.
• Backup scope. By default, backups include adult-zone data so that account recovery restores the full state. The "Exclude Ember from device backup" toggle (Settings → Ember privacy, off by default) sets NSURLIsExcludedFromBackupKey on adult-zone files; turning it on means a fresh-device restore will not bring those rows back.
• Export scope. GDPR / portability exports exclude adult-zone rows by default. Turn on "Include Ember in GDPR data export" (Settings → Ember privacy, off by default) to embed them.

8.3 Operational and security data

• Crash logs / Crashlytics: up to 90 days.
• Firebase Analytics event-level data: up to 14 months (default Firebase retention).
• Transaction / billing records: for the period required by tax and consumer law, typically 6–10 years depending on jurisdiction.
• Security and abuse logs: up to 12 months.
• Deleted account tombstones (to prevent re-creation abuse): up to 30 days.

When a retention period ends, we delete or irreversibly anonymise the data.

8.4 Child-account retention

A complete, parent-readable schedule of how long we retain data tied to child accounts — together with the finite-bounding mechanisms and the operational code paths that enforce each window — is published as the Children's Data Retention Policy. That document supplements this section and §3 (Children's Privacy) in fulfilment of the amended COPPA Rule effective 22 April 2026.

9. Security

We implement administrative, technical, and organisational measures designed to protect personal information, including:

• TLS 1.2+ in transit; certificate pinning on mobile clients.
• Encryption at rest for databases and object storage.
• Argon2id for password hashing (OWASP-recommended memory-hard KDF; tuned per the OWASP 2024 password-storage cheat-sheet parameters). Plaintext passwords are never written to disk or logged.
• Secrets stored in platform keychains (iOS Keychain, Android Keystore) via flutter_secure_storage.
• Authenticated API access with short-lived access tokens and rotating refresh tokens; auto-logout on refresh failure.
• Unknown-location login alerts. When a successful sign-in arrives from a country we have not seen on your account in the recent history, we send a security email to the address on file with the timestamp, approximate country (resolved from your IP address by our GeoIP sub-processor, freeipapi.com — see §6), and a "this wasn't me" link that revokes the session. To perform this lookup your IP address is sent to freeipapi.com; the resulting country code is not persisted beyond the session record. We do not share the country code with third parties for advertising; it is a security signal only.
• Idempotency keys on sensitive write endpoints to prevent duplicate charges.
• Rate limiting and exponential-backoff retry logic.
• Least-privilege access to production data, with audit logging.
• Periodic security reviews and third-party penetration testing.

9.1 Adult-zone (Ember) hardenings

The adult zone carries additional, defense-in-depth controls (the zone-isolation guarantees document itemises all 14):

• Biometric gate on every adult route (Face ID / Touch ID / Android biometric). Pref off by default; you opt in from Settings. Biometrics stay on your device (BIPA). The match is performed entirely on-device by the operating system (Face ID / Touch ID / Android BiometricPrompt); ConKarma never collects, receives, stores, or has access to any biometric identifier or biometric information, no biometric data ever leaves your device, and we do not use biometric data for identification or any other purpose.
• Session re-prompt on inactivity (5 min default, RC-tunable) and on app-background dwell (30 s default). The biometric latch is not permanent.
• Per-device enable — adult zone is OFF by default on every non-primary device; opt in per device.
• Two-eye admin access. No XTZ Group human can read user adult-zone content unilaterally. Admin tools exclude adult tables by default; overrides require a second admin's signed approval, recorded in an immutable audit log.
• In-memory cache zeroing. When you cross the ember→serene boundary or background the app, every cached bitmap is dropped via ImageCache.clear() + clearLiveImages(). Defense-in-depth against memory inspection / forensic tooling.
• Spotlight / Apple Intelligence / AppIntents exclusion. No adult entity is donated to Spotlight; no adult AppIntent ever exists; Apple Intelligence's on-device LLM gets no adult context. iOS Smart Stack and Lock Screen widgets hard-pin to serene-zone content only.
• Push-body redaction. Adult-zone push notifications always carry the static body "You have a new message" regardless of category; the recipient app reads the category from the data payload after biometric unlock.
• Screenshot guard. Android FLAG_SECURE + iOS privacy snapshot whenever the app is on an adult route.
• Server-side zone-tagged trust relations + per-entity visibility_scope enum + RequireZoneMatch helper + boot-time validator.
• Zero-tolerance leak metric. Any cross-zone read attempt increments goia_zone_leak_attempted_total; production target = 0.

The full list lives in assets/legal/zone_isolation_guarantees.md and the public mirror at conkarma.app/security/zone-isolation.

No system is perfectly secure, and we cannot guarantee absolute security. If you believe your account has been compromised, contact legal@conkarma.app immediately.

10. Data-Breach Notification

If we become aware of a personal-data breach that is likely to result in a risk to your rights and freedoms, we will notify affected Users and the relevant supervisory authorities without undue delay and, where feasible under GDPR, within 72 hours of becoming aware. Similar commitments apply under UK GDPR, U.S. state breach laws, Canada's PIPEDA, Australia's Privacy Act, Brazil's LGPD, and other applicable regimes.

11. Your Rights

Depending on where you live, you have some or all of the following rights:

• Access — obtain a copy of the personal information we hold about you.
• Rectification / correction — correct inaccurate or incomplete data.
• Erasure / deletion — delete your data, subject to legal retention obligations.
• Restriction — limit how we process your data in certain circumstances.
• Objection — object to processing based on legitimate interests or direct marketing.
• Portability — receive a machine-readable export.
• Withdraw consent — where processing is based on consent.
• Notification preferences — opt out of any notification category (per-category, including push, in-app bell, and email; transactional account / security / billing email is always-on by design). Manage via in-app Settings → Notifications. Marketing and digest emails are split from transactional email; toggling the marketing toggle off stops non-essential email entirely while leaving security and account-state messages unaffected.
• Complain to a supervisory authority — see Section 15.
• Automated decision-making — we do not make decisions producing legal or similarly significant effects about you solely by automated means.

Adult-zone (Ember) user-controlled privacy primitives. Beyond the rights above, every Ember user can — at any time and without losing access to the feature — adjust:

• Per-device enable. Settings → Devices → toggle each device individually.
• Retention window. Settings → Ember privacy → 90 days to 10 years (default 3).
• Backup exclusion. Settings → Ember privacy → "Exclude Ember from device backup" (default OFF).
• GDPR-export scope. Settings → Ember privacy → "Include Ember in GDPR data export" (default OFF).

These controls are user-controlled by design: we do not change them on your behalf, and we surface the disclosure copy directly above each toggle so the consequence of every change is unambiguous.

California residents (CCPA/CPRA): you have the right to know, delete, correct, and limit use of sensitive personal information, and to opt out of "sale" or "sharing". We do not sell personal information and we do not share it for cross-context behavioural advertising. You may exercise rights via legal@conkarma.app or the in-app Settings. You may designate an authorised agent. We will not discriminate against you for exercising a right.

Nevada, Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, and other U.S. state residents: analogous rights apply; contact legal@conkarma.app.

To exercise a right, email legal@conkarma.app from the address on your account or use the in-app Settings → Privacy controls. We will verify your identity proportionate to the sensitivity of the request and respond within the period required by applicable law (typically 30–45 days).

12. Multi-App Architecture

ConKarma is distributed as two coordinated apps that share one account: the main ConKarma app (the family experience) and ConKarma After Dark (a standalone, adults-only couple-intimacy experience for those 18+). Either app can be your starting point — you may begin in either and use the same account in the other; they are not in a primary/secondary relationship, and After Dark is a full app in its own right, not merely an add-on. Both apps share your account, your cell membership, and your data-subject rights, and the privacy practices in this Policy apply identically across both.

13. Cookies and Similar Technologies

Our mobile app uses local storage (SharedPreferences, iOS Keychain / Android Keystore) to keep you signed in, remember preferences (dark mode, haptics, density, theme), and cache data for offline and performance reasons. Firebase Installations generates an installation identifier.

If you use the web version of the Service, we use strictly-necessary cookies for authentication and, subject to your consent where required, first-party analytics cookies. A cookie banner will let you manage choices.

For free, adult and teen accounts, the mobile app integrates Google AdMob for non-personalised banner, interstitial, and rewarded-video advertising. AdMob's SDK reads the OS-level advertising identifier (IDFA / AAID) only when you grant permission via the system App Tracking Transparency / ad-personalisation prompt; if you decline, ads are still served but without personalisation. No advertising SDK is loaded on child accounts. Premium / family-plan subscribers see no ads.

You can change ad-personalisation preferences any time via your device settings (iOS: Settings → Privacy & Security → Tracking; Android: Settings → Google → Ads).

14. Apple Privacy Nutrition Label and Google Play Data Safety

For transparency, the data categories we declare to Apple and Google mirror this Policy:

• Linked to you: Contact Info (email); User Content (photos, audio, messages, other user content); Identifiers (User ID, Device ID, country code derived from IP for security); Usage Data; Diagnostics; Purchases; Health & Fitness (steps / distance / active minutes / sleep / mindfulness — only categories you opt in to via HealthKit / Google Fit / Health Connect); App Functionality (notification preferences).
• Used to track you across apps/websites owned by other companies: none.
• Used for third-party advertising: Identifiers (Device ID where the user has granted ad-tracking permission), Diagnostics — declared on free, adult and teen accounts only. Never on child accounts. Never on premium / family-plan accounts. Health & Fitness data is never used for advertising on any account type.
• Used for the developer's advertising or marketing: only with separate opt-in.
• Health & Fitness — Apple Privacy Nutrition Label / Play Health Connect disclosure: read-only access to user-selected categories; processed locally on-device for threshold checks; the only server-side signal is a boolean "threshold crossed today" attached to the relevant mission/duty/experience. Never written back to the platform health store. Never shared with third parties.
• Per-zone retention disclosure. The Privacy Nutrition Label and Play Data Safety form distinguish serene-zone data ("Account-life retention; user-deletable") from adult-zone data ("3-year default, user-configurable 90 days–10 years"). The user-controlled backup-exclusion and GDPR-export-scope toggles are disclosed under "Data scope user can control" so reviewers can verify the consent surface.

15. Complaints and Supervisory Authorities

If you are in the EEA or UK, you may lodge a complaint with your local Data Protection Authority. A list is available at https://edpb.europa.eu/about-edpb/about-edpb/members_en (EEA) or https://ico.org.uk (UK). We'd appreciate the chance to address your concern first — please email legal@conkarma.app.

16. Changes to This Policy

We may update this Privacy Policy from time to time. Material changes will be announced at least thirty (30) days in advance via in-app banner or email, and we will update the "Last Updated" date above. Non-material changes (such as clarifications, typography, or additional legally-required disclosures in a single jurisdiction) may take effect immediately.

17. Jurisdiction-Specific Addenda

Region-specific addenda are appended to this document rather than editing the main body. The current set is published at https://conkarma.app/legal/addenda; we update the list as we open new markets.

18. Contact Us

For any privacy question, request, or concern, contact: XTZ Group, Inc. 2261 Market Street #4524, San Francisco, CA 94114, USA legal@conkarma.app