Effective date: 2026-08-22

Nib is an Android client for a Ghost publication chosen and controlled by the user.

Data processed by the app

Nib stores the following data on the device:

• the Ghost site URL and Admin API key supplied by the user;
• the Ghost staff access token, if the user supplies one to enable analytics, comment moderation or Social Web;
• account labels and locally cached site metadata, which includes the site address again;
• drafts, queued posts, attachment references, and display preferences;
• the last five search terms typed in each blog's timeline;
• the comment inbox, if comment moderation is enabled: for each new comment, its identifier, the title of the post it was left on, the commenter's display name as your Ghost site supplies it, and whether you have opened it;
• the last complete analytics dashboard for each blog, and the anomaly inbox derived from it — visit counts, growth figures, referrer, campaign, device and country totals, and post and newsletter titles, all aggregate;
• Nib Pro entitlement state and local aggregate monetization event counts;
• the Google Gemini API key, if the user chooses to supply one for the remote writing or alt-text fallback;
• the crash-reporting choice described below.

The Admin API key, the optional Ghost staff access token and the optional Gemini API key are stored using Android encrypted preferences backed by Android Keystore. The other items in that list, including the cached copy of the site address, are ordinary app-private files: unreadable by other apps, but not separately encrypted. Application backup is disabled, so none of it — credentials, drafts, queued content or search terms — is copied through Android Auto Backup.

Subscriber records are not stored on the device. Nib holds one local database table, for posts; member names, email addresses, labels, notes, subscription state and payment history exist only in memory while a screen that shows them is open, and are gone when it closes. That includes the CSV you import — its bytes go from the file you picked to your Ghost site without being kept — and the CSV you export, which is written only to the file you chose and is thereafter yours rather than Nib's.

One name is an exception, and it is deliberate. If you switch comment moderation on, the inbox has to know which comments it has already told you about, or every check would report the same ones again. So each new comment leaves a small entry behind: its identifier, the post title, and the commenter's display name as your site supplies it. The comment text is not stored, no email address is stored, and the entry never leaves the device. Disconnecting that blog deletes its inbox with it.

Data sent to other services

Nib sends Ghost requests directly from the device to the Ghost site configured by the user. Those requests can contain publishing content, media, tags, pages, newsletter settings, and member-management data necessary to perform the requested action. The operator of that Ghost site controls its data handling.

A few optional actions can involve services that are neither Nib's nor your blog's. They are worth knowing about because none is obvious from drafting a post.

The first is link previews. When you add a link to a post and ask Nib to fetch its preview, Nib requests that page directly from your device, identifying itself as Nib/1.0. The site you linked to therefore learns your IP address and the approximate time you were drafting, whether or not you ever publish the post. Nothing is fetched until you ask for a preview. If the page supplies a preview image, that image is loaded from whatever server the page names, and it is loaded again each time the post is later displayed — so that server sees the request repeat. If this matters for something you are writing about, skip the preview and paste the link as plain text.

The second is member avatars. On the Members screens, each member's picture is loaded from whatever address your own Ghost site supplies for it. On a default Ghost installation that address is a Gravatar URL derived from the member's email address, which means opening the member list can tell Gravatar's operator that those addresses were looked at. This follows from your Ghost configuration rather than from anything Nib chooses, and Nib displays a plain initial instead whenever no address is supplied.

The third is site analytics. Ghost 6 does not serve visit figures from your own site: it hands Nib a short-lived token and the address of the analytics service your Ghost installation uses, which for a Ghost Pro site is Tinybird. Nib then reads the figures from that address directly, over HTTPS, so the operator of that service sees your device's IP address and the date ranges you looked at. Nib will not follow that address to a plain-HTTP host, to an address on your local network, or to one carrying a username or password. Nothing is contacted until you open the Analytics screen; a blog that does not offer analytics is never contacted about it at all.

The fourth is comment moderation, and it is the only thing in Nib that talks to your site when you are not looking. Switching it on for a blog schedules a check roughly every fifteen minutes, on an unmetered connection and not on a low battery, against that blog's Ghost site and nothing else. Switching it off for that blog stops the checks.

The fifth is the Social Web, and it is different in kind from the rest of this section, because what it sends is not private data but public speech. A note, reply, like, repost or follow that you make in Nib goes to your own Ghost site, which then distributes it to every other server in the fediverse that is following the conversation. Those copies are outside your control and outside Nib's: deleting something later asks other servers to remove it and cannot make them. This is how the fediverse works everywhere, not something Nib adds, but it is worth stating plainly on the screen where a stray tap sends something. The identity token Nib uses for it is held in memory only, is never written to disk, and is sent only to your publication's own address.

