1. Security principles
Services and people should receive only the access reasonably needed for their function.
Credentials, provider keys, and sensitive configuration belong in managed server-side secret storage.
Ordinary logs should use technical metadata rather than copying questions, answers, exact birth inputs, or linked-person content.
Versioned calculation artifacts and controlled deployment paths make unexpected changes easier to detect and investigate.
2. Network and transport security
Production deployments are intended to use HTTPS/TLS for browser-to-service and service-to-service communication where applicable. Modern managed cloud platforms, secure cookies, and restricted cross-origin configuration are used or planned according to environment.
Users should avoid accessing accounts through compromised devices or networks and should keep browsers and operating systems updated.
3. Authentication, sessions, and authorization
Kaaladarshi uses authenticated sessions for account persistence. Authorization checks are intended to ensure that users can access only data associated with their account or an appropriately authorized anonymous session.
Session controls may include secure cookie settings, expiration, re-authentication, logout, and server-side ownership checks. UI restrictions alone are not treated as an authorization boundary.
4. Data protection and storage
Production service data is intended to use managed databases and storage with access controls, encrypted transport, provider-supported encryption at rest, backup processes, and environment separation.
Calculated artifacts may be stored so they can be reused without recalculating until their relevant baseline or engine version changes. Artifact persistence remains subject to account ownership and deletion policies.
5. Secrets and configuration
Production credentials and API keys should be stored in managed secret systems rather than source control or browser-delivered bundles. Local development may use environment files that are excluded from version control.
Kaaladarshi may rotate credentials, revoke access, or replace providers when security or operational needs require it.
6. Logging, monitoring, and incident investigation
Operational logging is designed around request identifiers, endpoint, status, timing, safe error codes, artifact/version metadata, and other technical signals needed to diagnose service health.
Private questions, generated answers, exact birth details, and linked-person data should not be included in ordinary logs. Controlled diagnostic access may be used when necessary and authorized, with additional safeguards appropriate to the situation.
7. Secure development and deployment
- Version-controlled source and reviewable changes.
- Dependency management and vulnerability scanning appropriate to the environment.
- Automated regression tests, including golden Jyotish calculation tests.
- Environment separation between local, staging, and production.
- Immutable or traceable deployment artifacts where practical.
- Database migrations and rollback/backup planning before broad launch.
8. Cloud and third-party providers
Security also depends on third-party providers used for hosting, databases, authentication, AI, analytics, monitoring, communications, or other service functions. Kaaladarshi evaluates provider use according to operational need and may change providers over time.
Third-party incidents can affect availability or confidentiality despite Kaaladarshi's own controls.
9. What users can do
- Protect the Google or other account used to authenticate.
- Use device security, browser updates, and account recovery controls.
- Do not share authentication codes or passwords with Kaaladarshi support.
- Enter only information necessary for the experience.
- Sign out from shared devices.
- Report suspicious activity or unexpected data exposure promptly.
10. Responsible security disclosure
If you believe you found a vulnerability, please avoid accessing, modifying, downloading, or exposing data that does not belong to you. Do not use destructive testing, denial-of-service techniques, spam, social engineering, or automated scanning that materially affects service availability.
Send a concise report to security@kaaladarshi.com with “Security report” in the subject. Include reproduction steps, impact, and relevant technical details without unnecessary private user data.
11. Security incidents
If a material security incident occurs, Kaaladarshi may investigate, contain, remediate, preserve relevant records, notify affected users or authorities where legally required, and change service behavior to protect users.
Timing and content of notices may depend on the facts, legal requirements, investigative needs, and security considerations.
12. Scope and changes
This overview describes security principles rather than a guarantee, certification, audit opinion, or complete list of controls. Controls may change as Kaaladarshi's architecture, providers, and threat model evolve.
For privacy practices, see Privacy. For AI boundaries, see Responsible AI.