Security

What follows is how Patepang is built: design facts, not guarantees. The limits are in the next section, and the audit status is in the Current state section.

• End-to-end encryption. Messages, groups, updates, moments, photos, voice, and files are encrypted on the phone before they are sent, with libsignal (PQXDH with ML-KEM-1024, and the triple ratchet). The server only forwards content it cannot read.
• Sealed sender. For messages, the Patepang server knows the recipient but does not record the sender. The exception: the first messages after a tempel (at most 20 within 24 hours) use a token tied to that tempel, so the server knows those messages come from the person you did the tempel with.
• Keys that can be checked. Every account's keys are recorded in the key transparency log, which is public and only grows. Other people's phones check your keys before trusting them, so keys cannot be replaced silently. Long-lived records are signed twice, with Ed25519 and ML-DSA-65.
• Witnessed tempel. Whether the shakes match is checked in an enclave, that is, an isolated environment whose code can be proven; the server itself cannot make a tempel certificate.
• Keys stay on the phone. Private keys are stored with the phone's hardware key and are never sent. Your PIN is checked on the phone; Patepang never asks for your PIN.
• Little is stored. No email, phone number, or name on the server. The server does not keep IP addresses, sign-in logs, or app usage history, and server logs, without IP addresses or account ids, are kept for 7 days. What is still kept: the date last active, tempel history (with whom and when), and the time of key changes, which is public.
• Sealed notifications. Apple and Google only deliver 176 sealed bytes; the sentence on the screen mentions no name or content.
• Photos without metadata. Photos are sent without EXIF data or location, and the size of every media item is rounded up before it is encrypted, so the server only knows the approximate size.
• Travel mode and locked conversations. With six words, people, conversations, updates, and moments can be sealed so that the phone only shows stand-ins. Until the next hardening is finished, someone holding the unlocked phone can still count your connections (account ids, without names). Conversations can also be locked behind a PIN.
• Recovery through the people you meet. Three guardians, two of whom are enough, with a 48-hour waiting period that your old phone can cancel. There is also the emergency lock, for when one of your devices is lost or taken: from a device you still hold, all other devices are removed, then linking devices, changing guardians, and recovery are refused for 72 hours.

So that you can judge for yourself, this is what Patepang's design does not protect:

• The server knows which account has done a tempel with which account and when, who is a member of which group, and who is whose guardian. Not the content, but the links between accounts, yes. If you cut a connection on the day you met, the server can infer that too.
• Cloudflare, the network in front of the server, decrypts the connection encryption. It sees every request except the encrypted content: IP addresses, times, sign-in tokens, account ids, the recipient of every message, and the key of every media item. So, through IP addresses, Cloudflare can link a sender to a recipient, and a media uploader to its downloader.
• Apple and Google see the IP address and time of notifications, purchases, and app authenticity checks, and Cloudflare records the IP addresses of visitors to the patepang.com site and its subdomains. The app from the App Store and Google Play does not check for updates by itself; only test versions for testers ask Expo (see Privacy policy section 4.14).
• A tempel proves that two phones were shaken together, or that two people deliberately worked together from a distance to imitate it, for example by practicing the rhythm of the shake over a phone call. The host of an event room can let in people who are not present, and guardians can be talked into a recovery tempel from a distance by someone who claims to be you.
• Two of your guardians who collude, with a modified app, can open your account backup without a recovery and without you knowing. Choose guardians you trust.
• The copy on the recipient's phone is in the recipient's hands. “Delete for everyone” and disappearing messages depend on the app on their phone, and screenshots remain possible.
• A phone that has been compromised can read anything shown on its screen.

The details are in the Privacy policy.

Patepang has not launched yet. A security audit by an outside party is a requirement before the public launch, and has not yet been done. Patepang's code will be opened under the AGPL-3.0 license at the public launch, after the audit, so that anyone can check it (see Licenses).

Write to security@patepang.com in Indonesian or English. Tell us what you found, how to reproduce it, and what an attacker can gain. Do not include anyone else's data, and test only with your own accounts and devices.

In scope

The server and its cells, the enclaves and their attestation, the apps, the protocol and its formats, and the key transparency log.

Out of scope

Denial-of-service attacks by flooding traffic, findings in third-party services (report those to them), social engineering of our people, physical attacks, and results from automated scanners without a demonstrated impact.

• Acknowledge your report within 3 business days at the latest, with the name of the person handling it.
• Assess it within 10 business days at the latest: whether we can reproduce it, how severe it is, and what our plan is.
• Fix critical and high findings as fast as possible, normally within 30 days, and other findings within 90 days.
• Keep you informed at least every two weeks until it is fixed.
• Agree a disclosure date with you: normally once the fix has reached users, or 90 days after your report, whichever comes first, unless we agree otherwise.
• Name you in the release notes and the acknowledgements, if you want.

Not yet in force. This section is still a draft awaiting review by legal counsel. The way to report and the deadlines above already apply.

We will not pursue or support legal action against anyone who, in good faith, reports a vulnerability under this policy. Good faith means: testing only what is in scope, not reading, keeping, changing, or deleting other people's data, not disrupting the service for others, and giving us reasonable time before disclosing.

If a third party takes legal action against you for such research, we will state that you acted in accordance with this policy.

This contact and this policy are also listed in /.well-known/security.txt, in accordance with RFC 9116.