Breadcrumbs News

Privacy Policy

Effective 7 November 2026.

Breadcrumbs (the App Store name is Breadcrumbs News) is operated by Ryan Unger. This policy describes the app and this website. Questions and deletion requests go to privacy@breadcrumbsnews.com.

This website

breadcrumbsnews.com is a set of static pages. It does not ask you to sign in, does not set its own cookies, and does not use analytics or advertising. The pages are served by a Cloudflare Worker. Cloudflare’s logs for that Worker can include the page requested, the time, and network information such as an IP address, so the site can be operated. This policy does not state a retention period for those host logs.

The app’s account data is not stored on this website. The API and the database are hosted on Render.

What the app does

You can browse a curated news desk and search stories already collected. Following a story requires an account. After you follow a story, Breadcrumbs looks for later coverage and writes a briefing when something material changes. The app is in internal testing. It is not a public App Store release.

Information the app collects

Account

Sign-in is Apple, Google, or an emailed code. An account can store:

• Email address, when the provider includes one. It is stored in lowercase.
• The Apple account id, the Google account id, or both, when you use those providers.
• Display name, up to 80 characters. A name that contains an http address is not stored. If a later sign-in does not include a name, a name already saved is kept.
• A photo URL from Google, and only if it is an https URL. The app loads that image from the URL when it shows the account button. Apple sign-in does not provide a photo. If a later sign-in does not include a photo, a photo URL already saved is kept.
• Which provider last signed in (Apple, Google, or email), and when the account was created.

The same email address is one account. Signing in with Apple or Google can attach that provider’s account id to an account that already has the email.

Google sign-in

The app uses Google Sign-In and does not pass a scopes list. On Android, the sign-in library this app depends on starts from Google’s default sign-in options, adds the email scope, and requests an ID token because a web client id is set. That ID token is the openid scope, together with profile from the default options. On iOS, the same library passes no additional scopes, and Google Sign-In adds the email and profile scopes. The app reads the ID token that SDK returns. No other Google scope is requested. The app does not ask for offline access, a refresh token, or a server authorization code.

