Privacy

Athenana is a personal tool, running on a server its owner operates. It has no advertising. Nothing is sold, and nothing is handed to anyone for their own purposes. What leaves this server leaves to do something for you, and each case is named below — what goes, to whom, and whether it is your browser or the server that sends it. It counts one thing: how many times each link on the front page is followed to another site. That count is a number per link and nothing more — no address, no cookie and no identifier of any kind is stored with it, and nothing here can tell one reader from another, or the same reader twice. The counts are deleted after ninety days.

What the browser extension sends, and where

The extension sends what you save to the server you configure in its options — nowhere else. There is no Athenana service in the middle. It authenticates with an API token you generate on your own account and paste in yourself.

When you click save, it sends:

the page's address and title;
the page's description and preview image, if it publishes them;
a JPEG screenshot of the visible part of the tab — kept for your own board, and never published;
the text you had selected, if you used "Save highlight".

It sends these only when you click the toolbar button or choose the context-menu item. It does not read pages you have not asked it to save, and it does not run in the background on the sites you visit.

The permissions it asks for, and why

activeTab, scripting: Read the title, description and preview image of the tab you are saving, and photograph it. Granted for that one tab at the moment you act.
contextMenus: Add the "Save highlight" item to the right-click menu on selected text.
storage: Remember your server address and API token, in your browser's own extension storage.
One site, granted when you ask: Permission to talk to your server. The extension requests the single address you type into its options; it never asks for access to all sites. If an install prompt ever says it can read your data on every website, that is a bug — please report it.

What is shown publicly

Nothing you save is shown to anyone until you turn publishing on. That switch is on your account, it is off to begin with, and it is per account — not something the person running the server decides for you.

Once it is on, each item sits at one of three levels, and you choose which:

Private — visible only to you. This is where notes, images and highlights start.
Blog — it has a public page of its own, and appears on your blog if you have one. It is not listed on the front page.
Public — all of that, and it is also listed on Athenana's front page and sent to that page's feeds. Saved links start here; nothing else can reach this level.

What that means for what you save:

The front page carries links, and nothing you wrote. A note, an image or a highlight is never put on it, and neither is the note or comment you attached to a link — those are yours and stay off it.
It shows links from every account that has turned publishing on, not only the person running the server. If you turn it on, your public links appear there alongside everyone else's.
Any item can be moved back down to private at any time, and it then stops being shown anywhere but in your own account.
Separately, one setting keeps everything you save private whatever the individual items say. It is an emergency stop rather than the opt-in above: it hides everything at once and remembers your per-item choices for when you turn it off again.
The pictures on that page come from the publisher of the page being linked to — their own preview image. The screenshots are never published, because a screenshot is a photograph of the tab as it was and can catch a page you were signed in to.

Counting clicks on the front page. A link on the front page that points to another site goes through this server before it takes you there, so that following it can be counted. The count exists to choose the five links in the weekly email. What is stored is the link and the moment — never who followed it. Requests that identify themselves as robots, and the invisible fetches browsers make to speed up pages you have not clicked, are not counted; a robot that does not identify itself will be. Nothing on a blog, on a link's own page, in a feed, or anywhere you have to sign in is counted. The email itself contains no tracking: its links go straight to their destination, and there is no invisible image that reports it was opened. Beside each link it shows the same small picture and the same typeface as the front page, both served from this server, and every reader receives an identical copy — so when a mail client loads them the server can see that an issue was opened by somebody, never by whom.

The weekly email. If you ask for it, your address is stored here so it can be sent to you, and you are sent a link to confirm you meant it — nothing is sent to an address that has not followed that link. It is used for nothing else, it is never given to anyone, and every issue carries a link that removes it.

Blogs

If you choose a handle on your account page, you get a blog at /blog/<your handle>, and /blog lists the people who have one. Choosing a handle is what creates the blog; clearing it takes the blog down. Without a handle you have no blog at all.

Your blog is where your own writing appears. Anything you set to Blog or Public is on it — notes, photos and highlights, and the links you kept together with whatever you wrote about them. Unlike the front page, it is attributed to you, and it is yours alone: one person's blog never shows another person's items. It is also the one public place a summary can appear, if you switch that on — that part is the server's writing about a page rather than yours.

Feeds

The front page has RSS and JSON feeds, and each blog has its own pair. The front page's feeds contain links with nothing you typed, and a blog's feeds contain your writing. A blog's feeds carry less than its page does. If you switch summaries on, the summary appears on the blog page and on nothing else — it is kept out of both feeds deliberately, for the reason the next paragraph gives: a page can be taken down, and a feed entry cannot be recalled.

