RSS Is Not a Privacy Technology (But It Is Better)

Somewhere inside almost every “ditch the algorithm, subscribe to feeds instead” post sits a claim that goes further than the evidence supports: that switching to RSS makes you private. Is RSS private? Not by default, and treating it as though it were is the fastest way to trade one kind of surveillance blind spot for another.

Here is what a feed reader genuinely removes: the ranking system built to hold your attention, learn from your behavior, and sell what it learns. That’s real, and it matters. Here is what it does not remove: you. Every time a feed reader checks a subscription, it sends an ordinary web request carrying your IP address and software fingerprint to a stranger’s server, on a schedule that describes your habits all by itself. And if that reader lives on someone else’s infrastructure — which most popular ones do — that company now holds a list of everything you follow. That list is arguably a sharper picture of you than most advertising networks assemble from raw browsing behavior, because you built it yourself, on purpose, one subscription at a time.

None of that makes RSS a bad choice. It makes RSS a different kind of good choice than the marketing implies — and the difference is worth getting precisely right rather than taking on faith.

🎯 The Claim That Actually Holds Up

The version of this argument that survives scrutiny isn’t “feeds have no algorithm.” Most serious feed readers do let you rank things — Inoreader has rule-based filtering, NewsBlur has a “training” system that scores stories by your past reactions, and nearly every reader supports folders and priority tiers. Pretending none of that is ranking would be false.

What’s actually different is who holds the rule. In a feed reader, the sorting logic — if you use any at all — is something you set up, can see, can turn off, and can take with you. In an algorithmic timeline, the ranking is opaque, tuned by the platform for its own goals, and inseparable from the service. The honest version of the privacy argument follows the same shape: it isn’t that a feed exposes nothing, it’s that what it exposes is narrower, and what does the ranking — if anything does — is accountable to you instead of to an advertiser. Overstate either one and you’ve stopped describing RSS and started selling it.

📡 What a Single Feed Fetch Actually Hands Over

Strip away the format entirely and a feed subscription is just a computer periodically asking another computer for a file. That request is a standard HTTP GET, and it carries what every HTTP GET carries: your source IP address, a User-Agent string (most feed readers identify themselves by name and version, and some report subscriber counts in it), and a timestamp. The RSS specification itself has nothing to say about any of this — the RSS 2.0 spec, maintained by Harvard Law School’s Berkman Center since July 2003, contains no section on privacy, security, authentication, or encryption at all. Privacy was simply never in scope.

The polling itself is a signal in its own right. The RSS Advisory Board’s Best Practices Profile (version 1.0, published October 2007) records that “by convention, most aggregators check an RSS feed for updates once an hour” — a default so widely followed that a publisher’s access logs end up holding a near-hourly heartbeat for every subscriber: when it starts, when it goes quiet for two weeks, when the source IP changes. The same document found that only about a fifth of surveyed feeds even bothered setting a custom polling interval, so the hourly default is less a rule you opted into than a pattern imposed on you by whichever software you picked. None of this requires cookies, an account, or a beacon. It’s just what a scheduled HTTP request looks like from the other end.

🗂️ The Part the Pitch Leaves Out: Your Reader Knows Everything You Read

This is the piece that gets skipped in almost every “RSS is private” argument, and it’s the biggest one. If you use a hosted reader — a service that polls feeds on your behalf and syncs read state across your devices — that service must, by construction, hold your full subscription list. It isn’t a leak or a bug; it’s the product. The reader can’t do its job without knowing what you follow.

NewsBlur’s privacy policy says this plainly: it stores “information about the stories you’ve read to sync this information between the website and your devices,” alongside your email, hashed password, notification tokens, IP address, and device information, while stating that data isn’t sold to third parties (the policy’s only date is a first-published stamp of November 28, 2017). Inoreader’s policy separately names “Technical Data” — IP address, login data, browser details, page views and navigation paths — sourced from what it calls its “analytics tracking system,” though it doesn’t call out the subscription list or reading history as its own named category. That gap in language doesn’t mean the list isn’t held; a service that syncs unread counts across devices has to keep it somewhere.

Sit with what that list actually contains. A social platform infers your interests by watching what you click. A feed reader is handed them, pre-labeled, because you typed them in yourself: health conditions, a job search, a religious practice, a competitor’s blog, a political cause. Concentrated in one account, at one company, behind one password. That is a genuinely more intimate document than most engagement-driven platforms ever manage to reconstruct from behavior alone — the trade is that nobody is using it to rank what you see next.

🖼️ Tracking Doesn’t Need Your Permission — It Just Needs an <img> Tag

Feeds carry HTML, and HTML can carry a tracking pixel. The Atom specification (RFC 4287, finalized December 2005) actually anticipated this: its security section flags a list of “unsafe” elements that shouldn’t be trusted in feed content, and IMG is on that list, right alongside SCRIPT and IFRAME. Two decades later, most readers still load remote images automatically by default — which means the moment you open an item containing a 1-pixel tracking image, your reader fetches it, and whoever hosts that image now has your IP address and the exact moment you opened that specific item. This is not a hypothetical: a 2018 Princeton study of email tracking (Englehardt, Han and Narayanan, published in Proceedings on Privacy Enhancing Technologies) crawled roughly 15,700 sites and found that about 30% of the emails they collected leaked the recipient’s address to a third party the instant the message was opened, mostly by design. Route a newsletter into a feed through a bridge service and that same pixel travels along with it.

