Privacy

Denison 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; for an assistant you connect, which company is yours to choose. It counts two things: how many times each link on the front page is followed to another site, and how many times the front page and each link’s own page are visited. Each count is a number per link or page per day 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 Denison service in the middle. It authenticates with an API token you generate on your own account and paste in yourself. The Firefox version is the same extension, signed by Mozilla and installed from this site; it reads and sends exactly what the Chrome version does.

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;
a copy of the page as your browser is showing it, when you save a link or a highlight — the whole page, not only the part on screen, and including whatever the site shows you because you are signed in. Its scripts and styles are taken out first, and so is every form field and editable box, so a message you were typing or a password your browser filled in is not sent; text a page copies out of such a box into the page itself, as a live preview does, can still be in it. The page’s hidden settings are taken out too — every meta tag except the ones that describe the page, and every data attribute — but an address in a link or picture is part of the page and is kept as it is. The copy is kept for your own board, never published, and read only if the site will not let the server read the page. A page larger than 2 MB is not sent at all, and if the copy would make the save too large to send, the save goes without it;
the text you had selected, if you used “Save highlight”;
on a YouTube video, the words of its transcript, if you have YouTube’s transcript open on the page — read from the page as you see it; the extension never asks YouTube for it.

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, except to re-check the pages you have asked it to watch.

The permissions it asks for, and why

activeTab, scripting: Read the title, description and preview image of the tab you are saving, copy the page, and photograph it. Granted for that one tab at the moment you act.
contextMenus: Add the “Save highlight” and “Watch this page” items to the right-click menu.
storage: Remember your server address and API token, in your browser’s own extension storage.
alarms, offscreen: Check the pages you asked it to watch, about once an hour: it fetches each one in your browser — with your own sign-in in Chrome; Safari sends none — reads the items in a hidden extension page, and sends the titles, links and a short excerpt of each item it found to your server. It also fetches the page once when you pick it, to check the items are there. Nothing else is read, and a page you stop watching, or whose site you remove from the extension’s permissions, is never fetched again.
One site, granted when you ask: Permission to talk to your server. The extension requests the single address you type into its options and, when you choose “Watch this page”, the one site that page is on; 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 Denison’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.
Links you make between your own items, and the Kept with this list on each item, are shown only to you; a public page shows the words of a link, and links them only to things that are themselves public.

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, 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.

Counting visits. Opening the front page, or a link’s own page, adds one to that page’s count for the day, and the total for the last ninety days is shown on the page itself. What is stored is the page and the day — never who opened it. Robots and prefetches are left out the same way as for clicks, with the same caveat: a robot that does not identify itself will be counted.

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 until somebody opens that link and presses Confirm. It is used for nothing else, it is never given to anyone, and every issue carries a link that removes it.

A blog’s email. A blog can offer its posts by email if its writer turns that on. If you ask for it, your address is stored here so the posts can be sent to you, and you are sent a link to confirm you meant it — nothing is sent to an address until somebody opens that link and presses Confirm. It is used for that blog’s posts and nothing else, it is never given to anyone, and the writer sees how many people subscribe, never who. Each email carries a link that removes you, carries no tracking, and is the same for every reader of that blog.

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.

A blog can live on its writer’s own site instead. Its public feed carries everything the blog shows, and denison.app then forwards its blog pages to that site; nothing that is not already public is added to the feed.

If you connect a Bluesky account, each new blog post is also posted there — its text, its link and any pictures already on the blog — and deleted there if you make the post private or delete it, or delete your account. A lapsed subscription, or switching your blog off, leaves posts already sent where they are; disconnecting stops new ones, and you can disconnect at any time. Nothing private, and no summary, is ever sent.

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. If you switch summaries on, a link’s summary goes into the blog’s feeds as well as onto its page, in place of the page’s own description. The front page’s feeds never carry one. Because a feed entry cannot be recalled (see the next paragraph), switching summaries on publishes them for good to anything that has already fetched the feed.

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.
A news reader app such as NetNewsWire or Reeder can sync the feeds you follow over the Google Reader API, using a Reader app token you create on the Extensions page and can revoke there. It can read your feeds and mark them read, and starring an article saves it to your library; it cannot see the rest of your library, and which articles you have read is kept only for that app and never shown in Denison.
You can connect an AI assistant, such as Claude, to read your library. It sees what you see here — every item including private ones, their notes, summaries, highlights and stored text, but never screenshots — and can change nothing. When it searches with a question, or with three or more words, this server sends the search words, and the titles, tags and opening lines of the matching items, to Anthropic so the results can be ranked by meaning, just as a search on your board does. That counts against your searches by meaning for the day (at most 50 a day through an assistant) and, on a Hosted plan, against your AI allowance. What it reads goes to that assistant’s company under its own terms, so connect only one you trust. Each connection has its own token, listed under Settings → Tokens, and revoking it stops it at once.

