Your birth time is your birth time. We don’t share it. We don’t sell it.
An astrology app touches the most intimate data anyone has — date, time, and place of birth. Here is exactly what we do with it, who can read it, and how researchers can tell us when we have made a mistake.
Last updated: May 26, 2026
How your data actually moves
Every birth-data field follows the same path. Watch the lock travel through:
Birth data is encrypted in transit (TLS 1.3) and at rest (AES-256), with row-level security enforced on every database query.
Four commitments we make on day one
The kind of promises you can verify, not the kind that need a long preamble.
Encryption everywhere
TLS 1.3 in flight, AES-256 at rest. Birth date, time and place are never written to disk in plaintext.
Row-level security
Every database row carries a user-id. Postgres RLS enforces "you can only read your own data" at the database layer, not just the API layer.
No third-party ads, ever
We do not run advertising and we do not allow ad networks to set cookies through our site. There is no commercial incentive to leak your data.
No data sale, no resale
We do not sell, license, rent or transfer your personal data to brokers, marketers or model trainers. Your chart is not someone else’s training set.
Threat model — what is in scope
Anything we run is fair game for a security researcher. Findings against third-party platforms — Anthropic, Supabase, Apple, Google, Stripe — should be reported to them directly.
Found something? Tell us — privately.
Email support@mypanditji.io with reproducible steps, the affected URL or account, and your preferred credit (named or anonymous). We acknowledge within two business days and work with you to a fix.
Researchers acting in good faith within the published scope are protected under our safe-harbour commitment in section 4 of the responsible-disclosure programme below.
Responsible-disclosure programme — formal text
The binding version. Section anchors are stable and quotable in a report.
1. Responsible disclosure
In plain English:Find a security issue? Tell us privately first. We respond fast and we won’t come after you in good faith.
MyPanditji welcomes good-faith security research. If you believe you have found a vulnerability in the Service — the website, the mobile applications, the public APIs, or our supporting infrastructure — please report it privately to the address below before any public disclosure. We will work with you to validate, fix, and credit (with your consent) the finding.
2. How to report
In plain English:Email support@mypanditji.io with details and steps to reproduce. PGP key on request.
Email: support@mypanditji.io PGP key: available on request. Please include in your report: • A clear description of the vulnerability. • Reproducible steps, including request payloads and responses where relevant. • Affected URL, account, or component. • Your name or handle, and whether you wish to be credited.
3. Scope
In plain English:Everything we run — mypanditji.io, the apps, our Supabase project, our edge functions, our astro engine.
In scope: • mypanditji.io, mypanditji.com and subdomains. • The iOS and Android applications published by MyPanditji. • Our Supabase project (RLS bypasses, auth flaws, data exposure). • Edge functions deployed under our Supabase project. • The Fly.io-hosted astro engine. Out of scope: • Third-party platforms we depend on (Anthropic, Supabase, Fly.io, Apple, Google, Stripe). Report directly to them. • Findings that require physical access to a victim’s unlocked device. • Reports based solely on outdated browsers or unsupported OS versions. • Reports from automated scanners with no reproduced impact. • Social-engineering attacks against employees.
4. Safe-harbour commitment
In plain English:If you act in good faith and within scope, we won’t threaten or pursue legal action against you.
We will not initiate legal action against, or recommend law-enforcement action against, security researchers who act in good faith, stay within the scope above, do not access or modify other users’ data beyond the minimum necessary to demonstrate the issue, and give us a reasonable period to remediate before public disclosure (we suggest 90 days, negotiable).
5. Recognition & rewards
In plain English:We don’t run a formal bounty programme yet, but high-impact reports may receive a token reward and public credit.
We do not currently operate a paid bug-bounty programme. We may, at our discretion, recognise high-impact reports with a public credit on a security acknowledgements page, a token monetary reward, or both. As the programme matures we will publish more formal severity and reward bands here.
6. security.txt
In plain English:Our security.txt lives at /.well-known/security.txt and points back to this page.
Per RFC 9116 we publish a machine-readable security.txt at /.well-known/security.txt naming the same contact and policy as this page. Reports that follow the RFC 9116 conventions are processed identically to reports sent by other means.