Nous AI Newsletter: Privacy Policy

Nous AI Newsletter has no accounts and never asks who you are. This is exactly what the app sends, what the server keeps, and for how long.

Last updated 2026-10-04

The short version. Nous has no accounts. There is nothing to sign up for, no email address to give, and no password. The app does not ask who you are and the server has no way of finding out. It keeps one anonymous identifier per installed copy of the app so that it can tell a real copy of the app from a script, and, only if you switch notifications on, the settings a notification needs. It contains no analytics, no advertising, and no third-party trackers, and nothing about you is sold or shared for advertising. If the app crashes, it sends a technical crash report that says nothing about what you were reading and is not tied to you or to your copy of the app. From version 1.2.3 it also measures how quickly its screens load, and you can switch all of this off in Settings. From version 1.2, the spoken summary of the day is written, translated and read aloud on your device; nothing you listen to leaves it. From version 2.0, the companies and models you follow, your reading history and your weekly recap stay on your device too. The one exception is your own choice: if you turn on breaking alerts, the list of what you follow is sent so that the server knows what to alert you about, and it is deleted when you turn them off.

Who is responsible

Nous AI Newsletter is made by Alp Özcan, an individual developer. For anything in this policy, including a request to delete data, write to hi@alp.me. Mail is usually answered within a few days.

There is no account

The app authenticates itself, not you. It uses Apple App Attest: on first launch your device generates a cryptographic key inside its Secure Enclave, and Apple vouches that the key belongs to a genuine, unmodified copy of this app on genuine Apple hardware. Every later request carries a short signature made with that key.

This proves that a request came from the app. It proves nothing about you, and it cannot: the key is created on the device, the private half never leaves it, and no name, email address, phone number or Apple ID is involved at any point.

What the server keeps

Two tables in the whole system hold anything at all that relates to an installed copy of the app, and from version 1.2 a third, used only if the voice for Listen is downloaded through Cloudflare. From version 2.0 there are two more, used only if you turn on breaking alerts or use Give a free week. This is all of it.

For every install

WhatWhyHow long
A key identifier: a value derived from the public half of the key your device generated. It is not derived from your device's serial number, your Apple ID or anything else about you, and reinstalling the app produces a new, unrelated one.To check the signature on later requests. 180 days after the last request that used it
The public half of that key.Same.Same
A counter of how many times the key has been used. To reject a captured request that is replayed.Same
Whether the key came from a development build or a released one, and this app's bundle identifier, which is the same value for every install. To tell a test build from a released one in diagnostics.Same
The date the key was registered and the date it was last used. To delete keys that are no longer in use.Same

There is deliberately no column for a user identifier, an IP address, a device name, or anything you have read. The table cannot answer the question “what has this person been reading” because it does not record it.

Only if you turn on notifications

The daily notification is off until you switch it on. When you do, the app registers with the server and it stores: the notification token Apple issues for that install, whether it is a development or production token, your device's language and region setting, your device's time zone, the time of day you chose, whether the notification is on or off, the app's version number, the key identifier above, when the registration was made and last refreshed, which edition was last delivered and when, a count of consecutive delivery failures, and, if the app proved a Nous+ subscription when it registered, the date that subscription ends. From version 2.0 it also stores whether the app wants a silent update shortly before your notification, and which edition that update last named and when. That silent update carries only the edition's date: it lets the app download the day's edition, and for Nous+ prepare the spoken brief, before you open it. Nothing is shown and nothing is sent back about it.

Switching notifications off deletes that row immediately: it is a delete, not a flag. If you never switch them off, the row is deleted 180 days after the app last contacted the server.

Only if you turn on breaking alerts (Nous+, version 2.0 and later)

Breaking alerts are off until you switch them on. When you do, the app sends the server the companies, models and topics you follow, so that it can tell you when something major happens to one of them. They are sent as entries from Nous's own list of companies, models and topics, which is the same for every reader. The server stores them next to the notification record above, keyed by that install's notification token, together with how many alerts a day you chose (one or two), your quiet hours, the date your Nous+ subscription ends (the only thing read from the subscription receipt, which is then discarded, as described below), and how many alerts it has sent you today. To avoid sending you the same story twice, it also keeps a short record of which stories it alerted that token about.