What the server stores

The items you save, their tags, and the screenshots and page copies taken when they were saved — the server’s own copy, or the one your browser sent or you pasted when a site would not serve the server — 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 (newsletter issues are not among them), 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, Denison 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, or a Word, Excel or PowerPoint file, attached to the message is kept too, as a private document of its own: its text is read so you can search it, and a PDF’s first page is drawn for the board. No other kind of attachment is stored, and on this address 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.

A second address, if you ask for one, collects newsletters instead of saving them. It is separate from the one above, and the one above works exactly as described there. Each issue that arrives at the newsletter address is kept here, up to a limit on how many issues and how much space one account’s newsletters may take, together with who sent it, as the whole message; past that limit new issues are dropped; this is the one place Denison keeps a sender’s address or a raw message. Issues are kept for 90 days from the day they arrive, or until you tell it to forget that sender, whichever is first, and then deleted along with their files. If you tell it to forget a sender, that sender’s address is kept on a short list so later mail from it can be refused, until you undo that. Nothing in an issue is fetched from anywhere until you save it: opening one shows you its words, with no pictures, so the sender is not told you opened it. Saving an issue works exactly like forwarding the same message: it becomes a private note, its pictures are fetched once and stored, and the sender and the raw message are not kept with it. Until you save one, issues are not sent to the AI briefing or to any model.

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.

The morning email, if you switch it on

On Today you can ask for an email at seven in the morning, your time, when something you marked is due. It lists the titles of those items, each linked to its page here, and on a day it already goes, up to three things you saved on that date in earlier years, and goes to your account’s address through the same mail service as every other message this server sends — so that service, and your own mail provider, see those titles. It carries no tracking image and no wrapped links. It is off until you switch it on, and nothing is sent on a day with nothing due.

The watch email, if you make a watch rule

On Discover’s settings you can add a watch rule — a site, a feed or some words — and having one is what turns this email on. Once a day, at seven in the morning your time, new entries in your feeds that match a watch rule are emailed to your account’s address, listed under the rule they matched: each entry’s title, linked to its own page at the site that published it, and the feed’s name. It goes through the same mail service as every other message this server sends — so that service, and your own mail provider, see those titles and the wording of your rules. It carries no tracking image and no wrapped links. Nothing is sent on a day with no matches, and deleting your watch rules stops it.

Music, if you switch it on

The artists you follow are kept on your account. Once a day the server sends Anthropic the names of up to fifty of them, the artist and title of up to thirty songs you saved, and which recent picks you marked More like this or Not for me — nothing else from your library — and asks for songs you might like. Each suggestion is checked against MusicBrainz, a public music database, which receives the artist and title; the ones that play are found on YouTube, which receives the same search.

If you give a city for shows near you, it is sent to Apple once to find where it is, and stored as that city’s name and a point rounded to about a kilometre — never your device’s location. The server sends Ticketmaster the name of each artist you follow, once, to find them in its listings; then each day it sends that point, the distance you chose and which of those artists to look for, and keeps the shows it returns. Clearing the city deletes both and every show.

If you connect Apple Music, Spotify or YouTube, once a week the server creates a playlist there of that week’s picks, which tells that service the songs. You can also make one of the past seven days’ picks yourself, once a day, from Discover settings. To do it, the server keeps the sign-in it was given — and, for Spotify, the client ID and secret of the Spotify app you registered — encrypted, and uses them for nothing else except an import you ask for. Under Discover → Artists you can import artists from one of your Apple Music or YouTube playlists, or your Apple Music library: the server reads the artist names in it (on YouTube, each video’s channel name) and the titles of your playlists, shows them to you, and keeps only the artists you tick. A link you paste to a public Apple Music playlist is read with this server’s own Apple key, so nothing of yours goes with it. Disconnecting deletes them at once.

Films and books

