← Back to home

Security policy

Last updated: June 2026

How to reach us

Email security@yumankind.com (preferred). If you don't get an acknowledgement within three business days, follow up at hello@yumankind.com.

The canonical reporting channel is published in our security.txt per RFC 9116.

What to include

  • A description of the vulnerability and the impact you believe it has.
  • Reproduction steps — ideally a minimal proof-of-concept.
  • The relevant component (mobile app, Cloud Functions, Firestore rules, Hosting, Remote Config, etc.) and the version or commit you tested against.
  • Any logs, screenshots, or HAR captures that help reproduction.
  • Your name or handle if you'd like to be credited publicly.

Our commitments

  • We acknowledge receipt within 3 business days.
  • We provide an initial triage and severity assessment within 7 business days.
  • We keep you updated at least every 14 days until resolution.
  • We do not pursue legal action against researchers acting in good faith under this policy.
  • With your permission we credit you in our public release notes once the issue is fixed.

Scope

In scope

  • The Prson mobile app (net.prson.app on iOS and Android).
  • Cloud Functions deployed under europe-west1 for the prson-network Firebase project.
  • The Firestore security rules.
  • The Hosting sites app-prson.web.app / app.prson.net and prson-network.web.app / prson.net.
  • Identity, signature, verification, and messaging flows — including the offline-verifiability claims we make about them.

Out of scope

  • Denial-of-service against shared infrastructure (Firebase, Apple, Google, Cloudflare R2). Reporting service-wide quota issues is welcome; attacking them is not.
  • Social engineering of Yumankind staff or end users.
  • Findings that require physical access to an unlocked, paired device.
  • Self-XSS or issues requiring the victim to paste attacker-controlled code into their own console.
  • Best-practice or theoretical issues without a demonstrated impact.
  • Vulnerabilities in third-party software we depend on, unless our configuration meaningfully exacerbates the issue.

Coordinated disclosure

Please give us a reasonable window to fix valid issues before publishing details. Typical timelines:

  • 30 days for low / medium severity issues.
  • 60 days for high severity issues.
  • 90 days for issues that require client or infrastructure rollouts (e.g., key-format changes that need every wallet to migrate).

If we agree on a longer window we'll say so in writing. If we go silent, you are free to publish after the agreed window has expired.

Priority-one categories

Prson makes very specific claims about cryptography. Reports demonstrating any of the following are triaged first:

  • Minting, altering, or revoking a property signature without possession of the identity key or the notary key.
  • Recovering raw values (birthdate, document number, selfie bytes, etc.) from server-side data alone.
  • Reading another wallet's MLS-encrypted messages.
  • Binding a reality-proof capture to an identity that did not actually capture it, or replaying one capture as the response to a different challenge.
  • Writing or modifying Firestore data outside what the deployed rules permit.

Encrypted reports

If your finding is sensitive enough to warrant encryption in transit, mention this in a brief plaintext email and we will respond with an appropriate public key and continue from there.

Security architecture & compliance posture

For researchers and partners evaluating Prson, the load-bearing properties of the platform are:

  • Keys never leave your device. Identity keys derive from a 24-word recovery phrase; device keys live in the Secure Enclave / Android StrongBox and are non-extractable. We operate no key custody.
  • Hash-only server storage. Verified properties are stored as salted hashes; raw values stay on-device. Bank figures, document fields, and selfies follow the same discipline.
  • Verifiable without our servers. Notary signatures (rotating keyring, published at /.well-known/jwt-vc-issuer and did.json) let any party verify proofs, properties, and credentials offline.
  • Unlinkable by design. Identifiers shared with relying parties are pairwise — derived per domain — so independent verifiers cannot correlate the same person across sites.
  • No wallet usage analytics. The app carries crash diagnostics only; no behavioural tracking of wallet use.
  • On-device biometrics. Face matching for document verification runs entirely on the phone; no biometric templates are stored server-side.

The full architecture — key model, verification ladder, unlinkability, certified capture, and the standards we implement — is documented publicly in the Prson trust-architecture white paper.

Vulnerability disclosure follows RFC 9116 security.txt. Conformance documentation for enterprise and regulatory review is available to partners on request at hello@yumankind.com.

Thank you

Privacy and authenticity are load-bearing for everything Prson is trying to build. We're grateful to researchers who help us hold the claims up.