Sheaf Android App Privacy Policy

Effective: 2026-08-02.

This policy covers the Sheaf Android app binary published by Lupine Systems LLC at https://github.com/sheaf-project/android and on Google Play, IzzyOnDroid, and other app stores. It describes what the app does on your device and what third parties the app interacts with as part of running.

It does not cover:

• The Sheaf instance you connect to. That's a separate piece of software run by an operator (which may or may not be Lupine Systems). When you sign in, the app surfaces that instance's privacy policy and terms inside the login screen and in Settings → Server. You should read your chosen instance's policy before signing up; that's where most of the data you enter lives.
• The marketing site at sheaf.sh: see /privacy/.
• Lupine Systems' own hosted instances (test.sheaf.sh, app.sheaf.sh, etc.): see /service/privacy/. The mobile app is one of the ways you can connect to those instances, in which case both this policy and the hosted-service policy apply.
• The iOS app: see /mobile/ios-privacy/ (separate, because the third-party processors involved differ).

1. Data controller

For everything in this policy, the data controller is Lupine Systems LLC. See /legal/ for full company identification and contact details.

For data sent to a Sheaf instance via the app, the controller is the operator of that instance (which, for the official hosted services, will be Lupine Systems too).

2. What the app stores on your device

The app keeps the following on the device's local storage (specifically: Android DataStore, Android-Keystore-backed where applicable, and Room for cached content). None of it leaves the device unless you explicitly send it to your chosen Sheaf instance.

Tokens and cached content are wiped on sign-out and on app uninstall.

3. Data the app sends to your chosen Sheaf instance

When you use the app, it makes HTTPS requests to whatever Sheaf instance you've configured (https://...). The contents of those requests are whatever you do in-app: members you create, fronting switches you log, journals you write, files you upload, your account details, etc.

The processing of that data is governed by the operator of your chosen instance, under their own privacy policy. The Sheaf protocol does not bake any analytics or telemetry into client-server traffic; only data you create is transmitted.