Nib's writing assistant first uses Gemini Nano through Android AICore. The normal writing actions process the draft and proposal on the device. Android may need to download the on-device model before first use, and Nib starts that preparation only after you press the visible preparation button. If AICore is unavailable or a local request fails, Nib can show a separately labelled cloud fallback. That fallback runs only when you press a button whose label begins Send draft to Google; it sends the draft, current title and the selected writing instruction directly to Google's Gemini API using your own key. It is never selected automatically. A proposal from either path is never applied, saved, queued or published automatically.

The alt-text assistant also tries Gemini Nano on the device first. That normal Generate action does not send the image to Google Gemini's web API. If Gemini Nano cannot describe it, Nib may offer a separate button to use the Google Gemini API key you supplied in Settings. Nothing is sent when you attach an image, save a draft, publish a post, or use ordinary on-device generation. An image leaves the device only when you press that explicitly labelled BYOK fallback button.

For either local description or the explicit fallback, Nib prepares the image rather than giving a model the file you picked. It is scaled down so that its longest edge is at most 1024 pixels and re-encoded as a JPEG. Re-encoding discards the metadata the original carried, which for a photo taken on a phone typically includes GPS coordinates, the camera model and serial number, and the time the picture was taken. None of that metadata is sent, and the original file is never sent. In the fallback, what Nib transmits is the downscaled image and one fixed instruction asking for a one-sentence description. Your post text, your Ghost site address, your Admin API key, your account name and your other attachments are not part of the request.

If you choose either cloud fallback, the request goes directly from your device to Google's Gemini API, authenticated with your key and billed to your Google account; Nib operates no server and sees nothing. Google's handling of the text or image is governed by the terms attached to your own Gemini key, not by this policy. Generated writing remains a diff that you apply or discard; an image description is placed in the alt-text field for you to read, edit or delete. Nib never publishes either automatically. Your key is stored using Android encrypted preferences backed by Android Keystore, is kept separately from your Ghost credentials, belongs to the device rather than to any one blog, and can be removed at any time from the same Settings screen. Removing it disables both remote fallbacks.

System dictation is handled by the speech-recognition service installed on the Android device. Nib asks it to prefer offline recognition, but that preference is not a guarantee: the installed service decides whether it can work locally and its own privacy terms apply if it uses a network. Nib requests no microphone permission itself. It receives only the recognized text, shows it for editing, and adds it to the draft only after you confirm; it never publishes dictated text automatically.

If the user starts a Nib Pro purchase — a monthly or yearly subscription, or the one-time lifetime purchase — Google Play processes the transaction. Nib receives product and purchase status information but does not receive payment-card details. Google processes purchases under its own privacy terms.

Nib stores four values on the device to remember Pro access between launches: the access state, whether it came from a subscription or the lifetime purchase, whether the subscription is set to renew, and when Google Play last confirmed it. Nib does not store the purchase token, the order ID, or any Google account identifier, and none of them is written to logs.

Nib also records the first app version an install ever ran, so that people who installed Nib before Pro existed keep the features they already had. That value is a version number and identifies nobody.

The analytics screen described above reads your own site's audience figures and sends nothing about you anywhere; it is not an analytics SDK watching your use of Nib. This version carries no advertising, and no analytics SDK beyond the Crashlytics session events described in the next section — which are governed by the crash-reporting switch and stop when it is off. There is no separate usage-analytics product: Google Analytics for Firebase is deliberately not included. Monetization funnel counters remain on the device and contain no Ghost URL, API key, account/member identity, content, filename, purchase token, or order ID.

Crash reports

Nib includes Google Firebase Crashlytics. It is on by default, and it can be switched off at any time in Settings › Send crash reports. Switching it off takes effect immediately — it does not wait for a restart — and the choice is remembered, so a later launch will not quietly resume reporting.

These reports are used for one purpose: finding and fixing bugs in Nib. They are not used for analytics, profiling, advertising, personalisation, measuring usage, or building any picture of who you are or what you publish, and they are not sold or passed to anyone for those purposes.

When it is on, a crash sends the stack trace of the failure together with the envelope Crashlytics assembles for itself: device model, Android version, Nib version, locale, available memory and storage at the moment of the crash, and a randomly generated installation identifier. That identifier is created by Crashlytics, belongs to the installation rather than to a person, and is destroyed when the app is uninstalled or its storage cleared.

Crashes are not the only moment something is sent. While reporting is on, Crashlytics also records that the app was opened — a short session event carrying the same installation identifier and the same device, Android and Nib version details, and nothing about what you did in that session. This is how Crashlytics can say what proportion of launches ended in a crash rather than only how many crashes there were; without it a crash count means nothing. It is governed by the same switch: turn crash reporting off and these session events stop too. They carry no Ghost site address, no credential, and no content.