Podcasts push this further, openly and by design. The industry’s own measurement guidelines (IAB Tech Lab, version 2.2, May 2024) state outright that podcast measurement “is based on server logs” — every download, and every partial download from scrubbing ahead, is a request the host can see. Some shows also use “prefix” services, which insert a redirect in front of the actual audio file specifically to count listens. And subscription feeds that gate paid or private content routinely issue a unique URL per subscriber, because that’s how the paywall knows who you are — which means every fetch of that URL identifies you personally, with no cookie required.

🔧 What Actually Changes the Picture

A few concrete choices move the needle more than the format itself ever will:

• Move the fetch off someone else’s server. A local app (something like NetNewsWire) or a self-hosted reader you run yourself means only you see the subscription list, because there’s no vendor in the loop to hold it. The trade-off: your IP now reaches every publisher directly, whereas a hosted reader’s traffic hides inside a much larger pool of other users’ requests. There’s no version of this that wins on every axis — you’re choosing which observer you’d rather deal with, the vendor or the publisher.
• Turn off automatic remote images, or pick a reader that proxies or strips them. Open-source, self-hostable readers like Miniflux document doing exactly this: their features page states it “removes pixel trackers,” strips tracking parameters such as utm_source and fbclid from links, sends a Referrer-Policy: no-referrer header, and blocks external JavaScript in rendered content. That’s the deployment-level fix for the pixel problem described above — the format can’t fix it, but the software can.
• Treat your OPML export as sensitive. OPML is just the file format a feed reader uses to hold your whole subscription list, and exporting it produces exactly the document a hosted reader is sitting on internally. Open it once and read it as a stranger would.
• Remember that “no account” is not “no identification.” It’s a genuine and underrated privacy property — no password to leak, no persistent login tying sessions together — but an IP address, a distinctive User-Agent, and an hourly polling schedule are still a workable fingerprint on their own, account or not.

⚖️ So, Is RSS Private? The Honest Verdict

RSS is better than an algorithmic timeline, and the reason is specific: there’s no cross-site identity graph stitching your activity together, no engagement-optimization system tuning what you see to keep you scrolling, and no inferred behavioral profile packaged up and sold to the highest bidder. Those absences are real, structural, and worth having. But “better” and “private” are different claims, and this hub’s format doesn’t earn the second one just because it lacks the first three. The transport is still an ordinary HTTP request with your IP and timing attached. A hosted reader still needs your subscription list to function. A feed can still carry a tracking pixel.

The single sentence worth keeping is this: removing the algorithm is not the same as removing the observer. A system can be free of behavioral manipulation while still being highly legible to whoever operates it — and understanding exactly where that line sits is a more useful skill than believing either extreme.

If you want the mechanics of what a feed actually is before deciding whether any of this changes your mind, LIG covers that ground separately. And if your interest runs the other direction — using feeds offensively, as a way to watch for new vulnerabilities in the software you run — that’s a genuinely different, more constructive use case that deserves its own treatment rather than a paragraph tacked onto this one.

❓ Frequently Asked Questions

Is RSS more private than social media? In the ways that matter most, yes: no algorithmic ranking system profiles you, no engagement-optimization layer is tuned against your attention, and there’s no social graph exposing who you follow to other users. But a feed fetch still reveals your IP address and reading schedule to the publisher, and a hosted reader still holds your full subscription list. “Better” is the accurate word; “private” overstates it.

Does a feed reader require an account? Not always. Local apps that run on your own device don’t need one at all — you fetch feeds directly, no login required. Hosted readers that sync across your phone and laptop generally do need an account, because syncing read state and subscriptions between devices requires somewhere to store them.

Can a publisher tell it’s specifically me reading their feed? If you subscribe through a hosted reader, no — your request arrives from the vendor’s servers, pooled with every other user’s traffic, and the publisher only knows “someone using this reader” checked in. If you run a local or self-hosted reader, yes: the request comes straight from your IP address, on your own schedule, identifiably yours.

Do RSS feeds have tracking pixels? They can. Feeds are allowed to carry HTML, and a remote image loaded when you open an item works exactly like an email tracking pixel — it tells whoever hosts it that you opened that specific item, at that moment, from that IP. Turning off automatic image loading, or using a reader that proxies images, blocks this.

What’s the single best privacy improvement for someone who already uses a feed reader? Turn off automatic remote-image loading, or switch to a reader that strips it for you by default. It closes the one channel inside feed content that behaves like real tracking — everything else covered here is a property of the transport, and no reader setting changes that.

---

📦 Recommended Resources

The free primary sources do the heavy lifting here — the RSS 2.0 specification and RFC 4287 (Atom) are short, readable, and cost nothing, and they’re exactly what this article draws on for what a feed fetch technically is and isn’t. These three books are supplements for going deeper on the surrounding argument, not replacements for reading the specs.

1. The Age of Surveillance Capitalism by Shoshana Zuboff — the fullest account of the “observer” half of this article’s closing line: what it means for a system to hold a detailed profile of you even when it isn’t manipulating your attention. LIG has a full summary of the book’s argument if you want the longer version first.

1. RSS and Atom in Action — the strongest surviving book on how feeds actually work at the protocol level, written while RSS and Atom were both still under active development. Useful if you want the mechanics behind “a feed fetch is just an HTTP GET” in more detail than a single article can carry; note that no meaningfully newer RSS-specific book exists, which is itself part of the story of the format settling into infrastructure.

1. Algorithms of Oppression by Safiya Umoja Noble — a sharper look at the flip side of this article’s ranking argument: what it costs when a ranking system is opaque and unaccountable. Useful context for why “you can inspect, edit, and export the rule” is doing real work as a privacy and power distinction, not just a technical footnote.

---

✅ Pro tip: None of these books will tell you whether your specific feed reader stores your subscription list — that’s in the vendor’s own privacy policy, and it’s worth the five minutes to go read it.