Datenschutz und Sicherheit in RSS Reader: Wie Feeds geladen werden und was gesendet wird

Einführung

Ein Webpart, das Inhalte von außerhalb des Unternehmens ins Intranet bringt, wirft für einen Administrator zwei Fragen auf: Was verlässt den Mandanten, und was kommt herein? RSS Reader ist unter den Vitextra-Produkten insofern ungewöhnlich, als seine Inhalte tatsächlich über einen Vitextra-Server laufen – den Feeddienst, der die Feeds herunterlädt. Dieser Artikel beschreibt genau, was diese Anfrage enthält, was das Webpart in Ihrem Mandanten tun darf, wo seine Konfiguration liegt, was es im Browser aufbewahrt und wie es mit dem HTML umgeht, das Herausgeber in ihre Feeds einfügen.

Zusammenfassung für Administratoren

Berechtigungen der Lösung

RSS Reader ist ein SharePoint Framework-Webpart, das aus dem App-Katalog bereitgestellt wird.

• Das Paket fordert keine API-Berechtigungen an. Auf der Seite API-Zugriff des SharePoint Admin Centers erscheint nichts, und das Webpart ruft für Daten weder Microsoft Graph noch die SharePoint-REST-API auf.
• Aus dem Seitenkontext liest es nur, was jedes Webpart hat: das Design, die Sprache, die Websiteadresse (für die Lizenzprüfung und die Feedanfrage) und die Identität des angemeldeten Benutzers (die Objekt-ID, für dieselben Anfragen).
• Es schreibt nichts in SharePoint, OneDrive oder Microsoft Entra ID.

Was Benutzer benötigen

Wie Feeds geladen werden und was gesendet wird

Browser erlauben es einem Skript auf einer Website nicht, ein Dokument von einer anderen Website herunterzuladen, sofern diese Website es nicht mit Cross-Origin-Headern gestattet; Feedherausgeber tun das fast nie. Ein reines Browser-RSS-Webpart würde daher bei den meisten Feeds scheitern. RSS Reader löst dies mit einem serverseitigen Feeddienst unter vitextra.com: Der Browser sendet ihm die Liste der Feedadressen, der Dienst lädt die Feeds aus dem Internet herunter, analysiert sie und gibt die Kanäle und Elemente als strukturierte Daten zurück.

Jedes Laden und jede automatische Aktualisierung ist eine Anfrage an den Feeddienst mit folgendem Inhalt:

Die Antwort enthält die Feedelemente – Titel, Links, Beschreibungen, Datumsangaben, Autoren, Kategorien und Bildadressen – und die Liste der Quellen, die nicht heruntergeladen werden konnten. Der Dienst empfängt keine Inhalte Ihres Mandanten und gibt keine zurück; der Benutzer wird über eine GUID identifiziert, nicht über Namen oder E-Mail-Adresse.

Drei Konsequenzen:

• die Feedadressen, die Sie konfigurieren, sind dem Feeddienst bekannt. Verwenden Sie keine Feeds, deren Adresse selbst ein Geheimnis enthält (ein persönliches Token oder einen API-Schlüssel in der Abfragezeichenfolge): Solche Feeds sind nicht dafür gedacht, mit einem Aggregator geteilt zu werden, und werden ohnehin nicht unterstützt, weil der Dienst Feeds anonym herunterlädt;
• Feeds, die nur innerhalb Ihres Netzwerks erreichbar sind, können nicht angezeigt werden;
• der Browser stellt für den Feed nie eine Verbindung zu den Servern der Herausgeber her. Er verbindet sich mit ihnen für die Bilder der Elemente, die der Browser wie jedes Bild auf einer Webseite direkt lädt – der Herausgeber sieht die gewöhnliche Bildanfrage des Browsers des Benutzers.

Wo die Konfiguration gespeichert wird

Auf einer SharePoint-Seite wird die Konfiguration – die Feeds mit ihren Adressen, Namen und ihrer Reihenfolge, das Layout und die Schalter – in den Eigenschaften des Webparts innerhalb der Seite in der Bibliothek Websiteseiten gespeichert. Jeder, der die Seite lesen kann, kann die Konfiguration lesen (die Feedadressen sind in den Quellenregisterkarten ohnehin sichtbar); Seitenversionen bewahren frühere Konfigurationen auf.