If you run a self-hosted instance (your own or someone else's), the operator of that instance is the controller of that data — not Lupine Systems.

4. Third-party services the app talks to

The Android app interacts with the following third parties as part of running on Android. These are separate from any third parties used by your chosen Sheaf instance (which will be listed in that instance's own privacy policy).

4.1 Google (Google Play Services / Wearable Data Layer)

If you have the Sheaf Wear OS companion app installed alongside the phone app, the two communicate over Google's Wearable Data Layer, an inter-process communication mechanism provided by Google Play Services. This is required by the Wear OS platform; there is currently no FOSS alternative.

The Data Layer does not relay messages through Google Cloud servers. Per Google's documentation, Data Layer items are "private to your app and only accessible to your app on other devices," and the API works only between paired Android-or-Wear-OS devices over their local Bluetooth or Wi-Fi link — it does not function at all if the two devices are out of range of each other. Google Play Services on each device handles the local IPC and synchronisation queue, analogous to the role the operating system plays in any inter-app communication, but message contents are not visible to Google's infrastructure.

The data exchanged between phone and watch is your own app credentials (so the watch can sign in to your chosen Sheaf instance independently) and small UI-state messages. Both devices need Google Play Services installed for the channel to work; this is a property of running on Wear OS rather than something the Sheaf app introduces. If you don't install the Wear companion or don't pair a watch, the Wearable Data Layer is not used.

4.2 Push notifications (and why the build you installed matters)

The Android app is built in two flavours, and they differ specifically on this point. Which one you have is worth knowing.

The Play Store build (systems.lupine.sheaf) uses Firebase Cloud Messaging, Google's push service. Push is opt-in: nothing happens until you enable notifications and grant the Android notifications permission. If you do, the app registers with FCM, receives a device-specific token, and sends that token to your chosen Sheaf instance so the instance can address notifications to this device.

Google sees push metadata as part of delivering it: the target token, timing, and the payload the instance sends. How much detail is in that payload is a setting on the instance side, per notification channel, so if you would rather Google never see member names in a payload, use the lower payload-sensitivity setting when you configure the channel. Disabling notifications stops delivery; removing the device in the app's notification settings, or signing out, clears the token from the instance.

The open build (systems.lupine.sheaf.open, distributed via GitHub Releases and IzzyOnDroid) contains no FCM and no push provider at all. It ships a no-op token provider in place of the Firebase one, so there is no Google push dependency compiled into the binary and no token to register. If you want Sheaf on Android with no Google push involvement whatsoever, install that build. You can still receive front-change notifications through the channels that do not need a mobile push provider: ntfy, Pushover, web push, or a webhook.

This is a build-time difference, not a setting. Switching between the two means installing the other build.

4.3 Sigstore (transparency log)

Each released APK is signed by our CI workflow via sigstore/cosign keyless OIDC; signatures are recorded in the public Rekor transparency log. This involves no user data: only the signature, the cert tying it to our CI workflow, and the timestamp. The transparency log exists so anyone can independently verify the build, including you. See https://github.com/sheaf-project/android/blob/master/docs/VERIFYING.md.

This involves the user's device only if they choose to verify a build before installing it; the app itself does not contact Sigstore at runtime.

5. Permissions the app requests

The app does not request, and never uses:

• Location
• Contacts
• Phone or SMS
• Camera or microphone
• Storage outside its own sandboxed app directory
• Advertising ID

6. What the app does not do

• No analytics. No Google Analytics, Firebase Analytics, Plausible, Sentry, Mixpanel, etc.
• No crash reporting. No Crashlytics, no Firebase Crashlytics, no Sentry, no Bugsnag. If the app crashes, you can copy the crash dialog and send it to us, but nothing is reported automatically. In most cases, opening a GitHub issue is appropriate; for security-related issues please use a private GitHub security advisory or contact the development team as described in Sheaf's Security Policy.
• No advertising or ad-tech. No ad SDKs, no advertising ID lookups, no tracking pixels.
• No fingerprinting. No proprietary device-fingerprinting libraries.
• No telemetry of any kind that isn't explicitly under your control.
• No background data collection. The app makes network requests when you're actively using it, when an explicit feature like the fronting notification is checking for status, and (Play build, if you enabled push) when handling an incoming push. Those requests carry the same data as any other request you make, to your chosen instance and nowhere else. What the app does not do is collect or transmit anything about you in the background: no telemetry, no analytics, no beacons.

7. Where you got the app from

The app's distribution surface affects who sees what:

• GitHub Releases (sheaf-project/android/releases): GitHub records standard download logs. We do not have access to per-download identifying information.
• Google Play: Google Play collects download and install data per its own policies. This is governed by Google's privacy policy, not ours.
• IzzyOnDroid: a third-party F-Droid-compatible repo. Operated by IzzySoft; see https://apt.izzysoft.de/fdroid/index/info.
• F-Droid main repo: not currently planned (see the project's https://github.com/sheaf-project/android/blob/master/docs/PUBLISHING.md).

8. Children

The Sheaf hosted service is not intended for users under 16. The app itself doesn't enforce that — your chosen instance does — but in practice the app is most useful when used with an instance, so the same age guidance applies. See the hosted Terms.

9. Your rights

For data the app stores locally on your device, you control it directly: uninstalling the app removes everything; clearing app storage clears tokens and caches.

For data sent to your chosen Sheaf instance, your rights (access, rectification, erasure, etc. under GDPR / UK GDPR / CCPA / equivalents) are exercised against the operator of that instance, per their privacy policy. If your chosen instance is one of Lupine Systems' hosted instances, see /service/privacy/ §7 — including the universal-policy extension that means we honour those rights for anyone, regardless of jurisdiction.

10. Security

• Tokens are stored in DataStore backed by the Android Keystore where the device supports it.
• All network traffic is TLS-encrypted.
• The optional app-lock feature gates access to the running app behind biometric or device-credential auth at the OS level.
• App releases are double-signed: by the project's release keystore (the standard Android signature; pinned at first install) and by Sheaf's CI via Sigstore keyless OIDC. Both are independently verifiable by anyone — see https://github.com/sheaf-project/android/blob/master/docs/VERIFYING.md.

Responsible disclosure of security issues: [email protected], GitHub Security Advisories, or the project's SECURITY.md.

11. Changes

When this policy changes we'll update the Effective date at the top.

For material changes (a new permission requested, a new third party involved, new data collected or sent off the device) we'll also call it out in the release notes for the version that makes the change, on the Play listing and in the GitHub release, and flag it in the app's About section so it's visible to someone who installed before the revision. This policy covers the app binary rather than any particular instance, so it reaches you through the app itself rather than through any instance's mailing list.

If you use one of the Lupine-hosted instances, changes to that service are notified separately, per Terms §14.

12. Contact

Privacy questions, data requests, or complaints: [email protected]. See /legal/ for company details.