A feed is worth understanding before you publish. A page can be edited or taken down, but a feed entry has already been fetched and stored by whatever was subscribed to it. Moving an item back to private removes it from the feed going forward; it cannot reach into anything that already collected it.

Your blog can be followed from Mastodon

A blog here is also an account on the fediverse, and anyone on Mastodon — or anything else that speaks ActivityPub — can find it by your handle and follow it. A follow is accepted on its own; there is no approval step, because everything on a blog is already public. To check that a follow is genuine, the server fetches the follower's public profile from their server, once.

When you set a note, a photo or a highlight to Blog or Public, it is delivered to every follower's server, signed with a key this server holds for your blog, and that server keeps its own copy and shows it to them there. A link you kept is never delivered — only what you wrote — though the blog's public outbox lists links too, as recommendations, for anything that reads it. What is delivered is what the blog page shows: the text, its pictures, its tags as hashtags, and its address here. Like a feed entry, a delivered post cannot be reached back into: taking it down here does not remove the copies other servers already hold.

For each follower the server stores the address of their account and of their inbox, the name their server gave them, which server they are on, and whether it has been answering — a server that has stopped replying is skipped rather than posted to forever. Your blog's follower count is public, as the protocol requires; who they are is not, and the list is shown to nobody. Replies, likes and boosts sent back to the blog are acknowledged and discarded: nothing anyone else writes is stored here. Clearing your handle takes the blog down, and with it the account that can be followed.

Notifications and posting in

When a link is on the front page, the site it points to is told so, using the web's standard Webmention notification — the same way a blog learns it has been linked. Sites that accept these often display them publicly. The notice carries only the front page's address and the link itself, it is only ever sent for links the front page is already showing to everyone, and when a link leaves the front page a follow-up notice is sent so the site can drop the mention.
The server accepts posts over Micropub, so other people's apps can save things into your account. An app gets in one of two ways, and both are yours to revoke on the Tokens screen: a token you create there yourself and paste into the app, or, if the app speaks IndieAuth, by asking. Then you are shown the app's address exactly as it gave it, and what it wants to be allowed to do, and if you approve it receives a token for those permissions and your blog's address as your identity — so this needs a handle. The app is never fetched or looked up: what you see on that screen is the raw address, not a name or a logo chosen by whoever is asking. Nothing can post to your account without a token.

What the server stores

The items you save, their tags, and the screenshots and page copies taken when they were saved — along with what the server worked out about each one: a summary of what the page says, and the words read out of any picture. They stay on the server until you delete them. Deleting your account removes them. The summary is yours and is shown to nobody else, except that it can be published on your blog if you turn that on — a switch on your publishing settings, off unless you set it.

Two smaller records exist because two screens need them, and neither is shown to anyone but you. The date you last opened an item is kept, so Revisit can offer you things you saved and stopped going back to — opening something is what puts it away again. And each morning's reading list is kept for ninety days, so you can look back at a past morning rather than losing it at midnight — along with that morning's briefing on what your feeds carried, which is kept and thrown away on exactly the same ninety-day schedule.

Email you forward in

If you set up an address on Save by email, Athenana checks one mailbox on its own mail host every few minutes and turns what it finds into notes. The message is deleted from that mailbox once it has been read — whether it became a note or not.

What is kept is the subject and the text of the body, as a private note like any other, together with the message's own HTML so you can read it laid out as it was sent. A PDF attached to the message is kept too, as a private document of its own: its text is read so you can search it, and its first page is drawn for the board. No other kind of attachment is stored, and neither is the sender's address, the raw message, or anything else from its headers.

The secret part of your address is stored encrypted, beside a one-way hash of it that is what actually matches an arriving message to your account. You can read the address back on the Save by email screen whenever you need it — it has to go into a forwarding rule on every device you send from, and it travels in the open in every message sent to it anyway. Anyone who can read this server's database still cannot recover it without the key the application is configured with.

When you save a message, this server fetches the pictures it links to, once, and stores copies. A picture the sender attached inside the mail is stored here too. That matters more in email than anywhere else: newsletters carry invisible images whose only purpose is to tell the sender that a message was opened, and by whom. Images declared as 1×1 or 0×0 — the shape of a tracking pixel — are never requested. A tracker that declares an ordinary size is requested like any other picture, so this reduces tracking rather than preventing it. Your browser still contacts nobody: every picture you see is served from this server's disk.

