Private by architecture.

Security approach

PES is designed as a multi-user system in which each signed-in account can access only its own workspace records. Security is layered across identity, application requests, database rules, hosting, and operating practices.

No connected service can honestly promise that hacking or data loss is impossible. PES reduces risk with specific controls, limits the data exposed to each component, tests critical boundaries, and updates the system as threats change.

Account access

• Verified email sign-in. Account access uses a time-limited email link or code instead of an app-managed password.
• Protected sessions. Web sessions use secure, HTTP-only, same-site cookies in production.
• Abuse controls. Authentication and sensitive requests are subject to rate limits and automated abuse checks.
• Server verification. Protected routes verify the current user with the authentication provider before loading data.

Data isolation

Personal tables use PostgreSQL Row Level Security. Read, create, update, and delete policies compare each record’s owner with the authenticated user. Application queries also include the account identifier as a second, explicit boundary.

Database functions that replace, seed, or reorder records operate only on the calling account. Per-account quotas and bounded import sizes reduce resource-abuse and accidental-overwrite risk.

Application and network controls

• HTTPS encrypts data while it travels between your device and PES.
• Mutation requests use origin and request-context checks to reduce cross-site request attacks.
• Security headers restrict framing, browser capabilities, resource origins, and information sent in referrers.
• Private app pages are marked not to be stored in shared browser or edge caches.
• Privileged server credentials are not shipped in browser or native app code.

Infrastructure and vendors

PES uses established providers for hosting, database infrastructure, authentication, and transactional email. Access to those provider accounts should use unique credentials, multi-factor authentication, and the minimum privileges needed.

Data at rest is protected by provider-managed infrastructure controls. PES is not end-to-end encrypted: authorized infrastructure operators may be technically capable of accessing data when required to operate, secure, or support the service.

What you control

• Secure the email account used to sign in and enable its MFA.
• Do not forward sign-in links, codes, exports, or private records.
• Sign out on shared devices and keep device software current.
• Export important records and protect those files wherever you store them.
• Treat unexpected sign-in messages as a warning and use only official PES domains.

Reporting a concern

A verified security-reporting channel will be published on withpes.com before public registration opens. In the first report, describe the affected page, the observed behavior, and safe reproduction steps. Do not include another person’s personal records, passwords, sign-in codes, or active session tokens.

Do not disrupt the service, use social engineering, access data that is not yours, or continue testing after confirming a vulnerability. PES will review credible reports and coordinate remediation and disclosure when appropriate.

Incident response

If PES confirms an incident, the response may include containing access, rotating credentials, preserving relevant logs, patching the issue, verifying account boundaries, and restoring from protected backups where necessary.

Affected users will be notified when required by law or when practical steps are needed to protect their accounts. This page will be updated as material controls change.