Privacy Policy

Effective date: 2026-10-11 · Applies to: Keryx (desktop, Android, and iOS / iPadOS)

Keryx is a local-first RSS reader. This document explains, plainly and completely, what data the app handles and where it goes. Keryx is open source — every claim below can be verified directly against the source code at https://github.com/shimataro/keryx.

Overview

• Keryx has no user accounts and no server operated by the developer. There is nothing to sign up for, and Keryx never sends your data to its developer.
• All of your data — subscriptions, articles, read/starred status, tags, folders, settings — lives in a local database on your device, unless you explicitly turn on cloud sync.
• The app does not include any analytics, telemetry, crash reporting, advertising, or tracking of any kind. There is nothing to opt out of, because nothing is collected in the first place.

Data stored on your device

Keryx stores its data in two local files:

• keryx.db (SQLite): your feed subscriptions, cached article content (title, summary, body, author — fetched from the feeds you subscribe to, not submitted by you), read/starred status, tags, folders, and global app settings. It also contains a local full-text search index and internal sync bookkeeping, neither of which ever leaves your device (see below).
• local_settings.json: device-local preferences such as theme, font size, refresh interval, and window layout.

On desktop (macOS, Windows, Linux), both files live in the OS-standard application data directory (on macOS, inside the app’s sandbox container: ~/Library/Containers/works.merc.keryx/Data/Library/Application Support/Keryx; %APPDATA%\Keryx on Windows, $XDG_DATA_HOME/Keryx on Linux). On Android, they live in separate app-private storage areas that only Keryx can access — keryx.db in the app’s database directory and local_settings.json in its internal files directory — neither reachable by other apps, and not accessible to you directly without root. On iOS and iPadOS, they live in the app’s own sandbox container (the Application Support folder inside it), which only Keryx can access.

An OS-level cache directory — ~/Library/Containers/works.merc.keryx/Data/Library/Caches/Keryx on macOS, %LOCALAPPDATA%\Keryx\Cache on Windows, $XDG_CACHE_HOME/Keryx on Linux — stores favicon images and the article reader’s WebView profile as transient, local performance data. On Android, favicon images and the article reader’s WebView profile live in the app’s own private cache area instead (on iOS and iPadOS, the Caches folder inside the app’s container), which the OS may clear under storage pressure. Either way, this is separate from the application data directory above; see “Data retention & deletion” below for how to remove it yourself.

Keryx itself does not upload a copy of this data anywhere unless you opt into cloud sync (below). Ordinary requests to the feeds you subscribe to are separate; see “Network requests this app makes” below. Backups made by your device’s operating system, described next, are separate from Keryx.

Automatic backups (Android)

Android’s OS-level “Back up my data” feature is enabled for Keryx (allowBackup). This means keryx.db and local_settings.json may be included in Android’s automatic backup of app data to your own Google Account, and in device-to-device transfer when you set up a new phone — channels Keryx’s developer has no access to. Your cloud-sync credentials (below) are explicitly excluded from both. You can turn this off for Keryx at any time from your device’s Android backup settings (the exact menu path varies by device and Android version).

Device backups (iOS and iPadOS)

Like any iOS app’s data, Keryx’s files are included in your device backups — to your own iCloud account, or to your computer — which are channels Keryx’s developer has no access to. Keryx does not exclude its files from them. Your cloud-sync tokens (below) are kept in the Keychain and are not shared through iCloud Keychain; an encrypted device backup may restore them to a new device.

Optional cloud sync (Dropbox / OneDrive / Google Drive)

Cloud sync is off by default. If you choose to connect Dropbox, OneDrive, or Google Drive (one provider active at a time), here is exactly what happens:

• Availability: all three providers are supported on desktop. On Android, Dropbox and OneDrive are always available; Google Drive is available on any device with Google Play services installed, enabled, and up to date (Google’s OAuth policy for mobile apps rules out reusing the desktop client’s redirect-based flow, so Android reaches Google Drive through Play services’ own authorization API instead — see below). On iOS, iPadOS and macOS, Dropbox and OneDrive are always available and Google Drive uses Google’s own client type for Apple apps (see below).
• Authentication uses OAuth 2.0 with PKCE for Dropbox and OneDrive, performed directly between your device and Dropbox’s or Microsoft’s own servers — Keryx has no server in the middle of this exchange at any point (not for login, not for token refresh, not for the sync traffic itself). On Android, Google Drive instead uses Play services’ own AuthorizationClient, which likewise runs directly between your device and Google, hands out a short-lived access token, and involves neither a Keryx-operated server nor a stored refresh token. On desktop, Google Drive uses the same direct OAuth 2.0 PKCE flow as Dropbox and OneDrive. On iOS, iPadOS and macOS (the native app), all three providers use that same direct PKCE flow — Google Drive with Google’s client type for Apple apps, which needs no client secret — carried out in the system’s secure sign-in sheet (ASWebAuthenticationSession), so Keryx never sees your password.
• What syncs: your feed subscriptions, folders, tags, cached articles (read/starred status included), and global app settings.
• What never syncs: device-local settings (local_settings.json), your OAuth credentials, and the local full-text search index. These stay on each device independently.
• What gets uploaded: a snapshot copy of your local database (with the search index removed) is uploaded to a file in your own Dropbox, OneDrive, or Google Drive. For Google Drive, this is written to the drive.appdata scope — a hidden, app-only folder that does not appear in your regular Google Drive and that no other app can see. For Dropbox, standard file-content scopes are used. For OneDrive, the standard Microsoft Graph file storage scope is used and the sync file is stored in an app-specific folder within your OneDrive.
• Credential storage: on macOS and on iOS / iPadOS, access and refresh tokens are stored in the app’s own data-protection Keychain and never written to a file — if the Keychain cannot save them, the app tells you, and you connect the account again after a restart. On Windows and Linux, they are stored using your operating system’s secure credential storage (Credential Manager on Windows, Secret Service on Linux — inside the Snap package, an encrypted local store keyed by a per-app master secret from your desktop’s Secret portal). If the OS store is unavailable, tokens fall back to a local file instead — on Linux this file’s permissions are explicitly restricted to your own account (0600); on Windows, no such permission bit is set, and the file instead relies on Windows’ own per-user ACL inheritance on %APPDATA%/%LOCALAPPDATA% to keep other accounts out. On Android, tokens are encrypted with a key held in the Android Keystore before being written to a file in the app’s private storage; this file is explicitly excluded from Android’s automatic backup and device transfer. Tokens are never sent anywhere except directly to Dropbox’s, Microsoft’s, or Google’s own API, as required to perform the sync you requested.
• Once your data is in your Dropbox, OneDrive, or Google Drive account, it is subject to that provider’s own privacy policy and terms — Keryx has no further access to or control over it beyond the sync file it wrote.
• Disconnecting cloud sync in Settings stops future syncing immediately. It does not retroactively delete the sync file already sitting in your Dropbox, OneDrive, or Google Drive — you can remove that yourself from your cloud storage account if you wish.

