This policy explains what the ondalet Android app (name.gpm.ondalet) does with data. It covers the app only, as it is designed today. The app is a beta. Today’s build keeps the sources and engines you set up and their credentials (encrypted, as described below), writes and reads backups, keeps your saved and recent searches, and searches the Newznab, Torznab and Prowlarr engines and the public torrent sites you add, showing the preview images they give. With your TorBox key it checks which torrent results TorBox has cached, adds a result to TorBox, lists your TorBox items, removes one when you ask, and plays their videos and audio in the app or in another player of yours. With a Usenet provider set up, it reads the articles of the NZB results you open and play straight from that provider. It does not download files yet, and it reaches apps-management only from the Info tab. The sections below describe each feature as it will work when it ships, and this page changes with every release that changes what the app does.

The short version: the app talks directly to the services you set up, and nothing about what you search, watch or configure goes to the developer. It has no analytics, no crash-reporting service and no advertising, and no Firebase or other Google service in either of its builds.

Who is responsible

Gabriele Proietti Mattia is the data controller for the processing described here. Contact: apps@gpm.name.

What the app talks to

ondalet has no server of its own. It connects, from the phone, to the services you add:

• Your Usenet provider, over NNTP with TLS, to read the articles of the files you choose to play or download.
• TorBox, through its API with your key (details below), to list your items and files, add to them, and play or download them.
• Indexers and torrent sites you set up, including custom Newznab and Torznab engines, a Prowlarr or Jackett of your own, and the public torrent sites you switch on (Knaben, The Pirate Bay through apibay, EZTV, YTS, Nyaa, Torrents-CSV, at the address you can change), to search them. Public sites take no account and no key.
• Image servers, for the preview image of a result when an engine gives one. The app loads it from the address the engine gives, which can be the engine’s own server or another site’s (a film database’s image server, for instance). That server sees your IP address and which image was asked for. With Preview images switched off in Settings, no image is requested at all.

Those services receive what a normal client sends them: your credentials, your search terms, the files you ask for, and your IP address. An engine you add with an http:// address (typically a Prowlarr or Jackett on your own network) is reached without encryption, its key included; the app says so when you type one. They are not run by the developer and have their own privacy policies; read them. Whatever you search for, add or watch goes to them and never to the developer.

What goes to TorBox

Only once you have saved a TorBox key or signed in with TorBox, and every call carries that key:

• After each search, the info hashes of the torrent results (the identifiers of the torrents, not their names and not what you searched for), to show which ones TorBox already has. Usenet results are not sent.
• When you add a result, the torrent’s magnet link, or the file itself: for an NZB or a .torrent that an indexer gives as a link, the app downloads the file from your indexer and uploads it, with the release’s name, so that your indexer’s link and its key never reach TorBox.
• When you open the Library, a request for your list of items with their files, repeated every 10 seconds while one is still downloading and the Library is on screen.
• When you remove an item, after you confirm, a request to delete that one item.
• When you open Settings or its TorBox page, a request for your account’s email address and plan, which the app shows and does not keep.
• Signing in with TorBox asks TorBox for a code, which you approve on TorBox’s own site; the app then receives your key and keeps it like a key you paste.
• When you play a file, a request for that file’s download link, then the file itself from TorBox’s servers. The link carries your key, so it never leaves the app: when you choose another player (VLC, mpv…), the app hands that player an address on the phone itself (127.0.0.1, with a random secret part) and passes the file through; the other app never sees the link or the key. That small server runs only while a notification says so, and stops after ten minutes without use or when you press Stop. A file read from your Usenet provider goes to another player the same way.
• When you tap Use my TorBox Usenet account in a Usenet provider’s form, a request for the Usenet account TorBox gives your key: its server, port, connections and user name (TorBox does not send the password). The app fills the form with it and keeps only what you save.

What goes to your Usenet provider

Only once you have set one up, over NNTP with TLS (or without, if you turn TLS off for that provider), signing in with the user name and password you saved:

• When you open an NZB result’s page, a check of a sample of its articles (whether the provider still has them) and the first part of its files, to see whether they hold a video or an archive and, for an archive, its headers.
• When you play, the articles of that file, as it plays and a little ahead.
• Test, in a provider’s form, signs in and asks about one article.
• A provider set to fill missing articles is asked only for the articles the others do not have.

The NZB itself comes from your indexer, through its link; that link and its key never reach the Usenet provider.

What stays on your phone