Nib attaches nothing of its own to a report. No Ghost site address, Admin API key, account label, draft, published post, image, filename, tag, page, newsletter setting, member record, purchase token, or order ID is included, and Nib holds no capability to add one — the code path to Crashlytics accepts an on/off value and nothing else.

Crashlytics is operated by Google, which processes the reports as a data processor for Nib under the Firebase terms and privacy information published at https://firebase.google.com/support/privacy. Google states that it encrypts this data in transit and does not transfer it to third parties other than its own subprocessors.

Reports already sent are held by Google and are removed under its retention practices; to have them removed sooner, contact pawel@orzech.me. Disconnecting the last Ghost account returns the crash-reporting choice to the default if you had left it on, so a device that is handed on or started over does not carry the previous owner's settings. If you switched crash reporting off, disconnecting your blogs does not turn it back on. Once you have said no, only you can undo it, from the same switch in Settings.

Retention and deletion

Nib has no accounts and no server. There is nothing to close and nothing held about a person under a login, so deletion is a matter of removing data from the device and, for crash reports only, asking for removal from Google.

How to delete your data in Nib — step by step

1. Remove one blog's data. Open Settings and tap Disconnect Current Account. This deletes that account's stored Ghost credential and staff access token, its local drafts, its queued posts, its cached site metadata, its newsletter and tag settings, its search terms, its comment inbox, and its analytics snapshot and anomaly inbox. If it was your last blog, this does everything step 2 does, including returning the crash-reporting choice to the default — unless you had switched reporting off, which is kept.
2. Remove everything. In Settings, tap Disconnect All Accounts. This deletes every stored credential and staff access token, all local drafts and queued posts, every blog's newsletter and tag settings, all search terms, every comment inbox, every analytics snapshot and anomaly inbox, and the cached images and site metadata. It also returns the crash-reporting choice to the default, unless you had switched reporting off — a refusal is kept.
3. Remove the rest. Uninstall Nib, or open Android Settings › Apps › Nib › Storage and tap Clear storage. This removes everything Nib has written on the device, including the Pro entitlement cache and the local monetization counters.
4. Remove your Gemini key. In Settings, under AI assistant key, tap Remove key. This disables the remote writing and alt-text fallbacks; on-device generation remains available on supported devices. This is a separate step on purpose: the key belongs to the device rather than to any one blog, so disconnecting a blog — or even all of them — deliberately leaves it alone. Uninstalling or clearing storage removes it too.
5. Stop crash reports. Crash reporting is on by default; turn off Send crash reports in Nib's Settings. Collection stops immediately and the choice is remembered.
6. Request removal of crash reports already sent. Email pawel@orzech.me from any address, stating that the request concerns the Nib Android app. No account identifier is needed, because Nib holds none.

What each step deletes, and what it does not

Deleted	Not deleted
Ghost site URLs, Admin API keys and staff access tokens stored on the device	Posts, pages, images and members already published to your Ghost site — those belong to your site and are deleted through Ghost, or through Nib while it is still connected
Local drafts, queued posts, and attachment references	Google Play transaction records, which Google retains under Google Play policies; refunds and transaction history are handled through Google Play
Cached site metadata, feature images and avatars; every comment-inbox entry, including the commenter names it held; every stored analytics dashboard and anomaly	Crash reports already delivered to Google, until Google's retention period elapses or the request in step 6 is actioned
Your saved search terms, and each blog's newsletter and tag settings	Server logs kept by any site whose link you previewed, by whatever host serves your members' avatars, or by the analytics service your Ghost site names — those belong to the operators of those services, not to Nib
The Pro entitlement cache and local monetization counters	Anything you posted to the Social Web, which your own site distributed to other servers; deleting it asks those servers to follow and cannot compel them
Your Gemini API key, by Remove key or by uninstalling — but not by disconnecting a blog or by Disconnect All Accounts, which leave it in place	Anything Google has already received and retains for a writing or alt-text request you made, which is governed by the terms attached to your own Gemini key
The crash-reporting choice, unless you switched reporting off — a refusal is kept

Deleting a Ghost integration key inside your own Ghost site revokes Nib's access to it regardless of anything on the device, and is worth doing if you believe a key has been exposed.

Security

Nib blocks cleartext network traffic in release builds, does not log Ghost authorization headers or response bodies in production, and stores no real secrets in its source repository. No security measure can guarantee absolute protection; users should rotate a Ghost integration key if they believe it has been exposed.

Children's privacy

Nib is a professional publishing tool and is not designed for children.

Changes and contact

Material changes to this policy will be published with the application update.

Nib is published by Paweł Orzech. For privacy questions or data requests, contact pawel@orzech.me.