Spotlight: Jelly Reader. Follow the news without being followed

What you read says a lot about you and how you access the things you read matters just as much. Maybe more than your mail does. Twenty or so blogs, a couple of newspapers, a few YouTube channels and three newsletters are enough to give a decent guess at your job, your politics, your health worries and where you live. The content you consume make it easy to generate a profile that can be used and sold without your knowledge.

Feed readers have always worked one of two ways. Either your device fetches every feed itself, so every site you follow sees your IP address a couple of times a day. Or a server fetches them for you and keeps your list of feeds in a central place, tied to your account and with a risk of it being analyzed, sold or handed over. I didn't want either of these for jellysuite, so Jelly Reader goes a more creative, third way.

This is the first post in a series where I take one app at a time and show what it does and what goes on under the hood. Reader comes first because it has the most surprising story.

What Reader does

• Feeds and YouTube. Paste a site's address or a YouTube channel and Reader finds its feed. Mastodon, Bluesky, Reddit, GitHub, Substack and anything else that publishes a feed work the same way. Coming from another reader? Import your OPML file.
• Reader view. Articles open cleaned up: the text, its pictures and who wrote it, without ads or scripts. When a page won't clean up, it opens on its own site, and you can set a feed to always do that.
• Bookmarks. Save a link from any tab with the Save to jellysuite link in your bookmark bar, add a note, and keep a readable copy if you like. The copy keeps the article's images inside it, so it still works if the site goes away.
• Newsletters. Mark one of your mail aliases as your newsletter alias and sign up with it. Its mail shows up in Reader, next to your feeds, instead of in your inbox.
• Team folders. Share a folder of feeds and bookmarks with your team. Everyone's read state stays their own, and you choose which shared folders to follow.

It's included in every plan, in the web app and the Mac, Linux and iPhone apps.

How we fetch your feeds without knowing it's you

The rule we set for Reader: our server may know that a feed is fetched, but never for whom.

Think of the fetcher service as a mixer. Everyone's requests go in at the top: yours, your colleague's, and those of thousands of people you'll never meet. Out at the bottom come the feeds and articles. What doesn't come out is any note of whose request was whose, because the fetcher never gets one. It sees "someone wants this feed", hands it back, and that's all it ever knows.

For a mixer to work, nothing can stick to your request on the way in. So our fetcher is a small service of its own, kept apart from everything else we run. It can't look at our list of accounts, it gets no cookies and no login, and our web server takes your IP address off every request before passing it on. It also doesn't write anything down about who came by.

Tickets, stamped with your eyes closed

There's one catch. If the fetcher doesn't know who you are, how does it know you're a jellysuite user and not someone using it for free?

The answer is a ticket. While you're signed in, your app picks up a stack of tickets from us, and it hands one in for every feed it fetches. A ticket says "this person has an account", and nothing else. Here's the clever part: your app slips each ticket into a sealed envelope before we stamp it, and we stamp it through the envelope without ever seeing the ticket itself. Your app opens the envelope afterwards, and the stamp is on the ticket.

So we know we stamped a hundred tickets for you this morning, but when a ticket turns up at the fetcher later, we've never seen it before and there's no way to tell it came from you. Every ticket works once, and your app also checks that its tickets were stamped with the same stamp as everyone else's, so we couldn't secretly give you a stamp of your own to recognise you by.

Blending in

A mixer only hides you if you look like everyone else. A few small things make sure you do:

• One feed at a time. Your app asks for each feed separately, with a fresh ticket, in a random order and with short random pauses in between. Your list of feeds is the fingerprint we're trying to hide, so it never travels in one piece.
• A shared cache. When thousands of people follow the same newspaper, the fetcher gets it once and hands the same copy to everyone. Your request for a popular feed is one of many identical ones. (It's also kinder to the publishing sites.)
• Images too. Pictures in feeds and articles come through the fetcher as well, so the sites you read never see your IP address either. YouTube videos only load once you press play. From then on YouTube sees your IP address, as with any video on the web.

Why this matters

Most privacy promises are about protecting a list: we have your data, but we'll keep it safe. With Reader there is no list to protect. Nowhere on our servers is there a record that says "this person reads these feeds". That means there's nothing to leak in a breach, nothing to sell, and nothing to hand over if someone comes asking. We couldn't make a profile of your content habits if we tried and this means you don't have to trust us to keep it safe, because we never had it.

Everything you keep in Reader itself, like your feeds, folders, bookmarks, notes and what you've read, is locked on your device before it reaches us, like everything else in jellysuite. We went quite far there: even the date an article was published is locked away, because a list of dates alone can be enough to work out which blog it came from.

What we can still see

Full transparency, there's a bit of metadata left that we can (have to?!) see. But it's really thin. Here's what's left:

• Which feeds and articles are fetched, and how popular they are. But not by whom.
• How many tickets you pick up per day. Not what you spend them on.
• How much you store, and when. Your saved items are locked, but we can see their size and when they arrive, for all your feeds together.
• Your newsletter alias, because we deliver mail to it.
• Timing, in theory. Someone who secretly changed our servers and watched them live could try to line up the moment a feed is fetched with the moment your app saves something. Your app waits a random while before saving to make that hard, and nothing we record links you to a feed. #tinfoilhats

If you'd like the technical details, the Reader part of our security page has them.

What's next for our Reader

We want to build a browser extension for saving pages to bookmarks more easily. A native share menu on iPhone and Mac, and also a podcast player that keeps playing while you navigate the app. If you're missing something else, or you'd like to argue with any of the above, write to me at ben@jellysuite.com.

Ben