• Credentials (Usenet passwords, the TorBox key, indexer keys) are encrypted with AES-256-GCM under a key held in Android Keystore, which does not leave the device. They are kept in a place that is excluded from Android’s backup (the app declares allowBackup=false), so they are not copied to your Google account or to a new phone.
• The app lock’s PIN is never stored: only an Argon2id hash of it with a random salt, and the count of wrong tries with the wait they started, in a place excluded from Android’s backup and never put in ondalet’s own backups. The fingerprint is checked by Android; ondalet only learns whether it matched.
• Your sources and engines (without their secrets), settings, saved and recent searches and resume points (where you stopped in each file, by TorBox item, or by NZB, and file name, never the link) are stored in the app’s private storage, where no other app can read them. Resume points are not part of backups.
• Preview images are kept in the app’s cache, which Android may clear when space runs low.
• Usenet direct’s cache: the parts of files it has read, in the app’s private cache (5 GB unless you set another size in Settings, fewer when the phone runs short of space; Clear cache empties it).
• The NZB of a release you played, kept so that its resume point can reopen it, and deleted once it is more than 30 days old and no resume point uses it.
• Downloaded files are saved in the folder you choose.

Uninstalling the app removes what is in its private storage.

Backups

Backup and restore is a feature you start: the app writes a file where you choose, through Android’s file picker. The developer never receives it.

• Encrypted (the default): the file is encrypted with a passphrase you type, using a key derived from it with Argon2id and AES-256-GCM. Without the passphrase it cannot be read.
• Plain: readable JSON. Secrets are left out unless you switch them on, and if you do, anyone who gets the file gets your accounts.

Downloaded files are never in a backup.

What reaches the developer: apps-management, only when you use it

The only service of ours that the app reaches is apps-management (apps-management.gpm.name), run by the author and shared by the family’s apps. It is used for four things, all optional:

• Signing in, with an email address and a code we send to it. There is no Google sign-in and no Google library in the app. Signing in sends the address and nothing else: no source, no engine, no search. The app keeps a sign-in key on the phone; the service stores a one-way hash of it, and it stops working after a year without use or when you sign out.
• Licences granted by hand: when you are signed in, the app asks the service whether the author has granted you a licence. If you have not signed in, nothing is sent for that.
• Bug reports: sent only when you write one and press send. It carries what you wrote, the app version, your Android version, the phone’s manufacturer and model and your language, a screenshot only if you pick one, and an email address only if you type one. The service also keeps the IP address it came from and a keyed one-way hash of a device fingerprint (derived from the Android ID, which differs for every app), both used only to keep abuse out. The report is read and answered by hand.
• Feature requests and votes, likewise only when you send them. Asking and voting need a proved address so that there is one vote per person; the request is published once read, never your address and never who voted.

Your searches, sources, engines and what you watch are not part of any of these.

You can delete the sign-in identity and what hangs from it from the delete-account page.

What the app never does

• No analytics, no usage statistics, no crash-reporting SDK. There is no Firebase in either build.
• No advertising, no ad personalisation, no advertising identifier, no sale or sharing of data.
• No tracking across other apps or websites.
• No reading of your contacts, messages, photos or call history.
• The app ships no content and no list of content, and hosts nothing.

Permissions

What the app declares today, read from its merged manifest (the app’s own manifest plus its libraries).

The app also declares that it looks for installed video and audio players (Android’s package visibility), only to tell you when none is installed. Permissions for downloads will be added and listed here when they ship. Files are saved and backups are written through Android’s file picker, which needs no permission.

Legal basis (GDPR)

For readers in the EU/EEA and the UK:

• A report, a request, and the address you attach are processed on your consent, given by pressing send.
• Signing in and the sign-in key: your consent, given by asking for the code; withdrawn by signing out or by deleting the identity.
• The IP address and device fingerprint kept with a report or request are kept on the legitimate interest (Art. 6(1)(f)) in keeping abuse out of the service.

Retention

On the phone, until you delete it or uninstall the app. At apps-management, an address and what hangs from it are kept while you use it; one silent for five months is warned by email and deleted a month later, unless it has a licence recorded against it. Reports and feature requests are kept while they are useful, with the address removed when the identity is deleted. Details are on the delete-account page.

Your rights

Under the GDPR you may request access to, correction of, or deletion of your personal data, object to processing, and lodge a complaint with a supervisory authority. What the developer holds is the sign-in identity and its reports and requests: delete it from the delete-account page or write to apps@gpm.name. What the services you connect hold is for them to answer.

Children

ondalet is not directed at children under 13 and knowingly collects no data from them.

Changes

Material changes will be published on this page with a new date, and significant ones noted in the app’s changelog.

*Last updated: *