When you save a page about a film, a series or a book — an IMDb, Letterboxd, Goodreads or Open Library page, or one whose own markup names the work — the server looks the work up so its card can show the poster or cover, the year, who made it and its trailer. Only the title, the year, the author or director, or the page’s own id for the work is sent, to TMDB for films and series and to Open Library (or Google Books, when Open Library has nothing) for books; nothing about you and nothing else from your library. The poster or cover is copied to this server once, and your browser only ever loads our copy. A trailer plays from YouTube only when you press play, exactly like a saved song’s video. If a page’s address says nothing but it reads like a review, its title, its description and the first 2,000 characters of its text are sent to Anthropic to ask which work it is about — the same call, on the same key, as tagging. Saves older than this are checked without that call.

For a film or series, the server also asks TMDB where it can be watched in the US — which services stream it, offer it free, or rent and sell it — using TMDB’s own id for it and nothing else, and asks again each week while it is on your Watch shelf. The services are shown by name, with the date they were checked; their logos are never loaded. When nothing streams it, the page links to Amazon and Apple TV searches for it; the Amazon link carries Wyome’s affiliate tag, the same for everyone, as described below for lists.

If the film is in the public domain — published more than 95 years ago, or marked public domain by the Internet Archive — its title and year are sent to the Internet Archive to find a copy, and the item page can play it. Nothing is loaded from the archive until you press play; from then on your browser fetches the film from archive.org directly, so the archive sees your IP address as it sees any visitor’s.

Discover → Watch and Read show a shelf of what you marked to do, and a few picks made from the genres, directors and authors of the films and books you saved, shelved and finished, and the ones you add yourself. That whole list is shown beside the picks, where you can remove anything on it; nothing you only opened or looked at is used. Candidates are found at TMDB and Open Library by those names, and on plans with extras the names of up to fifteen of them and that list are sent to Anthropic to choose among. If a saved article talks about books, its title and the first 8,000 characters of its text are sent to Anthropic once to name the books it discusses, at most ten; only the names are kept, and a book two or more of your saved articles name is looked up at Open Library and offered as a Read pick. Either section can be switched off in Discover settings, which hides it and stops its picks. If you upload a Kindle’s My Clippings.txt, the server reads it, keeps each highlight on its book as a private item, looks each book up at Open Library, and deletes the file.

When you save a podcast show — its Apple Podcasts or Overcast page — or add one by name on the Cast tab, its Apple podcast id or its name is sent to Apple’s podcast directory to recognize it, and its artwork is copied here once. Its description is read from the top of the show’s own feed, the first 64 KB at most, so the show’s host sees a request from this server, and nothing about you. When a show is picked for you, the same read also gives its newest episode’s title, date, length and the address of its audio, and the pick gets a play button. Nothing is requested for that episode until you press play; then your browser fetches the audio from wherever the show is hosted, often through a redirect that counts downloads, and that host sees your IP address. If you upload a subscriptions file from your podcast app, it is read once and deleted; the shows it lists are kept on your account as “Already subscribed”, and each one’s name is looked up the same way. The Cast picks look in Apple’s directory for other shows by the hosts and networks, and in the genres, on your Cast list, and send it those names and nothing else.

If a saved page reads like a list — “the best westerns”, “what I read this year” — its title, its description and the first 12,000 characters of its text are sent to Anthropic to name the books, films, series, bands, albums and podcasts it recommends, at most 25. Each is then looked up — books at Open Library, films and series at TMDB, bands and albums at MusicBrainz, podcasts in Apple’s podcast directory — by its name and maker only, and only the ones found are shown on the item, with covers copied here. Nothing is added to your library until you press Save. Each also carries plain links to Bookshop.org, Libby or JustWatch, and an Amazon search link (for a book, a Kindle Store search as well), and each Amazon link carries Wyome’s affiliate tag, the same for everyone, so Amazon can attribute a purchase to Wyome and we may earn a commission; nothing about you is in the link. A recognized book’s own page and each book among the Read picks carry the same Kindle Store search link, with the same tag. Once you are on Amazon, Amazon sees you as it sees any visitor.

If a saved page is a recipe roundup, its title, its description, the first 12,000 characters of its text and its links are sent to Anthropic to find which links are the recipes and to copy out any recipe the text writes in full, at most 25. Only pages the roundup itself links to are shown, and a recipe copied from the text is kept only if every line of it is on the page. Nothing is added to your library until you press Save or Add to shelf. A roundup that publishes its recipes on the page is read from the page alone.

