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.
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:
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.
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:
What that means for what you save:
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 at all: its links go straight to their destination, and there is no image in it that reports whether it was opened.
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.
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.
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.
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.
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.
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 message shows you its words, not its pictures. The reading view carries the text, the headings and the links of the message, and no picture of any kind. The stored pictures are used in two other places instead: the largest of them becomes the item's thumbnail, and all of them are what the server draws on when it photographs the message for you — 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.
Eight. Six of them are contacted only by the server, and two of them your own browser goes to. Each says below which it is:
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.
Every saved item has a Share block, 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 six: 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 two — micro.blog and Are.na — are posted by the server, with a token you gave it. 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; it is 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. Neither button exists until its token does.
This site, its database and its mail run on one server at DreamHost, which hosts it. Everything mailed out — a confirmation, the weekly email, 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.
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.
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.
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 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.
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 12 September 2026.