Reading a saved item shows you its pictures, and every one of them is a copy kept on this server. Your browser is never pointed at the publisher's or the sender's own copy — not when you save it, and not years later when you come back to it. What you see is what this server fetched once, at the moment you saved. A picture it could not fetch is simply not shown, and the reader says so rather than reaching out for it. The stored pictures do two other jobs as well: the largest becomes the item's thumbnail, and for a forwarded message they are what the server draws on when it photographs the message — the picture labelled As it arrived on the item's own page, which is where a message looks the way it was sent.

Pictures too small to see — a single pixel, a spacer — are measured and discarded rather than stored, and how many were discarded is counted in the server's log. The count is all that is written: never a filename, an address or anything from the message.

Mail sent to an address the server does not recognise is discarded without a reply. Nothing is bounced back, deliberately: a bounce would tell whoever sent it which addresses exist. A count of how many messages were discarded is written to the server's log; the addresses they were sent to are not.

Email reaches that mailbox across the ordinary internet and is not end-to-end encrypted. Your mail provider, and every server the message passes through on the way, sees it as they would any other message you send.

Narrated audio is deleted 90 days after it is made — the same window the morning list's own history keeps. The article stays in your library, and asking for it again makes a new recording. An episode your podcast app has already downloaded is on your device and stays there; nothing here can reach it.

A file you import

A bookmarks file you upload — from a browser, Pinboard, Reeder, Instapaper or Pocket — is read on this server and nothing in it is sent anywhere: no page in it is fetched during the import, and the file itself is deleted as soon as its rows are in. A bookmark the file marks as private is saved as private. Reading the pages afterwards, a few hundred a day, is the same process described above for anything you save.

Creating an account with an email address

You can create an account with nothing but an email address. The server sends that address a link, and no account exists until the link is followed: until then it keeps only the address you typed, beside a one-way hash of the link, and that record is deleted within a day of the link expiring, an hour after it was sent, whether or not it was used. Following the link is where you choose a password, which is stored only as a one-way hash, never in a form that can be read back. If the address already belongs to an account here, the message says so and offers no second one. The page you typed the address into says the same thing either way, so it cannot be used to find out who has an account. A new account then opens when it subscribes.

Before you subscribe

Before you subscribe, you can already save from the iPhone app. Those saves are only stored: nothing is fetched from the sites they point to and nothing is sent to an AI service until your account opens. An account that has not opened can hold up to 200 saves. If it hasn't opened after 30 days, it is deleted along with everything saved to it, unless it currently has free access from us.

Paying for an account

A plan is paid for in one of two ways, and your card number never reaches this server in either. On the web, payment goes through Stripe: subscribing, changing your card, cancelling and reading your invoices all happen on Stripe's own pages. What this server keeps for a web plan is what it needs to know where you stand: Stripe's identifiers for you and your subscription, the plan and period you chose, whether it is paid and when it renews, and the kind of card and its last four digits, as Stripe reports them. In the iPhone app, a plan is an App Store subscription and Apple is the seller: Apple takes the payment, holds your card, and is where you cancel the subscription or ask for a refund. What this server keeps for an App Store plan is what Apple reports about it: Apple's transaction number, the plan and period, the price and currency, when it was bought, when it renews or ends, whether it will renew, and whether Apple refunded it. Apple sends no card number, name or address, and the server keeps none.

On the Own key plan, the AI work is done with your Anthropic key and nothing about those calls is recorded here: they are between you and Anthropic, your key is used for your account and nobody else's, and this server never charges you for them. On the Hosted plan the work is done with this server's key instead, up to a monthly and a yearly allowance, and the server records how many tokens each call used — what the call was for, which model answered, and what it cost — so the plan can be kept inside that allowance. Not the text of the call. Those records stay after an account is deleted, with nothing left in them to say whose they were.

When you subscribe on the web, the server keeps a record of it — the Stripe checkout, the time, and the exact words about renewal and cancelling that were on the page — because the laws on automatic renewal ask for one. When you subscribe in the app, it keeps which version of the app's subscription screen you bought from, with the purchase. Each time you sign in, the time and the way you signed in are recorded, on every account, and nothing else about it: not your IP address, not your browser. Sign-ins are kept for a year. Both exist for one case: if a payment is disputed with your bank, the operator may send Stripe, by hand and for that charge only, the subscription record, the dates and addresses of the billing emails, your sign-in dates after the charge, and how many items were saved and how many AI calls were made after it — counts, never what you saved. A payment taken by Apple is Apple's to settle if it is disputed, and this server sends Apple nothing about your account for it.

