Last updated: 2026-08-24 · Applies to version 1.0.0
Private RSS Reader does not collect or transmit user data to the developer or to any third-party analytics service.
Feed subscriptions, articles, read/unread state, article update history, article differences and settings are stored locally on the user's device.
Network requests are made only to feed URLs explicitly configured by the user, to a page the user asks to search for feeds, and when the user explicitly opens an original article or shares one.
Everything stays inside the Chrome profile on the device where the extension is installed:
| Data | Storage | Contents |
|---|---|---|
| Subscriptions | IndexedDB (private-rss-reader-db) |
Feed URL, title, site URL, HTTP ETag / Last-Modified, last fetch time, error state, your manual ordering |
| Articles | IndexedDB | Title, link, author, dates, summary, body, read state, update state, star, tags you wrote, content hash |
| Previous article versions | IndexedDB | The single immediately preceding title / summary / body of an article that changed |
| Preferences | chrome.storage.local |
Update interval, theme, language, badge mode, retention limit, selected feed, tag and filter |
| Reader tab id | chrome.storage.session |
A single tab id, cleared when the browser closes |
Nothing is written to chrome.storage.sync, so no part of this data is uploaded
to a Google account or synchronised between devices.
The extension makes exactly three kinds of request, and a fourth thing happens only when you ask for it by hand (sharing, below):
Feed downloads. A GET to a feed URL you added yourself, sent with
credentials: "omit" (no cookies) and referrerPolicy: "no-referrer"
(no referrer header). It is sent when you add the feed, when you press
refresh, and on the schedule you configure.
The one exception to "no cookies" is a feed that is not public at all - an
intranet SharePoint list, a private repository - which answers an anonymous
request with a redirect to a sign-in page instead of the feed. That single
answer, and nothing else, makes the extension repeat the request once with
credentials: "include", so Chrome attaches the cookies it already has for
that one site, and remember that this feed needs it. The anonymous attempt
always comes first, the repeat only ever goes to the site the feed is hosted
on - the one you subscribed to and granted access for - and any other failure
(404, timeout, unreachable host) never triggers it. Nothing is uploaded, no
cookie is read by the extension or copied anywhere, and every other feed
stays anonymous.
You are in control of this on both levels: Settings → Privacy switches the automatic repeat off entirely, and Settings → Show/Edit feed URLs shows which feeds are being downloaded as the signed-in you and turns any of them back to anonymous - a feed you switch off there is never promoted again.
One page, when you ask what feeds it has. Pasting a site address into "Add feed", or pressing "Find feeds on this page", downloads that one page - on your click, with the same no-cookie, no-referrer settings as a feed, and only after Chrome has granted access to that site. It is read for the feeds the page declares in its own HTML; those are shown to you and never followed, so a feed is downloaded only if you then press Add. No address a site did not advertise is ever requested: nothing is guessed at.
Pages you open. When you activate "Open original article", Chrome opens that link in a new tab. That is a normal browser navigation performed by you.
Sharing is the one feature that can move article data off this device, so it is described in full.
The share dialog composes a message - subject, article title, link, an optional excerpt and the feed name - and shows it to you in editable fields before anything happens. Pressing the button does not send it. It builds a URL and asks the browser to open it:
mailto: link. Chrome passes it to whatever mail
client is registered on your system, which opens with the message pre-filled.
Nothing is sent until you press send there. The "To" field is optional and is
only used to fill in the To line of that draft; a fragment is enough, because
the completion happens in your mail client's own address book. What you type
is not stored - the field is empty again the next time you share - and no
address is ever sent anywhere by the extension.https://teams.microsoft.com/share) and opens it in a new tab. The article
link and the message text are part of that address, so Microsoft receives them
the moment the tab opens; you then choose the chat or channel and press send
yourself. This is a normal browser navigation to a Microsoft page and is
governed by Microsoft's privacy terms, not by this policy.The extension makes no request of its own in either case, shares nothing in the background, and sends nothing automatically. "Copy message" puts the same text on the clipboard and involves no network at all.
Sharing is on by default and can be switched off completely in Settings → Privacy, which removes the button and its keyboard shortcut.
There is no other outbound traffic. In particular there is no:
Message catalogues for the interface are read with fetch() from inside the
installed extension package (chrome-extension://<id>/locales/<code>.json).
That is a local file read, not a network request.
Article bodies are sanitised before they are displayed. Elements that could load
a remote resource - img, iframe, video, audio, source, object,
embed, svg, script, style, link - are removed entirely. Version 1.0
therefore never loads a remote image or tracking pixel, and a publisher cannot
learn that you opened an article by embedding one.
Links inside articles are restricted to http: and https: and carry
rel="noopener noreferrer nofollow". They are only followed when you click them.
| Permission | Why it is needed |
|---|---|
storage |
Save preferences in chrome.storage.local and the reader tab id in chrome.storage.session |
alarms |
Schedule periodic feed refreshes without keeping a timer alive |
activeTab |
Read the address of the page in front when you press "Find feeds on this page" in the toolbar popup. Chrome grants this only at the moment you invoke the extension, only for that one tab, and it lapses when you move on. Only the address is read - not the page - and it is used to open the "add a feed" dialog on it. Nothing is fetched until you then ask for it, and no browsing history is recorded |
optional_host_permissions (https://*/*, http://*/*) |
Not granted at install time. Access to one specific origin is requested when you add a feed from that origin, and released again when the last feed using it is deleted |
optional_permissions (notifications) |
Not granted at install time. Requested when you switch desktop notifications on in the settings screen, and handed back when you switch them off. Notification texts are built on your device from your own feeds; nothing is sent to, or received from, any server |
No <all_urls> host permission is requested, no content scripts are injected
into web pages, and the extension has no ability to read the pages you browse.
activeTab is deliberately not the tabs permission: it gives the address of
one tab at the moment you ask something of the extension, rather than every
tab's address for as long as it is installed.
When you do ask for the feeds on a page, one request is made: to that page, on your click, after Chrome has granted access to that site. The declarations found in it are shown to you and never followed - a feed is only downloaded if you press Add.
chrome.storage.local data along with it.This extension has no server component, so there is no data to request or delete from the developer. Issues can be raised in the project repository.