The phone sends the ID token to our API. The API sends that token to Google’s tokeninfo endpoint (https://oauth2.googleapis.com/tokeninfo) to verify it, and checks that the token was issued for this app. We keep the Google account id (sub), the email if one is present, the name, and the picture URL. If Google marks the email as unverified, sign-in is rejected. We do not store the ID token. We do not call Gmail, Drive, Calendar, YouTube, or any other Google API.

Ryan Unger’s use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Google account data is used to create and sign in to your Breadcrumbs account and to show your name and photo on the account button. It is not sold, not used for advertising, and not sent to the model that judges stories. It is stored in our database on Render. The ID token is sent back to Google only to verify it.

Apple sign-in

The app asks Apple for your name and email. The phone sends Apple’s identity token to our API, and the name Apple gave the app on that sign-in. The API checks the token against Apple’s public keys. We store the Apple account id, the email if the token includes one, and the name if the app sent one. We do not receive a photo from Apple.

Email sign-in

You enter an email address. We create a 6-digit code and a sign-in link (postscript://sign-in). Only the SHA-256 hashes of the code and the link token are stored. The email address on that row is stored as text. The code stops working after 15 minutes. A second request for the same address inside 60 seconds does not create another code.

When RESEND_API_KEY and EMAIL_FROM are set, Resend receives the recipient address, the subject, the code, and the link, and sends the message. The deployment blueprint names those two variables. If they are not set and another mail URL is configured, that endpoint receives the same message. If neither is configured in production, email sign-in fails and nothing is sent. On a non-production server with no mailer configured, the message is written to the server log instead of being emailed.

Install id

The app creates a random id for the install and stores it on the device. It is not a hardware identifier. API requests send it in the X-Device-Id header. We store that id, when it was first seen, and, after you sign in, the account it is attached to. Signing out does not delete the install row or detach it from the account.

Push token

If you allow notifications, the iPhone or Android app gets an Expo push token and sends that token and the platform (a short string such as ios or android) to our API. The web app does not register a push token. We store the token on the install. A notification contains a shortened headline, a short status line, and the follow-up id. We do not send a notification when a check finds nothing material. If Expo reports the token as invalid, we clear it.

Preferences

We store the topics you chose, the theme (light, dark, or system), whether onboarding is finished, which outlets are included or excluded, whether the list is “all except” or “only these,” and whether paywalled outlets are hidden. The same record also holds two internal switches: an engine mode and whether a decision trace is shown. Before you have an account, preferences are stored for the install, and a copy is kept on the phone. The first sign-in copies the install’s preferences onto the account if the account does not already have any. Later sign-ins keep the account’s saved preferences.

Followed stories and notes

A follow-up stores the story (headline, source, link, date, summary, topic, and the other story fields needed to check it later), the timeframe, the date you picked, a note of up to 280 characters, the status, check times, and the briefing. It is tied to the install and, when you are signed in, to the account.

The note is not sent to the model. It is stored on your follow-up, shown back to you, and used on our server to write the line that begins “You asked to check on this specifically,” and to sort briefing items by ordinary word overlap with the note. The briefing saved on the shared story record can include that line, so it can include the note of the follow-up that ran the check. Another reader’s copy replaces that line with their own note before they see it. Deleting the follow-up deletes that follow-up, including the note stored on it. It does not delete the shared story record, which can still contain the note inside that saved briefing until a later check overwrites it.

Session

Each sign-in creates a session token (32 random bytes, shown as hex). We store only the SHA-256 hash, the account id, and the times it was created and when it expires. The raw token is returned once. The iPhone and Android apps keep it in secure storage. The web app keeps it in the app’s local storage. The token stops working 60 days after it is issued. Signing out deletes that session. Signing in again does not delete older sessions. There is no job that deletes expired session rows; an expired token is rejected.

How it is used

• To run your account and keep follow-ups available on the installs attached to it.
• To show the desk and search results according to your topics and outlet settings.
• To send a sign-in code or link to the email address you entered.
• To look for later coverage of a story you followed and to write the briefing.
• To send a push notification when a check finds a material change. The date you picked still produces a briefing in the app when nothing material turned up, and that result does not send a push.

Search queries for later coverage are built from the story’s headline, date, and summary. Your note is not pasted into those queries. The queries are sent to Google News RSS from our server. That request does not include your account, email, install id, or note. Candidate pages are fetched from publishers so the check can read a short lead. Those fetches do not include your account.

Who receives it

• Render hosts the API and the Postgres database (Oregon), and runs the scheduled job that collects news and checks follow-ups. Account, install, preference, session, email-code, follow-up, and story records are stored there.
• Resend receives the recipient address and the sign-in message (the code and the link) when email sign-in is sent through Resend. An alternate mail URL, if one is configured instead, receives the same message.
• Google Gemini receives the original story’s title, date, and summary (the summary is capped at 500 characters) and up to 8 candidate articles. Each candidate is a title, date, source, and the first one or two paragraphs, capped at 600 characters. The same kind of story text, without your note, can be sent when the model writes the two search queries for that story. Gemini does not receive your note, email, name, photo, account id, install id, or preferences. The deployment uses the Gemini model named gemini-flash-lite-latest unless that setting is changed. If an OpenAI key is configured and selected, the same story text is sent to OpenAI instead. OpenAI is not part of the deployment blueprint. This policy does not describe what Google or OpenAI do with prompts after they receive them.
• Expo receives the push token and the notification (shortened headline, short status line, follow-up id). On Android, Expo delivers that notification through Firebase Cloud Messaging. Our server does not send your account, email, or note to Firebase or to Expo beyond what is in the notification.
• Apple handles Sign in with Apple on the device. We retrieve Apple’s public keys to check the identity token. We do not send your Breadcrumbs note or follow-ups to Apple.
• Google handles Google Sign-In on the device. We send the ID token to Google’s tokeninfo endpoint to verify it, as described above.
• Cloudflare serves this website only. It does not host the app’s database.

How long it is kept

• Sessions stop working 60 days after they are issued. Signing out deletes that session. Expired session rows are not deleted on a timer.
• Sign-in codes stop working after 15 minutes. The code and the link token are stored only as hashes. The email address on that row is not deleted on a timer.
• Stories in the news archive are deleted when their publish date is older than 30 days, except the pinned demo and any story a follow-up still points at. A short cache of a publisher’s image or summary is reused for 7 days when it is useful and for 12 hours when it is not. That cache is not account data.
• Accounts, installs, preferences, push tokens, and follow-ups are kept until you delete a follow-up in the app, or until we delete them because you asked. There is no expiry job for them. Signing out does not delete the account, the preferences, the push token, or the link between the install and the account.
• Shared story-check records (the story, the search queries, judged article snippets, and the briefing saved for that story) are not deleted when you delete a follow-up, and there is no scheduled deletion for them. A note can remain inside that saved briefing until a later check overwrites it or the record is removed.

Selling and advertising

We do not sell personal information. The app and this website do not show ads and do not include an advertising or analytics SDK. We do not share personal information with advertisers.

Deletion

You can delete a single follow-up in the app. That removes that follow-up, including the note stored on it. Signing out removes the session on that phone and the token stored there. There is no delete-account control in the app.

To delete the account, email privacy@breadcrumbsnews.com. We will delete the account and the information we can tie to it, including sessions, preferences, follow-ups, install links, push tokens, email sign-in rows for that address, and a note of yours if one is still inside a stored briefing. The shared news text and the articles already judged for a story are about the story. They can remain when the record is still stored. This policy does not promise a number of days for that deletion.

Children

Breadcrumbs is not directed at children under 13, and we do not knowingly collect personal information from them. The app does not ask for an age. If you believe a child has given us personal information, email privacy@breadcrumbsnews.com and we will delete it.

Changes

If this policy changes, the new version will be posted on this page and the effective date at the top will change.

Contact

Ryan Unger
privacy@breadcrumbsnews.com