The billing emails come from this server: a note of what you signed up for when you subscribe or move to Hosted, a reminder about a month before a yearly plan renews and once a year on a monthly one, and a message when a card is declined or Apple cannot renew an App Store plan, when a subscription lapses, when free access is about to end or has ended, and before a lapsed account is deleted. Which were sent, when and to what address is kept with the account. An account given free access by the operator carries a record of that too: the plan, until when, who granted it, and any note they added.

A subscription that lapses — two failed payments on the web, Apple failing to renew an App Store plan once any grace period it gives has run out, a refund from Apple, or a cancelled plan reaching the end of what was paid for — keeps sign-in, reading, export and deletion, and stops everything else; your blog is hidden, not deleted, and renewing brings it back. After 180 days lapsed, the account is deleted along with everything in it, with an email 30 days, 7 days and 1 day before. An account whose payment is in dispute with the bank is treated the same way. Whatever happens to your subscription, you can always export everything you saved. The exports are text: the pictures and PDFs themselves stay on this server, and go when the account does.

If a card network warns that a payment made on the web was probably fraud, that payment is refunded in full and the subscription is cancelled at once, so the card is not charged again; the account then stops as a lapsed one does. No email is sent to the account about it; the operator is told. The warning, the charge and the amount are kept as a record of the refund, even after the account is deleted.

Deleting your account cancels a web subscription first, and removes this server's record of it and of any App Store one. Stripe keeps its own record of your payments under its own privacy policy, and this server cannot delete that. Deleting your account does not cancel an App Store subscription: only you can, with Apple, and Apple goes on charging for it until you do. The account screen says so before you delete it. If Apple goes on reporting that subscription afterwards, the server keeps its transaction number and plan with nothing to say whose it was, so the operator can see a purchase no account owns. Plans are sold in the United States only. On the web, a billing address from anywhere else has its country written to the server's log beside the account.

Third parties

Nine. Six of them are contacted only by the server, and three of them your own browser goes to. Each says below which it is:

Anthropic, to generate tags, to read text out of images, to summarise a saved page, to rank the morning reading list, and to write the daily briefing at the top of it. Saved page content is sent for those purposes and is not used to train models. The server sends it; your browser never talks to Anthropic.
The briefing is the one place where something you have not saved is sent. Once a day, the server sends the headline and the short summary of every item your subscribed feeds published in the past day — whether or not you have read it, saved it or opened it — and asks for a few paragraphs on what the day held. Which feeds you subscribe to is not sent, and neither is anything from your own library. It is one request a day for your whole account, made overnight while the reading list is built, and it does not happen at all if you have no feeds or nothing was published.
There is a second one, for feeds you tick “Summarise this feed's stories every morning”. For each story such a feed published in the past day, the server asks for five short facts — who, what, when, where and why. It sends the feed's own summary of the story when that is substantial; when it is a line or less, the server fetches the article itself, once, and sends its headline and text; if the page cannot be fetched, the short summary is sent instead. That fetch is the server's, not your browser's, it happens only for feeds you have ticked, and nothing from your own library goes with it. At most 30 stories a morning.
If you add your own Anthropic key, all of these go to your Anthropic account rather than this server's, and nothing about them is recorded here. On a Hosted plan they go on this server's key, which records how many tokens each call used and nothing of what was in it, and a Hosted plan does not get the morning briefing, the five facts or the ranking of the reading list.
Apple, in two unrelated places. The first is Sign in with Apple, which is one of the three ways to sign in here — a passkey, or an email and password, never involve Apple at all. Signing in with Apple takes your browser to Apple, at appleid.apple.com, so Apple sees your IP address and that you are signing in to this site. What happens after you approve it is between Apple and the server, and all Apple tells the server is an account identifier and nothing about what you save. The second is a plan bought in the iPhone app, where Apple is the seller. When you buy, the app hands Apple a random token this server made for your account — not your name, your email address or anything you save — so that Apple's record of the purchase can be matched to your account here. Apple then tells the server about that subscription, and the server asks Apple about it, using the facts listed under Paying for an account; Apple sends no card number, name or address. Nothing about how you use the account is sent to Apple. Your phone talks to Apple for the purchase, and the server talks to Apple about it afterwards.
Stripe, to take payment on the web, and only if you pay there. Subscribing, changing your card, cancelling and reading your invoices take your browser to Stripe's own pages, where you type your card and billing address; Stripe sees those, your IP address and your browser, and this server never sees your card number. The server gives Stripe your name and email address when it first sends you there, and afterwards asks Stripe whether you have paid; Stripe also works out the sales tax. Both your browser and the server talk to Stripe.
The Internet Archive, when a site refuses to serve the server. Many publishers block automated requests, and when that happens the address you saved is sent to archive.org to look for an existing public copy of the page, so its text can be read. Only the address is sent, and only for a page the server could not fetch itself. This is the server's request, not your browser's.
Google, in three unrelated places. The first is a video — a saved song, or a saved YouTube link. For a song the server searches YouTube for the same recording. For a YouTube link there is nothing to search, because the address already names the video; the server only fetches its cover picture. Either way the cover is copied onto this site, so a page with a video on it loads nothing from Google and tells them nothing about you until you press play. Pressing play loads the player into your browser from youtube-nocookie.com, and Google will see your IP address and which video you watched. It is one of two things here that can affect somebody merely reading a public page, rather than the person who owns the account; a saved podcast episode's play button is the other, described after this list. The second is Google News, which the morning reading list searches; that one is the server's request, and is described below.
The third is reading an article aloud. When you flag a saved article to listen to, its text is sent to Google's speech service and comes back as audio, which is stored here. Nothing else about the item goes with it — not its address, not its tags, not who saved it — and the audio in your feed is served from this server's own disk, so your podcast app never talks to Google. It happens only for articles you flag, one at a time, and never on its own. If you add your own Google credential on the Podcast settings page, it goes to your project rather than this server's.
Amazon, and only if you use it. Press Send to Kindle while reading a saved article and its text, its picture, its address and any passages you kept from it are mailed to the Kindle address you saved, where Amazon converts the file and keeps it as a personal document in your Amazon account. Nothing else about the item goes with it — not its tags, and your note only if you tick the box for it — and nothing is sent unless you press the button, one article at a time. The address is accepted only if it is at kindle.com, so this cannot be turned into a way of mailing your reading anywhere else. The server sends it; your browser never talks to Amazon.
MyMind, and only if you bring a key. Paste your MyMind API key on the MyMind settings screen and the server can import your library from it — your objects, tags, notes and the screenshots MyMind took — with that key, when you run the import. Nothing of yours is sent to MyMind beyond the key and the requests — and, when you press Share on a saved link, that link and its title, described under Sharing below. The key is stored encrypted and can be forgotten on the same screen, and nothing happens without it. The server's request, not your browser's.
Algolia, which runs Hacker News's search. The morning reading list searches it, once per topic. The server's request, not your browser's.
Flipboard, for the same reason: the morning reading list asks it for each topic's feed. The server's request, not your browser's.

Podcast episodes are the ninth, and it is not one company.

A saved Overcast or Apple Podcasts episode gets a play button. Athenana recognises the episode from the page it saved and copies its artwork onto this server, so a page carrying an episode loads nothing from anyone and tells nobody it was opened — the same guarantee the video player above makes, by the same mechanism: the player carries no address for the audio until you press play.

Sharing is the tenth, and it is eleven services you pick between.

Every saved item has a Share block unless you switch sharing out off, and every button in it hands something out, which is why they are named here even though nothing comes back. What leaves is the same for all eleven: the original address you saved and the item's title — and, for two of them, the item's picture. Never the archived copy, the screenshot, the summary, the tags, your note or the passages you kept. And nothing is shared unless you press the button, one item at a time.

Four of them — Bluesky, Mastodon, RecLeague and Hacker News — are links your own browser follows. Pressing one opens that service's composer, signed in as you, with the address and title already in it; the service sees your IP address and those two things the moment its page opens, whether or not you then post. Mastodon's is the server you named on the sharing settings screen, not anyone else's. RecLeague is one of the two places a picture goes along with the link, and only for an item you have published: it fetches the picture from this site, at the same public address anyone could.