The list of what you follow is not sent at all while breaking alerts are off. Switching breaking alerts off deletes it immediately. It is also deleted with the notification record (when you switch notifications off, when you use Delete all my data, or 180 days after the app last contacted the server), and 30 days after your Nous+ subscription ends if you have not renewed it. The record of stories already sent is deleted after 30 days.

Only if the voice is downloaded through Cloudflare (version 1.2 and later)

When the app fetches the voice for Listen from Cloudflare (see Listening), it first asks the server for download links. So that one copy of the app cannot be used to download the voice over and over, the server keeps, per install and per day: the key identifier above, the date, how many download links it issued that day, and the total size of the files those links cover. These rows are deleted after 30 days.

If a copy of the app is used to request far more downloads than the app ever makes, the server may also record its key identifier, the reason and the date, and refuse it further links. That record is deleted with your data, or 180 days after the app last contacted the server.

Subscriptions and payment

Nous+ is sold through Apple's In-App Purchase system as two plans: 1 week free, then either US$2.99 per month or US$24.99 per year, until cancelled. Apple takes the payment. Your name, your Apple ID and your payment details go to Apple and are never sent to this server, which has no way to ask for them.

To decide whether a request is entitled, the app sends the signed receipt Apple gives it. The server checks Apple's signature on that receipt and reads six things from it: the app it was issued for, which subscription was bought, when it expires, whether it was refunded, whether it came from Apple's test environment, and the reference number described next. The receipt itself is then discarded. It is not written to the database, and no transaction identifier, purchase history, price or Apple ID is stored. The one exception, from version 2.0, is the keyed fingerprint described under Give a free week, and only if you use it.

The subscription reference number

So that one subscription unlocks one copy of the app rather than being passed around, the app generates a random reference number when you subscribe and hands it to Apple as part of the purchase. It is not derived from anything: not from your Apple ID, not from your device, not from you. Apple echoes it back inside every signed receipt for that subscription, and the server stores it next to the key identifier of the copy of the app that first presented it, along with when that happened, when it was last seen, and how many times it has moved to a different copy.

That is the whole of it: a random number, an anonymous key identifier and three dates. It is deleted when you delete your data, and automatically after a year in which the subscription is never presented.

The one other thing kept is that end date, and only if you have notifications or breaking alerts on: it is stored on the notification and breaking-alert records described above, and nowhere else.

Give a free week (version 2.0 and later)

A Nous+ subscriber can send a friend a free week. The app asks the server for a code, and the server hands out one of a stock of one-time offer codes issued by Apple, as a link you can share. The usable code is erased from the server as it is handed out; only a one-way fingerprint of it remains, so the same code is never handed out twice.

So that each subscription can give at most three free weeks in 30 days, the server stores, next to each code it hands out, the time and a keyed fingerprint of your subscription's original transaction number. The fingerprint is made with a secret key held only by the server and cannot be turned back into the transaction number; the number itself is never stored. It is not linked to your copy of the app, your key identifier or your notification record. These rows are deleted 400 days after the code was handed out.

The server never learns who receives the code. Your friend redeems it with Apple, which handles that redemption as it handles any purchase. Redeeming any offer code in the app (Settings, Redeem code) opens Apple's own redemption screen; nothing about it passes through this server.

You can view or cancel the subscription at any time at https://apps.apple.com/account/subscriptions. See the subscription terms for the rest.

IP addresses

Your IP address reaches the server, because that is how the internet delivers a request. It is used for one thing: counting requests per minute so that the free, unauthenticated part of the handshake cannot be abused. The count lives in memory, in one-minute windows, and IPv6 addresses are truncated to their network prefix before being counted. No IP address is written to the database, ever.

