Privacy and your information

Operator and contact

MyKarmaChart is the public operator and brand. For support, privacy questions or questions about information you have provided, email our support contact. Do not include your password or a password-reset link.

support@mykarmachart.com

Account settings, export and deletion

Accounts

An account requires an email address and password. A display name is optional. We store a password hash, not a plaintext password, along with an account identifier, language preference, verification status and creation/update times. Authentication also creates security records. You can use the public chart and Numerology tools without saving an account profile.

Birth profiles and saved locations

Saving a birth profile stores its identifier and account ownership, relationship, birth date, birth time or unknown-time choice, city/country, coordinates, timezone, astrology preference, report language and timestamps. Display name, full birth name and region are optional. Location provenance can include a place reference, entered search text, source/version and repeated-time choice. Saved locations store a label when provided, location/timezone details, default choice, identifiers, timestamps and provenance. These records support your chosen profile and location workflows. Time-dependent calculations may be unavailable when birth time is unknown.

Adults and information about other people

Account holders must be at least 18 years old. An adult may create a profile for another person only when authorized to provide and use that person's information. For a child, this means a parent or legal guardian, or another adult with legally appropriate authority. Relationship labels do not establish permission. The application does not currently verify age, guardianship or consent technically.

Numerology inputs and results

Numerology uses a birth date and timezone, with an optional name for name-based numbers. It runs in the PHP application hosted by Hostinger; the name is not sent to the separate astrology calculation service by this workflow. Inputs, numbers, totals, reduction trails and calculation context can remain in a session-bound snapshot for language switching, valid for 15 minutes. This workflow does not save a Numerology result in the account database. A name deliberately saved in a birth profile is a separate stored record.

Birth charts and calculation state

Chart processing uses the required birth date/time, coordinates, timezone, repeated-time choice and calculation options. Requests to the calculation service contain these fields and request identifiers, not your account email or name. The chart and Numerology forms submit birth inputs in request bodies rather than placing them in public result URLs. Public chart generation does not automatically create a saved birth profile or a saved chart database record. Filtered inputs/results can remain in a session-bound snapshot, valid for 15 minutes, to preserve language continuity. Private reviewer timing features also use temporary session state; they are not a public AI service.

Cookies, browser storage and daily timings

A session cookie supports authentication and temporary state; it has no fixed browser expiry. Production session cookies are configured Secure, HttpOnly and SameSite=Lax. Theme and location preferences can be stored in localStorage without an application-set expiry. Saving a daily-timing location also sets a 180-day location cookie, renewed when saved, containing place/location, coordinates and timezone fields. That cookie is sent to our server; it is not browser-only storage. Browser controls can clear cookies and localStorage. Precise GPS sharing is not required; the current location button provides guidance rather than automatically obtaining GPS coordinates.

Session and cache limits

The application checks for 30 minutes of inactivity when a session is used. Chart and Numerology snapshots expire logically after 15 minutes; profile submission receipts have a 30-minute validity limit. These limits govern use, not guaranteed physical deletion of session files. Daily location/date calculation caches have a six-hour freshness limit, not a verified six-hour erasure deadline. Physical session/cache cleanup timing has not been established as a deletion guarantee.

Security and recovery records

Security records may include event type, account reference, hashed identifiers, IP address, login user-agent and timestamps. Rate limiting stores hashed identifiers and attempt times. Password-recovery jobs temporarily hold an email address, language and creation time in a private queue. Jobs older than 15 minutes are not eligible for delivery, and attempted jobs are removed through worker processing. Reset-token hashes are stored with expiry/use metadata; reset links are valid for one hour. Bounded cleanup during recovery processing is not a fixed deletion deadline for every record. Registration also creates verification-token records; this does not mean registration email delivery is certified.

Your account-data export

Account settings provides a JSON export: account UUID, email, display name, preferred language and creation time; saved birth profiles and saved locations, including their identifiers, timestamps and returned location-provenance fields. Internal numeric record/owner IDs are excluded. Chart metadata is currently empty. Password hashes, tokens, audit/rate-limit records, sessions and cached results are not included. This is an account-data export, not every record held by hosting or other infrastructure.

Deleting a profile

Profile deletion removes the selected owned profile from the active database and its linked location provenance. It does not delete the account or other profiles. A deletion audit record can retain the account reference, hashed profile identifier, IP address and time. The action does not promise immediate removal of every previously generated session copy, log or backup.

Deleting an account

Account deletion removes active profiles, saved locations and the account through a sequence of database operations, with linked provenance and token records removed by database relationships. It logs out the current session. Existing audit records can remain with the account reference cleared, while identifiers, IP/user-agent information and timestamps may remain; a separate deletion event is recorded. This is not an atomic erasure guarantee for every record, a guarantee that every other session is revoked, or immediate deletion of logs and backups.

Retention, logs and backup copies

Active records, security/audit records, sessions, snapshots, caches, logs, recovery records and backups have different purposes and lifecycles. No single fixed retention period has been verified for all of them. Application and hosting logs may retain operational information. A backup or independent recovery copy made before deletion can still contain deleted information. Current backup/log age-out and the removal date of independent copies have not been verified, so we do not promise removal within a fixed number of days. Contact us with retention questions; logical expiry is not proof of physical erasure.

Hosting and email providers

Hostinger hosts the website/application, database, sessions and private application storage. Titan SMTP processes password-recovery email, including the recipient address and reset message/link, for onward delivery to the recipient's mail service. The validated transport uses STARTTLS. Provider and recipient-mailbox retention is not controlled or verified here; account deletion does not delete delivered messages from those mailboxes.

Calculation infrastructure

Google Cloud Run processes required calculation inputs through authenticated HTTPS requests. The certified replay-protection design uses Google Cloud Storage for empty records named with a request-identifier hash, not birth-data payloads. Calculation-service logging records operational metadata such as request identifiers, status and duration. Historical Cloud Storage/Logging configuration is not a current provider-wide retention guarantee. We do not claim that all infrastructure logs are free of personal information or that provider data is erased on a universal schedule.

Browser dependencies and reference data

Pages load Bootstrap dependencies from jsDelivr, which causes browser network requests to that CDN. The application does not intentionally send profile fields in those dependency requests; network metadata still reaches the provider. GeoNames supplies the locally queried location catalogue; no live personal-data GeoNames API call was found in the inspected search flow. Astronomy Engine is calculation software, not a separate personal-data API in this flow. These distinctions are not guarantees about independent provider practices.

Analytics and operational information

No recognized application analytics or tag-manager integration was detected in the verified application scope. This is not a claim that hosting statistics, server logs, CDN/network telemetry or other provider operational data do not exist. MyKarmaChart is not adding application analytics as part of this disclosure update.

AI and model training

MyKarmaChart does not use users' private account, birth-profile, horoscope or Numerology information to train AI models. This is MyKarmaChart's operator policy. No AI/LLM or model-training integration was found in the verified application; the private factual question tool is deterministic, not an LLM. Independent infrastructure/service-provider practices have not all been verified or controlled by MyKarmaChart, and this policy is not a provider-wide guarantee.