Für die persönliche Teams-App speichert ein Administrator die Konfiguration mit Einstellungen speichern in der Gruppe Persönliche App (Microsoft Teams). Diese Konfiguration – dieselben Felder, ohne den Webparttitel – wird vom Vitextra-Dienst für Ihren Mandanten und Ihr Produkt gespeichert, weil die persönliche App keine Seite hat, in der sie gespeichert werden könnte. Sie wird von der persönlichen App jedes Benutzers im Mandanten gelesen und vom nächsten Einstellungen speichern überschrieben. Sie enthält nur Einstellungen und Feedadressen, keine Benutzerdaten.

In einer Teams-Kanalregisterkarte wird die Konfiguration mit der Registerkarte gespeichert, wie auf einer Seite.

Was im Browser aufbewahrt wird

Nach einem erfolgreichen Laden schreibt das Webpart die empfangenen Elemente in den Sitzungsspeicher des Browsers, mit dem Satz der Feedadressen als Schlüssel, und verwendet sie bis zu 30 Minuten lang, um beim nächsten Besuch sofort Inhalte zu zeigen, während aktuelle Elemente im Hintergrund geladen werden. Der Cache enthält die Feedelemente, wie sie vom Feeddienst zurückgegeben wurden, und nichts über den Benutzer; er gehört zur Browserregisterkartensitzung und wird entfernt, wenn die Registerkarte geschlossen wird. Das Webpart verwendet weder den lokalen Speicher noch Cookies oder einen anderen dauerhaften Speicher.

Welche Artikel ein Benutzer geöffnet hat, wird nirgends aufgezeichnet. Das Abblenden bereits geöffneter Titel beruht auf dem browsereigenen Verlauf besuchter Links, den kein Skript lesen kann.

Wie Feedinhalte dargestellt werden

Feedelemente enthalten vom Herausgeber geschriebenes HTML – Beschreibungen mit Markup, eingebettete Bilder, manchmal Skripts oder Tracking-Pixel. RSS Reader fügt dieses HTML nie in die Seite ein:

• die Beschreibung wird mit einem inerten Parser (DOMParser) analysiert, der weder Skripts ausführt noch eingebettete Ressourcen lädt, und nur ihr Nur-Text wird angezeigt;
• das Bild eines Elements wird aus den Medienelementen des Feeds oder aus dem ersten Bild der Beschreibung übernommen, und Bilder von einem Pixel – die typischen Tracking-Pixel – werden übersprungen; das Bild wird dann als gewöhnliches <img>-Element mit der Adresse des Herausgebers angezeigt;
• Links öffnen den Originalartikel in einer neuen Registerkarte auf der Website des Herausgebers; das Webpart fügt keine Tracking-Parameter hinzu.

Ein fehlerhaftes Element – fehlende Elemente, defektes Markup – wird mit den vorhandenen Daten angezeigt und verhindert nicht die Darstellung der anderen Elemente.

Anfragen an Vitextra-Dienste

Dieselben Informationen für alle Vitextra-Produkte finden Sie in KB10363. Wo Vitextra-Produkte Ihre Daten speichern: Datenschutz, Datenresidenz und DSGVO.

Netzwerkanforderungen

Lassen Sie ausgehendes HTTPS aus dem Netzwerk der Benutzer (und vom Teams-Client) zu vitextra.com, static.vitextra.com und vitextra-storage.azureedge.net zu. Ohne den ersten Host zeigt das Webpart Leider ist ein Fehler aufgetreten… anstelle der Elemente; ohne die beiden anderen wird es gar nicht geladen. Die Bilder der Elemente werden von den Hosts der Herausgeber geladen; blockiert Ihr Proxy einen Herausgeber, erscheinen dessen Elemente ohne Bilder.

Empfehlungen

1. Verwenden Sie Feeds von Herausgebern, denen Ihre Organisation vertraut, wie bei allen externen Inhalten im Intranet: Titel, Texte und Bilder gehören ihnen und ändern sich ohne Ihre Prüfung.
2. Bevorzugen Sie HTTPS-Feedadressen mit HTTPS-Bildern; über HTTP ausgelieferte Bilder werden vom Browser auf HTTPS-Seiten blockiert.
3. Konfigurieren Sie keine Feeds, deren Adresse ein persönliches Token enthält; sie werden mit allen geteilt, die die Seite lesen können, und mit dem Feeddienst.
4. Löschen Sie auf gemeinsam genutzten Computern beim Abmelden die Websitedaten des Browsers wie bei jeder Intranetseite; der Feedcache verschwindet ohnehin mit der Registerkarte.