hello@andrioli.tech
PORCH

Privacy Policy

Last updated: 1 November 2026

The app collects no personal data

The app collects no personal data of the person who uses it, and it holds no account of its own and no profile. The account of the user lives on the deployment, under the rules of the organisation that runs it, and the backend of the maker holds the same account only so the relay can watch the deployment for the push.

There is no advertising network in the build and no crash reporter in it. The app tracks nobody, and it follows nobody across the apps and the websites of the device.

The places the app talks to

The app talks to the deployment the user names and to the backend of the maker. The backend of the maker is a Supabase project of Andrioli Holdings, and the publishable key of that project is public by design while the secret key never reaches a phone. The sign in happens between the phone and the deployment alone: the app registers itself on the deployment, and it redeems the code of the sign in with the proof key of it, so no secret of an OAuth2 application exists anywhere.

The user names the address of a Coder deployment at the first launch of the app. Every request the app makes for the work of the user goes to that address.

What the app sends

The app sends six things, and nothing else.

  • The session of the deployment. The app hands the access token and the refresh token of the session to the deployment the user names with every request, so the deployment can tell who asks. The deployment keeps the account of the user, the workspaces, the chats and the notifications.
  • The registration of the app. The app registers itself on the deployment, so the person names no keys at all. The app hands the name of the app and the address the deployment sends the code back to, and the deployment keeps the client identifier of the registration.
  • The check of the registration. The app asks the deployment whether the client of the registration is still there, and it hands the token of the registration with the question. The deployment keeps the client identifier of the registration.
  • The renewal of the session. The app hands the refresh token of the session to the deployment the user names, and the deployment answers with a fresh pair of tokens. The deployment keeps the session of the user.
  • The registration of the phone. The app hands the push token of the phone, the address of the deployment, the client identifier and the access token of the session to the backend of the maker, so the relay can find the phone and watch the deployment with that token. The backend keeps the device registration of the phone and the access token of the session there, and the registration ends when the user signs out of the deployment.
  • The counts of the analytics. The app hands the day and the name of the event to the backend of the maker, when the switch of the settings is on. The backend keeps the day, the name of the event and the count.

The counts of the analytics

The app counts how often it opens and which screens the user opens, and it hands every count to the backend of the maker. A count carries the day and the name of the event, and nothing else: no identifier of a person leaves the device with a count, and the count names no user, no device, no name and no address.

The switch in the settings turns the counts off, and the app then sends nothing at all.

What the app keeps on the device

  • The access token and the refresh token of the session, in the secure store of the device: the keychain on iOS and the equivalent store on Android. The tokens leave the secure store only to sign a request to the deployment.
  • The address of the deployment, the client identifier of the registration of the app and the token that manages that registration. The token reads the registration and deletes it, and it never leaves the device.
  • A cache of the data the deployment sent, so the app opens on the last data it had. The cache leaves the device with the app.
  • The actions the user makes while the connection is down, waiting in a queue on the device. The app sends them to the deployment when the connection comes back.
  • The registration of the phone, with the push token of it and the identifier of the Coder user. The app forgets it when the user signs out of the deployment.

The client secret of the OAuth2 application is no part of this. The app registered itself, so the client of it is a public one and no secret exists anywhere.

None of this leaves the device, apart from the tokens, which go to the deployment the user names, the registration of the app, which goes to that deployment, and the registration of the phone, which goes to the backend of the maker.

The permissions of the app

The app asks the device for the biometric, so it can unlock itself after it has been away: Face ID on iOS, with the reason NSFaceIDUsageDescription, and the biometric or the fingerprint on Android, with the permissions android.permission.USE_BIOMETRIC and android.permission.USE_FINGERPRINT.

The app asks the device for the permission of the notifications, so it can show the push of the deployment on the lock screen: android.permission.POST_NOTIFICATIONS on Android. The phone shows a push only when the user lets it, and a phone that says no holds no token for the relay of the maker.

The build declares three more permissions on Android, and the app asks the user for none of them: android.permission.RECEIVE_BOOT_COMPLETED, which comes with the module that carries the push of the deployment, and android.permission.ACCESS_NETWORK_STATE and android.permission.ACCESS_WIFI_STATE, which come with the module that reads the state of the network of the phone.

The app reads the notifications of the deployment inside the app and shows them in its inbox. The push of the deployment comes from the relay of the maker, which finds the phone through the registration of it.

The children

The app is meant for people who run a deployment of their own. It is not made for children, and no data of a child is collected.

The changes of this policy

Every change of this policy lands in the history of the repository, with the app. The date of the last change stands at the top of the file.

The contact

The organisation that publishes the app answers the questions about the app and about this policy at the address on the site of the organisation.