Pressing Watching now, Reading now, Listening now, Casting now or Cooking now on a film, series, book, album, song, podcast or recipe puts that work’s title, its maker and our copy of its cover on your blog’s /now page, whatever the saved item’s own visibility; nothing else about the save goes with it, and the page links to the item only if the item is public itself. Finishing it, or Take it off, removes it, and a recipe comes off by itself after a week. If you then choose to post about it, the post is an ordinary blog post.

The shows email, if you ask for it

Under Discover’s settings you can ask for an email on Monday mornings, at seven your time, listing new shows near your city by artists you follow: each one’s artist, venue and date, linked to its Ticketmaster page. It goes to your account’s address through the same mail service as every other message this server sends — so that service, and your own mail provider, see those shows. It carries no tracking image and no wrapped links, and nothing is sent on a week with no new show.

A file you import

A bookmarks file you upload — from a browser, Pinboard, Reeder, Instapaper or Pocket, or Safari’s Reading List (from its export or a copy of its Bookmarks.plist) — 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. Everything from a Reading List 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, if you arrived by following somebody’s “Save to Denison” link, that link, so it can be offered once your account is made. That link is deleted when the account is made, or with the rest of the record if it never is: the 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; posts already sent to Bluesky stay there. 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

Fourteen. Nine of them are contacted only by the server, four of them your own browser goes to, and one you choose: the company behind an AI assistant you connect. Each says below which it is:

