Securityसुरक्षा

A society’s record has to be trusted by its members, its auditor and the Registrar. These are the design decisions that make that possible.

Each society is sealed off

Every table that holds a society’s data carries the society it belongs to, and the database itself — PostgreSQL row-level security — refuses to return a row to any request that is not working inside that society. A mistake in application code cannot show one society’s data to another. The application connects to the database with a role that cannot switch this off.

The record is not rewritten

Register entries, journal entries, minutes, resolutions and proofs of service are append-only. A correction is a new entry that supersedes the old one and points back to it, so the history of every register can be shown to an auditor.

Signed means bound

Each generated document — a notice, minutes, a certificate — is stored as a version with a cryptographic fingerprint. The wet-signed scan is bound to that exact version. A signature can never be claimed for a document that has changed since it was signed. Electronic signatures will be added on the same model.

In India, backed up

Data is hosted in India. The database is backed up nightly and documents are kept in versioned object storage in India.

Sign-in

The committee console uses session sign-in; the member and guard apps use device tokens that can be revoked. Roles decide who can see and change what — a member sees their own account; the auditor’s login is read-only.

Reporting a problem

If you think you have found a security issue, please write to [email protected]. We will reply within two working days.