Privacy and Security in RSS Reader: How Feeds Are Loaded and What Is Sent

Introduction

A web part that brings content from outside the company onto the intranet raises two questions for an administrator: what leaves the tenant, and what comes in. RSS Reader is unusual among Vitextra products in that its content does pass through a Vitextra server — the feed service that downloads the feeds. This article states precisely what that request contains, what the web part is permitted to do in your tenant, where its configuration lives, what it keeps in the browser and how it treats the HTML that publishers put into their feeds.

Summary for administrators

Permissions of the solution

RSS Reader is a SharePoint Framework web part deployed from the app catalog.

• The package requests no API permissions. Nothing appears on the API access page of the SharePoint admin center, and the web part calls neither Microsoft Graph nor the SharePoint REST API for data.
• From the page context it reads only what every web part has: the theme, the language, the site address (for the license check and the feed request) and the identity of the signed-in user (the object ID, for the same requests).
• It writes nothing to SharePoint, OneDrive or Microsoft Entra ID.

What users need

How feeds are loaded and what is sent

Browsers do not allow a script on one website to download a document from another website unless that website permits it with cross-origin headers; feed publishers almost never do. A browser-only RSS web part would therefore fail for most feeds. RSS Reader solves this with a server-side feed service at vitextra.com: the browser sends it the list of feed addresses, the service downloads the feeds from the internet, parses them and returns the channels and items as structured data.

Every load and every automatic refresh is one request to the feed service with the following content:

The response contains the feed items — titles, links, descriptions, dates, authors, categories and image addresses — and the list of sources that could not be downloaded. The service does not receive and does not return any content of your tenant; the user is identified by a GUID, not by name or e-mail address.

Three consequences:

• the feed addresses you configure are known to the feed service. Do not use feeds whose address itself contains a secret (a personal token or API key in the query string): such feeds are not meant to be shared with any aggregator, and they are not supported anyway, because the service downloads feeds anonymously;
• feeds that are reachable only inside your network cannot be shown;
• the browser never connects to the publishers' servers for the feed. It does connect to them for the images of the items, which are loaded directly by the browser like any picture on a web page — the publisher sees the ordinary image request of the user's browser.

Where the configuration is stored

On a SharePoint page, the configuration — the feeds with their addresses, names and order, the layout and the switches — is stored in the properties of the web part, inside the page in the Site Pages library. Everyone who can read the page can read the configuration (the feed addresses are visible in the source tabs anyway); page versions keep earlier configurations.

For the Teams personal app, an administrator saves the configuration with Save Settings in the Personal app (Microsoft Teams) group. This configuration — the same fields, without the web part title — is stored by the Vitextra service for your tenant and product, because the personal app has no page to store it in. It is read by the personal app of every user in the tenant and overwritten by the next Save Settings. It contains settings and feed addresses only, no user data.

In a Teams channel tab, the configuration is stored with the tab, like on a page.

What is kept in the browser

After a successful load the web part writes the received items to the session storage of the browser, keyed by the set of feed addresses, and uses them for up to 30 minutes to show content instantly on the next visit while fresh items load in the background. The cache contains the feed items as returned by the feed service and nothing about the user; it belongs to the browser tab session and is removed when the tab is closed. The web part does not use local storage, cookies or any other persistent storage.

Which articles a user has opened is not recorded anywhere. The dimming of already-opened titles relies on the browser's own memory of visited links, which no script can read.

How feed content is rendered

Feed items contain HTML written by the publisher — descriptions with markup, embedded images, sometimes scripts or tracking pixels. RSS Reader never inserts this HTML into the page:

• the description is parsed with an inert parser (DOMParser), which neither executes scripts nor loads embedded resources, and only its plain text is displayed;
• the image of an item is taken from the feed's media elements or from the first image of the description, and one-pixel images — the typical tracking pixels — are skipped; the image is then shown as an ordinary <img> element with the publisher's address;
• links open the original article in a new tab on the publisher's site; the web part adds no tracking parameters.

A malformed item — missing elements, broken markup — is shown with the data it has and does not prevent the other items from rendering.

Requests to Vitextra services

For the same information across all Vitextra products, see KB10363. Where Vitextra Products Store Your Data: Privacy, Data Residency and GDPR.

Network requirements

Allow outbound HTTPS from the users' network (and from the Teams client) to vitextra.com, static.vitextra.com and vitextra-storage.azureedge.net. Without the first host the web part shows Sorry, something went wrong… instead of items; without the other two it does not load at all. The images of the items are loaded from the publishers' hosts; if your proxy blocks a publisher, its items appear without pictures.

Recommendations

1. Use feeds of publishers your organization trusts, as you would for any external content on the intranet: the titles, texts and pictures are theirs and change without your review.
2. Prefer HTTPS feed addresses with HTTPS images; pictures served over HTTP are blocked by the browser on HTTPS pages.
3. Do not configure feeds whose address contains a personal token; they are shared with everyone who can read the page and with the feed service.
4. On shared computers, clear the site data of the browser at sign-out as for any intranet page; the feed cache disappears with the tab anyway.