Anthropic, to generate tags, to read text out of images and describe what they show, to summarise a saved page, to rank search results by meaning, to rank the morning reading list, and to write the daily briefing at the top of it, and, if you switch on music, to suggest songs from the artists you follow and the songs you saved, and to ask which film or book a saved review is about, to name the works on a saved list page, to name the books a saved article discusses, to find the recipes a saved roundup links to or writes out, and to choose among Watch and Read picks. 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. The briefing request does not say which feeds you subscribe to, and nothing from your own library goes in the briefing request. 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.
The feeds you have told Denison you already read elsewhere are treated the same way. Each night the server fetches up to 500 of them — its request, not your browser’s — keeps their latest entries here, and lists the past day’s below Discover → News when you ask to see them. Their headlines and short summaries go into the same briefing, in the same one request a day, exactly as above. Take a feed off your ignored list and it is not fetched again.
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 use your own Anthropic key, run this server, or have had free access since launch, the server also sorts your feeds into folders for news reader apps: it sends the name of each feed you subscribe to or read elsewhere, its website, and up to five of its recent headlines, once when your feeds are first sorted and then only for feeds added since; newsletters and watched pages are never sent.
Searching with a question or several words also sends your search words, and the titles, tags and opening lines of the matching items in your library, so the results can be ranked by meaning. Pressing Answer from these also sends up to 2,000 characters from each of the five best-matching items (your note, its summary or its saved text), so an answer can be written from them.
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, the ranking of the reading list, feed folders or music picks, and its Watch and Read picks are chosen without a model call.
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.
If you switch on music, Apple also receives the city you type for shows near you, once; and, if you connect Apple Music, each week’s picks as a playlist; and, if you import artists from Apple Music, the request for a playlist’s or your library’s artist names. Connecting Apple Music loads Apple’s MusicKit into your browser from Apple, on that one page and only when you press Connect.
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 and your browser did not send a copy of. A saved Apple News link is the one exception: your browser’s copy is of Apple’s page, not the publisher’s, so for the publisher’s page it points to, archive.org may still be asked. This is the server’s request, not your browser’s. And, for a public-domain film you saved, to find a copy to play: the server sends its title and year. When you press play, your browser fetches the film from archive.org.
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. Both buttons also appear on your Discover lists, your feed search and your Feeds page, where pressing play is likewise the first request to anyone. 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.
Music’s picks are found on YouTube the same way as a saved song, and, if you connect YouTube, each week’s picks are made into a playlist in your account; and, if you import artists from a YouTube playlist, the request for its videos’ channel names.
YouTube, in detail. Denison uses YouTube API Services; by connecting YouTube you also agree to the YouTube Terms of Service, and Google’s own handling is described in the Google Privacy Policy. With your permission Denison creates a private playlist in your YouTube account each week and adds that week’s picks to it, and, when you import artists, reads the titles of your playlists and the channel names of the videos in the one you choose. It stores only the sign-in Google gives it (encrypted), the link to the latest playlist, and the artists you tick to follow; nothing else it reads is kept. A followed artist’s name is used like any other: up to fifty names a day go to Anthropic to suggest songs, and Anthropic does not train its models on that data. Nothing from your YouTube account is sold, used for advertising or shared with anyone else. Disconnecting YouTube under Discover settings revokes Denison’s access with Google and deletes the sign-in at once; you can also revoke it yourself at myaccount.google.com/permissions. Denison’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.
Apple, for saved map links. When you save a Google Maps or Apple Maps link, this server sends the pin’s coordinates — and nothing else about you or the item — to Apple, once, to draw a picture of the map, which is then stored here. A map link is saved private; it appears on your front page or blog only once you make it public. Pressing Explore map on a map link — yours, or a published one anyone can see — loads Apple’s interactive map from Apple’s servers into that browser, which from then on talks to Apple directly; nothing contacts Apple before the press.
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.
Bluesky, only if you connect it: the server, with the app password you gave it, posts each new blog post to your account there, and deletes it if you make the post private, delete it, or delete your account.
MusicBrainz, a public music database, to find an artist you search for or follow, to check that a suggested song exists, and to look up a song’s code (its ISRC) when a playlist is made, and to confirm a band or an album named on a saved list. It receives artist names, song titles and its own ids, and nothing about you. The server’s request, not your browser’s.
TMDB (The Movie Database), to recognise a saved film or series, copy its poster once, find its trailer, find where it can be watched (data from JustWatch) and, for Watch picks, find recent films by the directors on your list. It receives titles, years, names and its own ids, and nothing about you. The server’s request, not your browser’s. This product uses the TMDB API but is not endorsed or certified by TMDB.
Open Library, and Google Books when Open Library has nothing, to recognise a saved book, copy its cover once, and, for Books picks, find new books by the authors on your list. They receive titles, author names and ISBNs, and nothing about you. The server’s request, not your browser’s.
Apple’s podcast directory (the iTunes Search API), to recognize a podcast show you save, add by name or subscribe to in your podcast app, to find a podcast a saved list names, and, for Cast picks, to find other shows by the hosts, networks and genres on your list; its artwork is copied once. It receives show names, Apple podcast ids, host and network names and genre words, and nothing about you. The server’s request, not your browser’s.
A podcast’s own host, to read its description from the top of its feed (the first 64 KB), and, for a Cast pick, the newest episode’s title, date, length and audio address from the same read; pressing a pick’s play button is the first request from your browser. It receives a request from this server for the feed, and nothing about you.
The Cover Art Archive, for an album’s cover on a saved list, copied once. It receives the album’s MusicBrainz id. The server’s request, not your browser’s.
Ticketmaster, if you give a city for shows near you. It receives the name of each artist you follow, once, and then each day a point rounded to about a kilometre, the distance you chose and which of those artists to look for. The server’s request, not your browser’s; following a show’s link to Ticketmaster is your browser’s visit.
Spotify, if you connect it, through the Spotify app you registered yourself: each week’s picks, as a playlist in your account. Connecting takes your browser to Spotify to approve it; after that the server talks to Spotify.
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.
An AI assistant’s company, only if you connect one. What the assistant reads from your library goes to its company under its own terms, through the assistant’s own app rather than through your browser. Its searches by meaning also pass through this server to Anthropic, as yours do: the search words and, for your own matching items, a title, tag names and an opening excerpt. Which company is your choice, so none is named here.

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

A saved Overcast or Apple Podcasts episode gets a play button. Denison 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. Your Discover lists, your feed search and your Feeds page carry the same button when a feed you read publishes an episode or a video file, and a YouTube story there gets the video player above; on Discover too, pressing play is the first request to the show’s host or to Google. Saving such an episode keeps its play button for you; on your public pages the link appears without it. Where you stopped listening is remembered in your own browser, never on this server.

Sharing is the sixteenth, 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 in the Share block 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. Each time one of the seven takes a post, this server notes which service it was, when, and the address it gave back, so the item’s page can show where it has gone. That note is yours alone, is never published, and goes when you delete the item for good or delete your account. Nothing is noted for the four your browser goes to, because only the service knows whether you posted.

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 the site answers, its copy replaces the one your browser sent with the save. When the site turns the server away, or answers with a check for robots, the server reads your browser’s copy instead. And on a saved link the site refused, you can paste the article’s text or upload a page you saved from your browser; the server then reads that and does not fetch the page again.

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 3 November 2026.