Transparency

How to check what app.perch.ws runs · Privacy policy

Perch's privacy promises are meant to be checked, not taken on trust. There are two levels to that, and it's worth being clear about which is which.

1. What the design guarantees

The strongest guarantee doesn't depend on our server at all. Sync chains are encrypted on your devices with a key that never leaves them, and app.perch.ws keeps no libraries. Even a server changed to misbehave couldn't read your feeds, what you read or your private notes. You can check this in the open-source code of the apps, which is where the encryption happens.

2. Which code the server runs

For the rest (accounts, shared notes, what the server logs) you need to know which code it runs. Every server image is built by the project's public CI from a commit on GitHub, published to GitHub's registry, and given a signed attestation saying exactly which commit and workflow produced it. app.perch.ws runs those images and reports its commit:

curl -s https://app.perch.ws/api/v1/server

The build.commit it returns is a commit you can read on GitHub. To check that the image for it was built there, from that code:

gh attestation verify \
  oci://ghcr.io/arifcinartekin/perch-server:<commit> \
  --repo arifcinartekin/perch

The reported commit is the newest one that changes what goes into the server; commits that only touch the apps, the docs or this site build no new image, so it can be older than the repository's latest.

This proves the image is genuine. It can't prove, from the outside, that the machine answering at app.perch.ws is running it: no ordinary server can prove that about itself. That's why the design in point 1 matters more, and why we keep as little as possible on the server in the first place.

Other servers

Anyone can run Perch, and change it. A server you don't run yourself may run different code. The apps show which server you're connected to; trust it as much as you trust whoever runs it.