The other seven are posted by this server, with a token you gave it, and no button exists until its token does. micro.blog receives the title and the address as a short post on your blog. Are.na receives the address and, when the item has one, its picture — the one you chose or the page's own, never a screenshot — as a block in the channel you chose, and reads the page for itself; without a picture from here it would show a screenshot it takes of the page, which is why one goes along, fetched from this site at an address that stops working after a day, whether or not the item is published. When you connect Are.na the server also asks it once which channel you meant, so a typo is caught on the screen you typed it on. Pinboard, Raindrop, Readwise Reader and Karakeep each receive the address and the title as a new bookmark in your own account there — Pinboard in whatever privacy your account there defaults to, Raindrop into Unsorted, Karakeep at the address you gave for your own server. MyMind receives the same through the key you gave for importing from it; there is no second key, and if that key can only read, the share tells you so. When you connect Pinboard, Raindrop, Readwise Reader, Karakeep or Are.na the server makes one request with the token to check it works, and stores nothing if it does not.

And the one that sees all of it

This site, its database and its mail run on one server at DreamHost, which hosts it. Everything mailed out — a link to finish creating your account, a link to set a new password, a confirmation for the weekly email, the billing emails, a file for your Kindle — leaves through DreamHost's mail servers, and the mailbox that Save by email reads is one of theirs. A host can see whatever is on the machine, which is why it is named once here rather than beside each thing above.

Your podcast feed has no password, and that is not an oversight.

A podcast app cannot sign in, so the private feed of narrated articles is protected by its address alone: a long random string nobody can guess. Anyone you give that address to can listen to everything in it, so treat it as a key rather than a link. It is never linked from anywhere, it asks search engines not to index it, and you can replace it at any time from the Podcast settings page — which stops the old one working immediately. Nothing is in the feed unless you flagged it.

Pressing play is the moment that changes, and what it contacts is not a company this page can name. The audio comes from wherever the show hosts it, which is the publisher's choice and differs per show — often through a measurement redirect that exists to count downloads. That host will see your IP address, the browser you are using, and that this episode was played. Play buttons appear on public pages as well as your own, so this is worth knowing whether or not you have an account.

What the morning reading list searches for

The daily list is built early each morning by searching three places — Google News, Hacker News and Flipboard — once each per topic. What is sent is the topic word and nothing else: no account identifier, no cookie, and nothing about what you have saved. All three see the server's address rather than yours, because your browser never contacts them; the list that comes back is a set of links to follow if you want them, and nothing on the page loads from any of the three. One more request can go to Google, and only when you open a Google News story to read it here: its link is a Google address rather than the publisher's, so the server asks Google where the story lives, sending that link and nothing else. Google then learns that the story was opened, by this server, not by you; the publisher's address is kept, so a story is asked about once, or at most once a day if Google gives no answer.

The topics, though, come from your own collection. The fifteen searched each day are the ten tags you use most, plus five drawn at random from the rest of your vocabulary. So while those three learn nothing about you as a person, they do see, over time, what this account reads about. You can drop a topic on the Discover screen, and it is then never searched for again.

The server also fetches the pages you save, directly, in order to archive and screenshot them.

When you open a story from Discover, the server fetches it for you. It reads the article and the pictures inside it, once, and shows you the result from here — so the publisher sees this server ask for the page, never your browser, and learns nothing about who opened it. The copy is kept for a day so going back to it costs nothing, and then deleted unless you saved the story. If the page cannot be read, you are offered a link to the publisher instead, and following it is your browser's own visit.

Pictures inside a page you saved

When you save a web page, this server also fetches the pictures inside its article, once, and keeps copies. That happens while it is already reading the page, so the site learns nothing it has not just learned a moment earlier. Those copies are what the reading view shows you afterwards.

The simple alternative — pointing your browser straight at the publisher's own copies — would tell that publisher every time you reopened your own archive, which page you went back to, and from where. Pictures declared as 1×1 or 0×0 are never requested, and pictures too small to see are discarded once measured rather than stored.

Pictures from your feeds

When a feed you subscribe to publishes a thumbnail with an item, and that item reaches your morning list, the server fetches the picture and keeps a copy. The same happens once for a feed's own logo. The pictures you see on the Discover and Feeds screens are then served from here.

This is deliberate, and it is the reason those pages are slower to build than they would otherwise be. The simple way to show a feed's picture is to point your browser straight at the publisher's copy — which would tell every publisher on the screen your IP address, your browser, and which page you were looking at, every time you opened the list, for articles you never clicked on. Fetching it here means your browser does not contact the publishers at all, and they see the server once rather than you repeatedly.

Contact

This is one person's project. Questions, and requests to delete an account and everything in it, go to support@wyome.com, which reaches a person rather than a ticket system.

Last updated 5 October 2026.