That covers the app's requests to the server. A crash report is a request to a different service, described under crash reports below, and that service is set not to store the address it arrives from. Asking for this web page is a separate thing again, handled by a separate host: see the website you are reading this on.

Diagnostic logs

The server writes a line per authenticated request containing whether the signature verified, the reason if it did not, the use counter, the path that was requested, and the first eight characters of the key identifier (a prefix, so a log line cannot be tied back to a row on its own). Turning notifications on or off writes a line with the language, time zone and time of day chosen. From version 2.0, two kinds of path are shortened before they are written: a request about breaking alerts is logged without the notification token in it, and opening a Storyline is logged without the company, model or topic it was about.

Nothing written by this server records a search term: the line records which endpoint was called, never the query. A search does travel to the server inside the web address of the request, so it can appear in the connection records the hosting provider keeps for its own operations, in the same way any website's search does. It is not stored here, not kept in the database, and not associated with an install.

These lines go to the hosting provider's log stream and are kept for as long as that provider keeps them. They are read to diagnose faults and are not analysed for anything else.

Crash reports

If the app crashes, it sends a crash report the next time it is opened, so that the fault can be found and fixed. Reports go to Sentry, a crash reporting service, and are stored in the EU, in Frankfurt. This is the one thing the app sends anywhere other than the server described above.

A report is technical. It contains where in the app's code the failure happened, the app's version and build number, the iOS version, and facts about the device such as its model, processor type, memory, screen size, language and region setting, and time zone. The same kind of report is sent in the rare case that the app has to rebuild its local storage at launch, with the database error code that caused it, and when a screen shows an error that suggests the service itself is broken, with a short fixed code naming the kind of failure.

From version 1.2.3, the app also sends performance measurements to Sentry: how long each screen takes to appear and to show its stories, how smoothly it draws, and when the app stops responding or is closed by the system for using too much memory. With a report, it sends a short trail of the screens opened before it and, for each story opened from a list, which list it was in, its topic (such as Research or Open Source, the same for every reader) and its position in that list. That is all a trail contains: never a story's title or address, and nothing you typed.

A report does not contain the title, text or address of anything you read or saved, anything you searched for or typed, any web address the app requested, a screenshot, or the key identifier and reference number described earlier. The reporting software would normally add two identifiers of its own that stay the same for one copy of the app; both are removed on your device before a report is sent, so two reports cannot be tied to each other, to a row on the server, or to you. Every other optional kind of collection the software offers is switched off: no usage or session counts, no recording of the screen, no record of the web requests the app makes, and no identifier sent to any other service.

You can switch it off. Settings, Data and offline, Send crash reports. It is on unless you turn it off; while it is off, nothing described in this section is sent at all, and turning it off stops reporting at once.

Sentry receives your IP address when a report arrives, because that is how the internet delivers a request, and is set not to store it. Reports are deleted automatically after no more than 90 days. Because a report carries nothing that identifies you, there is no way to find or delete one person's reports on request, which is a consequence of collecting nothing rather than an obstacle put in the way.

Kept on your device only (version 2.0 and later)

What is never collected

No name, email address, phone number, postal address, contacts, photos, calendar, microphone, camera, health or fitness data, or precise or approximate location. No advertising identifier. No fingerprinting. The app contains no analytics SDK, no advertising network and no third-party tracker of any kind, and no data leaves the app except the requests to this server, the crash reports described above and, from version 1.2, the download of the voice described under Listening.

Nothing is sold. Nothing is shared with data brokers. Nothing is used to build a profile or to target advertising, here or anywhere else.

Who else processes anything

WhoWhat they handle
AppleApp Attest, the App Store purchase, offer code redemption, delivery of notifications, Siri and Shortcuts and, from version 1.2, delivery of the voice for Listen. Apple sees what Apple always sees as the platform operator; this app sends it nothing extra. The Apple Intelligence and translation features Listen uses run on your device.
Fly.ioRuns the server, in Amsterdam. Handles the network connection and holds the log lines described above.
Cloudflare R2Holds encrypted backups of the server's database, in the EU. The backups contain the same tables and nothing more. From version 1.2 it also stores the files of the voice for Listen and delivers them to devices, in the EU. See Listening.
OpenRouterPasses the server's requests for written summaries, made from published news articles, to a provider that runs the model. The model currently used is Qwen, made by Alibaba. See below.
SentryReceives and stores crash reports and performance measurements, in the EU (Frankfurt). See crash reports above.