Network requests this app makes

Keryx only talks to servers that are directly relevant to the feature you’re using, and always straight from your device — never through any server run by the developer:

• The feeds you subscribe to — the app fetches each feed’s URL periodically (or on manual refresh) to check for new articles, using conditional requests so unchanged feeds transfer no content. On iOS and iPadOS, iOS decides when the app may refresh feeds in the background (at roughly the interval you set in Settings, if the system allows it); new-article notifications are created on the device itself and no push-notification service is involved.
• Each feed’s own site/favicon — to display a small site icon next to the feed.
• GitHub (api.github.com for an unauthenticated, anonymous release check; github.com and *.githubusercontent.com when you actually download an update) — so the app can tell you when an update is available, and fetch it if you choose to install it. No account information, telemetry, or identifiers are sent. On Android, this is skipped entirely when Keryx was installed through Google Play (self-update only makes sense for the GitHub-distributed build); on iOS and iPadOS, Keryx never contacts GitHub at all — the App Store delivers updates. On macOS, the check instead reads the latest release’s update feed (appcast.xml, from github.com) — automatically, unless you turn that off in Settings → General, or when you choose Check for Updates… — and downloads the update it lists from github.com / *.githubusercontent.com only if you choose to install it.
• Dropbox, OneDrive, or Google Drive — only if you’ve connected cloud sync, as described above.
• Content an article itself references — when you open an article, any external resources its own HTML embeds (images, videos, social-media embeds, iframes) are loaded directly from their original hosts by the reader view, the same way a normal web page would. Keryx does not filter, proxy, or block these requests — what gets contacted depends entirely on the article’s own content, not on anything Keryx chooses to fetch.

Aside from what an opened article’s own content may additionally reference (above), that’s the complete list of kinds of servers Keryx itself decides to contact — no analytics or tracking payloads are ever sent with any of these requests, and no server outside this list is ever contacted.

Data retention & deletion

• If you’ve set a cache retention period in Settings, articles older than that window are deleted automatically, except starred articles and the 10 most recent articles per feed, which are always kept regardless of age.
• To erase all local Keryx data: on desktop, delete keryx.db and local_settings.json from the application data directory described above, along with the cache directory named in “Data stored on your device” (it holds the favicon cache and the article reader’s WebView data), or simply uninstall the app. On Android, since these files live in app-private storage you cannot reach directly, use uninstall, or Android Settings → Apps → Keryx → Storage → Clear storage (this also clears the app’s cache). On iOS and iPadOS, delete the app (this removes its container and cache); because iOS may keep Keychain items after an app is deleted, disconnect cloud sync in Settings first: Keryx then attempts to remove the stored tokens and, for Dropbox and Google Drive, to revoke them. Keryx cannot confirm that either step worked (an expired token, for one, cannot be revoked), so to be certain, also remove Keryx’s access from the provider account’s app permissions — always for OneDrive, which offers no way for the app to revoke its token (use your Microsoft account’s).
• See “Optional cloud sync” above for how to remove data from your cloud storage account.

OPML import/export

Importing or exporting your subscriptions as an OPML file is a purely local file operation — it reads or writes a file you choose on your own device and involves no network request.

Security

• Keryx’s own communication — cloud sync, update checks, and update downloads — always uses HTTPS. A feed URL you subscribe to is upgraded to HTTPS only if you don’t give it an explicit scheme; if you subscribe to a feed at an explicit http:// address (or one that redirects there), that feed’s content is fetched over plain HTTP, as it would be in any other RSS reader.
• Cloud credentials are stored using your operating system’s secure credential storage where available, as described above.

Children’s privacy

Keryx does not collect personal data from anyone, including children. No age verification is performed or required.

Changes to this policy

This file is version-controlled along with the rest of the source code. Its history of changes is publicly visible at https://github.com/shimataro/keryx/commits/HEAD/PRIVACY.md.

Verify it yourself

Keryx is open source under the MIT License. Every claim in this document can be checked against the actual source code at https://github.com/shimataro/keryx.

Contact

Questions about this policy can be raised via GitHub Issues: https://github.com/shimataro/keryx/issues.