Those five are the whole list for the app and its server, and none of them is an analytics or advertising vendor of any kind. Each is bound by its own agreement to protect what it handles to the same standard set out in this policy, and none of them is permitted to use it for their own purposes.

The website you are reading this on

This policy, the subscription terms and the support page are published as static files on GitHub Pages, separately from the app and its server, so that they keep answering even when the server does not. Asking for one of these pages is therefore a request to GitHub, and GitHub records that request, including your IP address, in its own logs, under its own privacy practices, in the same way that any web host records a request for any page.

That is the whole of GitHub's involvement. It holds no app data: none of the tables above, not a notification record, not a subscription reference number. These pages carry no analytics, no cookies, no scripts, and nothing loaded from any other site, so reading them tells the app nothing about you and tells the author of this policy nothing about you either.

The news itself, and the summaries

Nous reads publicly available sources: RSS and Atom feeds published by news outlets, research labs and companies; Hacker News; arXiv; and public posts from a curated list of accounts on X. It ranks them and writes short summaries using a large language model, reached through OpenRouter.

All of that happens on a schedule, on the server, before any device asks for anything. Your reading is not part of it. Nothing you tap, search or open is sent to OpenRouter or to any other model provider, and no request from your device causes a server-side model to run. What is sent to OpenRouter is the text of published articles, which was already public.

Because the sources are third parties, Nous does not control what they publish. Summaries are generated automatically and can be wrong. If something in an edition is inaccurate, offensive or should not be there, write to hi@alp.me and it will be removed.

Listening (version 1.2 and later)

Listen reads a spoken summary of the day, one, two or five minutes long. All of it happens on your device.

Nothing you listen to, and none of your listening choices (the length, the voice, the speed, the language), is sent anywhere. They are stored on your device and nowhere else.

Downloading the voice

The voice is too large to include in the app, so it is downloaded once, about 100 MB, the first time it is needed, and updated occasionally. It comes from one of two places:

The files are the same for every copy of the app and contain nothing about you. Before downloading, the app checks that your device has enough free space; that figure never leaves your device. You can remove the voice at any time in the app's settings.

Deleting your data

There is no account to delete, but there are rows, and all of them can go, from inside the app, without asking anyone:

If you would rather ask a person, write to hi@alp.me. Because nothing held here identifies you, a mailed request has to name the identifier the app shows in its settings. There is no other way to tell which row is yours, which is a consequence of collecting nothing rather than an obstacle put in the way.

Your rights

If you are in the EU, the UK, or a US state with a privacy statute, you have rights to access, correct, delete and export what is held about you, and to object to its processing. Exercise any of them by writing to hi@alp.me. The practical answer is usually short, because the honest answer to “what do you hold about me” is the rows described above and nothing else. Crash reports are not part of that answer because they cannot be tied to a person or to a copy of the app.

The legal basis for holding them, under the GDPR, is legitimate interest: running the service, preventing abuse, and delivering a notification you asked for. Crash reports and performance measurements rest on the same basis: finding and fixing faults in the app, and you can switch them off in the app. There is no automated decision-making about you.

The things switched on by an explicit choice are the daily notification and, from version 2.0, breaking alerts. Withdrawing either choice is its toggle in the app: switching it off both stops it and deletes its record, in one action. Nothing else requires or relies on your consent, so there is nothing else to withdraw, and the rest can still be deleted, as described above.

Children

Nous is a news reader for a professional audience. It is not directed at children, collects nothing that would identify a child, and has no social features.

Changes

If this policy changes, the date at the top changes with it, and this page is the current version. Material changes will also be noted in the app's release notes.