Verwandte Website-Sets: Entwicklerleitfaden

Ähnliche Website-Gruppen (RWS) sind ein Webplattformmechanismus, der Browsern hilft, die Beziehungen zwischen einer Sammlung von Domains zu verstehen. So können Browser wichtige Entscheidungen zur Aktivierung bestimmter Websitefunktionen treffen (z. B. ob der Zugriff auf websiteübergreifende Cookies zugelassen wird) und diese Informationen den Nutzern anzeigen.

Durch die Einstellung von Drittanbieter-Cookies in Chrome sollen wichtige Anwendungsfälle im Web beibehalten und gleichzeitig der Datenschutz für Nutzer verbessert werden. Beispielsweise sind viele Websites auf mehrere Domains angewiesen, um eine einzelne Nutzererfahrung zu bieten. Unternehmen möchten verschiedene Top-Level-Domains für verschiedene Anwendungsfälle verwenden, z. B. für länderspezifische Domains oder Dienstdomains zum Hosten von Bildern oder Videos. Mit Gruppen ähnlicher Websites können Websites Daten domainübergreifend mit bestimmten Einstellungen teilen.

Grundsätzlich ist eine Gruppe ähnlicher Websites eine Sammlung von Domains, für die es eine einzelne festgelegte „primäre“ Gruppe gibt. und möglicherweise auch mehrere „Set-Mitglieder“.

Im folgenden Beispiel listet primary die primäre Domain auf und associatedSites die Domains, die die Anforderungen der zugehörigen Teilmenge erfüllen.

{
  "primary": "https://primary.com",
  "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}

Die kanonische Liste mit Gruppen ähnlicher Websites ist eine öffentlich sichtbare Liste im JSON-Dateiformat, die im GitHub-Repository für Gruppen ähnlicher Websites gehostet wird. Es dient als zentrale Quelle für alle Sets. Chrome verwendet diese Datei, um auf ihr Verhalten anzuwenden.

Nur Nutzer mit administrativer Kontrolle über eine Domain können einen Satz mit dieser Domain erstellen. Einsender müssen die Beziehung zwischen den einzelnen „Set-Mitgliedern“ angeben. auf „Primär festlegen“. Satzmitglieder können verschiedene Domaintypen umfassen und müssen je nach Anwendungsfall Teil einer Untergruppe sein.

Wenn für Ihre Anwendung der Zugriff auf websiteübergreifende Cookies (auch als Drittanbieter-Cookies bezeichnet) in derselben Gruppe ähnlicher Websites erforderlich ist, können Sie die Storage Access API (SAA) und die requestStorageAccessFor API verwenden, um Zugriff auf diese Cookies anzufordern. Je nach Teilmenge, zu der die jeweilige Website gehört, kann der Browser die Anfrage unterschiedlich verarbeiten.

Weitere Informationen zum Ablauf und zu den Anforderungen beim Einreichen von Sets finden Sie in den Richtlinien zur Einreichung. Die eingereichten Sätze werden verschiedenen technischen Prüfungen unterzogen, um sie zu validieren.

Gruppen ähnlicher Websites eignen sich gut für Fälle, in denen eine Organisation eine Form der gemeinsamen Identität auf verschiedenen Websites der obersten Ebene benötigt.

Beispiele für Anwendungsfälle für Gruppen ähnlicher Websites:

  • Länderanpassung: Lokalisierte Websites in Verbindung mit einer gemeinsamen Infrastruktur nutzen (example.co.uk kann auf einen von example.ca gehosteten Dienst zurückgreifen).
  • Integration von Dienstdomains Die Nutzung von Dienstdomains, mit denen Nutzer nie direkt interagieren, jedoch Dienste auf den Websites derselben Organisation anbieten (beispiel-cdn.com).
  • Trennung von Nutzerinhalten: Zugriff auf Daten in verschiedenen Domains, die von Nutzern hochgeladene Inhalte aus Sicherheitsgründen von anderen Websiteinhalten trennen, während der Sandbox-Domain Zugriff auf Authentifizierungs- und andere Cookies gewährt wird. Wenn Sie inaktive, von Nutzern hochgeladene Inhalte bereitstellen, können Sie diese möglicherweise auch sicher auf derselben Domain hosten. Beachten Sie dazu die Best Practices.
  • Eingebettete authentifizierte Inhalte: Unterstützung eingebetteter Inhalte aus verknüpften Properties (Videos, Dokumente oder Ressourcen, die auf den auf der Top-Level-Website angemeldeten Nutzer beschränkt sind)
  • Anmelden: Anmeldung über verknüpfte Properties hinweg Die FedCM API kann für einige Anwendungsfälle geeignet sein.
  • Analytics: Analyse und Messung von Nutzerpfaden über verknüpfte Properties hinweg, um die Qualität der Dienstleistungen zu verbessern

Storage Access API

Unterstützte Browser

  • 119
  • 85
  • 65
  • 11.1

Quelle

Mit der Storage Access API (SAA) können eingebettete ursprungsübergreifende Inhalte auf den Speicher zugreifen, auf den sie normalerweise nur in einem selbst erhobenen Kontext zugreifen würden.

Eingebettete Ressourcen können mit SAA-Methoden prüfen, ob sie derzeit Zugriff auf den Speicher haben, und Zugriff vom User-Agent anfordern.

Wenn Drittanbieter-Cookies blockiert sind, Gruppen ähnlicher Websites (RWS) aber aktiviert sind, gewährt Chrome in solchen Kontexten automatisch die Berechtigung. Andernfalls wird dem Nutzer eine entsprechende Aufforderung angezeigt. Ein „Intra-RWS-Kontext“ ist ein Kontext, wie z. B. ein iFrame, dessen eingebettete Website und Website auf oberster Ebene sich in derselben RWS befinden.

Speicherzugriff prüfen und anfordern

Um zu prüfen, ob sie derzeit Zugriff auf den Speicher haben, können eingebettete Websites die Document.hasStorageAccess()-Methode verwenden.

Die Methode gibt ein Versprechen zurück, das mit einem booleschen Wert aufgelöst wird, der angibt, ob das Dokument bereits Zugriff auf seine Cookies hat oder nicht. Das Promise gibt auch „true“ zurück, wenn der iFrame denselben Ursprung hat wie der oberste Frame.

Wenn Sie den Zugriff auf Cookies in einem websiteübergreifenden Kontext anfordern möchten, können eingebettete Websites Document.requestStorageAccess() (rSA) verwenden.

Die requestStorageAccess() API ist für den Aufruf von innerhalb eines iFrames vorgesehen. Dieser iFrame muss gerade eine Nutzerinteraktion empfangen haben (eine Nutzergeste, die bei allen Browsern erforderlich ist). Für Chrome ist außerdem erforderlich, dass der Nutzer irgendwann in den letzten 30 Tagen die Website besucht hat, zu der dieser iFrame gehört, und speziell mit dieser Website interagiert hat – als Dokument der obersten Ebene und nicht in einem iFrame.

requestStorageAccess() gibt ein Promise zurück, das aufgelöst wird, wenn der Zugriff auf den Speicher gewährt wurde. Das Versprechen wird unter Angabe des Grundes abgelehnt, wenn der Zugriff aus irgendeinem Grund verweigert wurde.

requestStorageAccessFor in Chrome

Unterstützte Browser

  • 119
  • 119
  • x
  • x

Quelle

Die Storage Access API erlaubt nur eingebetteten Websites, Zugriff auf den Speicher über <iframe>-Elemente anzufordern, die eine Nutzerinteraktion erhalten haben.

Dies stellt Herausforderungen bei der Implementierung der Storage Access API für Websites auf oberster Ebene dar, die websiteübergreifende Images oder Skript-Tags verwenden, die Cookies erfordern.

Deshalb hat Chrome eine Möglichkeit für Top-Level-Websites implementiert, im Namen bestimmter Ursprünge den Speicherzugriff bei Document.requestStorageAccessFor() (rSAFor) anzufordern.

 document.requestStorageAccessFor('https://target.site')

Die requestStorageAccessFor() API soll von einem Dokument auf oberster Ebene aufgerufen werden. Dieses Dokument muss ebenfalls gerade eine User-Interaktion erhalten haben. Im Gegensatz zu requestStorageAccess() sucht Chrome jedoch nicht nach einer Interaktion in einem Dokument auf oberster Ebene der letzten 30 Tage, da der Nutzer sich bereits auf der Seite befindet.

Speicherzugriffsberechtigungen prüfen

Der Zugriff auf einige Browserfunktionen wie Kamera oder Standortbestimmung basiert auf den von den Nutzern erteilten Berechtigungen. Mit der Permissions API lässt sich der Berechtigungsstatus für den Zugriff auf eine API prüfen. Dabei spielt es keine Rolle, ob der Zugriff gewährt oder verweigert wurde oder ob eine Nutzerinteraktion erforderlich ist, z. B. das Klicken auf eine Aufforderung oder die Interaktion mit der Seite.

Sie können den Berechtigungsstatus mit navigator.permissions.query() abfragen.

Um die Speicherzugriffsberechtigung für den aktuellen Kontext zu prüfen, müssen Sie den String 'storage-access' übergeben:

navigator.permissions.query({name: 'storage-access'})

Um die Speicherzugriffsberechtigung für einen bestimmten Ursprung zu prüfen, müssen Sie den String 'top-level-storage-access' übergeben:

navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'})

Zum Schutz der Integrität des eingebetteten Ursprungs werden dabei nur Berechtigungen geprüft, die vom Dokument der obersten Ebene mit document.requestStorageAccessFor gewährt wurden.

Je nachdem, ob die Berechtigung automatisch gewährt werden kann oder eine Nutzergeste erforderlich ist, wird prompt oder granted zurückgegeben.

Pro Frame-Modell

rSA-Erteilungen gelten pro Frame. rSA- und rSAFor-Erteilungen werden als unterschiedliche Berechtigungen behandelt.

Für jeden neuen Frame muss der Speicherzugriff einzeln angefordert werden und er erhält automatisch Zugriff. Nur die erste Anfrage erfordert eine Nutzergeste. Nachfolgende Anfragen, die vom iFrame initiiert werden, z. B. eine Navigation oder Unterressourcen, müssen nicht auf eine Nutzergeste warten, da diese durch die erste Anfrage für die Browsersitzung gewährt wird.

Für das Aktualisieren, erneute Laden oder anderweitige Neuerstellung des iFrames muss noch einmal der Zugriff angefordert werden.

Cookies müssen sowohl das Attribut SameSite=None als auch das Attribut Secure angeben, da „rSA“ nur Zugriff auf Cookies gewährt, die bereits für die Verwendung in websiteübergreifenden Kontexten gekennzeichnet sind.

Cookies mit SameSite=Lax, SameSite=Strict oder ohne SameSite-Attribut sind nur für die eigene Verwendung bestimmt und werden nie in einem websiteübergreifenden Kontext unabhängig von der rSA weitergegeben.

Sicherheit

Für „rSAFor“-Anfragen für Unterressourcen erfordern CORS-Header (Cross-Origin Resource Sharing) oder das Attribut crossorigin für die Ressourcen. Damit ist eine ausdrückliche Aktivierung erforderlich.

Implementierungsbeispiele

Zugriff auf Speicher von einem eingebetteten ursprungsübergreifenden iFrame anfordern

<ph type="x-smartling-placeholder">
</ph> Diagramm mit einer eingebetteten Website auf einer Top-Level-Website
requestStorageAccess() in einer Einbettung auf einer anderen Website verwenden

Prüfen, ob Sie Speicherzugriff haben

Mit document.hasStorageAccess() kannst du prüfen, ob du bereits Zugriff auf den Speicher hast.

Wenn das Versprechen als „true“ aufgelöst wird, kannst du im websiteübergreifenden Kontext auf den Speicher zugreifen. Wenn das Problem mit „false“ behoben wird, müssen Sie Speicherzugriff anfordern.

document.hasStorageAccess().then((hasAccess) => {
    if (hasAccess) {
      // You can access storage in this context
    } else {
      // You have to request storage access
    }
});

Speicherzugriff anfordern

Wenn du den Speicherzugriff anfordern möchtest, prüfe zuerst die Berechtigung für den Speicherzugriff navigator.permissions.query({name: 'storage-access'}). So kannst du feststellen, ob dafür eine Nutzergeste erforderlich ist oder ob die Berechtigung automatisch gewährt werden kann.

Wenn die Berechtigung granted lautet, können Sie document.requestStorageAccess() aufrufen. Der Vorgang sollte ohne Nutzergeste erfolgreich sein.

Wenn der Berechtigungsstatus prompt lautet, musst du den document.requestStorageAccess()-Aufruf nach einer Nutzergeste wie dem Klicken auf eine Schaltfläche initiieren.

Beispiel:

navigator.permissions.query({name: 'storage-access'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSA();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSA();
    });
    document.body.appendChild(btn);
  }
});

function rSA() {
  if ('requestStorageAccess' in document) {
    document.requestStorageAccess().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

Nachfolgende Anfragen innerhalb des Frames, der Navigation oder der untergeordneten Ressourcen erhalten automatisch die Berechtigung für den Zugriff auf websiteübergreifende Cookies. „hasStorageAccess()“ gibt echte Cookies zurück und websiteübergreifende Cookies derselben Gruppe ähnlicher Websites werden bei diesen Anfragen ohne zusätzliche JavaScript-Aufrufe gesendet.

<ph type="x-smartling-placeholder">
</ph> Diagramm, das zeigt, wie „requestStorageAccessFor()“ auf einer Website auf oberster Ebene und nicht in einer Einbettung verwendet wird
requestStorageAccessFor() auf einer Website der obersten Ebene für einen anderen Ursprung verwenden

Websites auf oberster Ebene können mit requestStorageAccessFor() Speicherzugriff für bestimmte Ursprünge anfordern.

hasStorageAccess() prüft nur, ob die Website, die sie aufruft, Speicherzugriff hat. Eine Website auf oberster Ebene kann also die Berechtigungen für einen anderen Ursprung prüfen.

Rufen Sie navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'}) auf, um herauszufinden, ob der Nutzer dazu aufgefordert wird oder ob dem angegebenen Ursprung bereits Speicherzugriff gewährt wurde.

Wenn die Berechtigung granted lautet, können Sie document.requestStorageAccessFor('https://target.site') aufrufen. Dies sollte ohne eine Nutzergeste funktionieren.

Wenn die Berechtigung prompt lautet, musst du den document.requestStorageAccessFor('https://target.site')-Aufruf hinter der Nutzergeste, z. B. dem Klicken auf eine Schaltfläche, einhängen.

Beispiel:

navigator.permissions.query({name:'top-level-storage-access',requestedOrigin: 'https://target.site'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSAFor();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSAFor();
    });
    document.body.appendChild(btn);
  }
});

function rSAFor() {
  if ('requestStorageAccessFor' in document) {
    document.requestStorageAccessFor().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

Nach einem erfolgreichen requestStorageAccessFor()-Aufruf enthalten websiteübergreifende Anfragen Cookies, wenn sie CORS oder das Crossorigin-Attribut enthalten. Websites sollten also möglicherweise warten, bevor sie eine Anfrage auslösen.

Für die Anfragen muss die Option credentials: 'include' verwendet werden und die Ressourcen müssen das Attribut crossorigin="use-credentials" enthalten.

function checkCookie() {
    fetch('https://related-website-sets.glitch.me/getcookies.json', {
        method: 'GET',
        credentials: 'include'
      })
      .then((response) => response.json())
      .then((json) => {
      // Do something
      });
  }

Lokale Tests durchführen

Vorbereitung

Wenn Sie Gruppen ähnlicher Websites lokal testen möchten, verwenden Sie Chrome 119 oder höher über die Befehlszeile und aktivieren Sie das Chrome-Flag test-third-party-cookie-phaseout.

Chrome-Flag aktivieren

Um das erforderliche Chrome-Flag zu aktivieren, navigieren Sie von der Adressleiste zu chrome://flags#test-third-party-cookie-phaseout und ändern Sie die Markierung in Enabled. Starten Sie den Browser neu, nachdem die Flags geändert wurden.

Wenn Sie Chrome mit einer lokal deklarierten Gruppe ähnlicher Websites starten möchten, erstellen Sie ein JSON-Objekt, das URLs enthält, die zu einer Gruppe gehören, und übergeben Sie es an --use-related-website-set.

Weitere Informationen zur Ausführung von Chromium mit Flags

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

Beispiel

Wenn Sie Gruppen ähnlicher Websites lokal aktivieren möchten, müssen Sie test-third-party-cookie-phaseout in chrome://flags aktivieren und Chrome über die Befehlszeile mit dem Flag --use-related-website-set mit dem JSON-Objekt starten, das die URLs enthält, die zu einem Satz gehören.

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

Prüfe, ob du Zugriff auf websiteübergreifende Cookies hast

Rufen Sie die APIs (rSA oder rSAFor) von den Websites auf, die getestet werden, und validieren Sie den Zugriff auf die websiteübergreifenden Cookies.

So deklarieren Sie die Beziehung zwischen Domains und geben an, zu welcher Teilmenge sie gehören:

  1. Identifizieren Sie die relevanten Domains. Dazu gehören die primären Domains und Gruppenmitglieder, die zur Gruppe ähnlicher Websites gehören. Ermitteln Sie außerdem, zu welchem Untermengentyp die einzelnen Gruppenmitglieder gehören.
  2. Prüfen Sie, ob die Formatierungsanforderungen und die Validierungsanforderungen festgelegt sind.
  3. Geben Sie die Gruppe ähnlicher Websites im richtigen JSON-Format an.
  4. Senden Sie die Gruppe ähnlicher Websites durch Erstellen einer Pull-Anfrage an die related_website_sets.JSON, wo Chrome die kanonische Gruppe ähnlicher Websites hostet. Zum Erstellen von PRs ist ein GitHub-Konto erforderlich und Sie müssen eine Lizenzvereinbarung des Beitragenden unterzeichnen, um einen Beitrag zur Liste zu leisten.

Sobald die PR erstellt wurde, wird eine Reihe von Prüfungen durchgeführt, um zu bestätigen, dass die Anforderungen aus Schritt 2 erfüllt sind.

Ist der Vorgang erfolgreich, zeigt der PR an, dass die Überprüfungen bestanden wurden. Genehmigte PRs werden einmal pro Woche (dienstags um 12:00 Uhr Eastern Time) manuell in Batches zur Liste der kanonischen Gruppen ähnlicher Websites zusammengeführt.

Wenn eine der Prüfungen fehlschlägt, wird der Absender über einen PR-Fehler auf GitHub benachrichtigt. Der Absender kann die Fehler beheben und die PR aktualisieren. Dabei ist Folgendes zu beachten:

  • Wenn die PR nicht erfolgreich ist, erhalten Sie in einer Fehlermeldung weitere Informationen dazu, warum die Übermittlung fehlgeschlagen ist (Beispiel).
  • Alle technischen Prüfungen für das Einreichen von Sets werden auf GitHub durchgeführt. Daher sind alle Übermittlungsfehler, die aus technischen Prüfungen resultieren, auf GitHub einsehbar.

Unternehmensrichtlinien

Chrome verfügt über zwei Richtlinien, um die Anforderungen von Unternehmensnutzern zu erfüllen:

  • Systeme, die sich möglicherweise nicht mit Gruppen ähnlicher Websites verknüpfen lassen, können die Funktion für Gruppen ähnlicher Websites in allen Unternehmensinstanzen von Chrome über die Richtlinie „RelatedWebsiteSetsEnabled“ deaktivieren.
  • Einige Unternehmenssysteme haben nur interne Websites (z. B. ein Intranet) mit registrierbaren Domains, die sich von den Domains in ihrer Gruppe ähnlicher Websites unterscheiden. Wenn sie diese Websites als Teil ihrer Gruppe ähnlicher Websites behandeln müssen, ohne sie öffentlich zugänglich zu machen (da die Domains vertraulich sind), können sie ihre öffentliche Liste mit Gruppen ähnlicher Websites mit der RelatedWebsiteSetsOverrides-Richtlinie erweitern oder überschreiben.

Chrome löst jede Schnittmenge von öffentlichen und Enterprise-Sets in einem von zwei auf je nachdem, ob replacemements oder additions angegeben ist.

Beispiel für das öffentliche Dataset {primary: A, associated: [B, C]}:

replacements Satzes: {primary: C, associated: [D, E]}
Das Enterprise-Dataset nimmt die gemeinsame Website auf, um einen neuen Satz zu bilden.
Resultierende Sätze: {primary: A, associated: [B]}
{primary: C, associated: [D, E]}
additions Satzes: {primary: C, associated: [D, E]}
Öffentliche und Enterprise-Sets werden kombiniert.
Ergebnissatz: {primary: C, associated: [A, B, D, E]}

„Benutzeraufforderung“ und „Nutzergeste“

Eine „Benutzeraufforderung“ und „Nutzergeste“ sind unterschiedliche Dinge. Chrome zeigt keine Berechtigungsaufforderung die sich zur selben Gruppe ähnlicher Websites befinden, aber Chrome weiterhin erfordert, dass der Nutzer mit der Seite interagiert hat. Bevor Sie die Berechtigung erteilen, Für Chrome ist ein Nutzergeste auch als „User-Interaction“ bezeichnet, oder „Nutzeraktivierung“. Das liegt daran, dass die Verwendung von die Storage Access API außerhalb des Kontexts einer Gruppe ähnlicher Websites (nämlich requestStorageAccess()) erfordert außerdem eine Nutzergeste. Designprinzipien für Webplattformen.

Auf andere Websites zugreifen Cookies oder Speicher

Bei Gruppen ähnlicher Websites wird der Speicherplatz für verschiedene Websites nicht zusammengeführt, sondern nur ermöglicht, einfachere (ohne Aufforderungen) requestStorageAccess()-Anrufe. Ähnliche Website Mit Sets verringert sich nur der Aufwand für die Nutzung der Storage Access API, aber nicht was zu tun ist, nachdem der Zugriff wiederhergestellt wurde. Wenn A und B unterschiedliche Websites sind ähnlicher Websites in derselben Gruppe und die Einbettungen B und B können requestStorageAccess() und erhalten ohne Nachfrage Zugriff auf eigenen Speicher Nutzenden. Bei Gruppen ähnlicher Websites erfolgt keine websiteübergreifende Kommunikation. Für Beispiel: Bei der Einrichtung einer Gruppe ähnlicher Websites an B gesendet werden, um an A weitergeleitet zu werden. Wenn Sie teilen möchten, müssen Sie dies selbst tun, z. B. indem Sie wird ein window.postMessage von einem B-iFrame an einen Ein Frame.

Für Gruppen ähnlicher Websites ist kein impliziter, nicht partitionierter Cookie-Zugriff zulässig ohne eine API aufzurufen. Keine websiteübergreifenden Cookies verfügbar default innerhalb des Satzes; Bei Gruppen ähnlicher Websites sind nur Websites innerhalb des festgelegten überspringen Sie die Berechtigungsaufforderung der Storage Access API. Ein iFrame muss document.requestStorageAccess() aufrufen, wenn er auf seine oder die Seite auf oberster Ebene document.requestStorageAccessFor() aufrufen kann.

Feedback geben

Wenn Sie einen Satz auf GitHub senden und mit der Storage Access API und der requestStorageAccessFor API arbeiten, können Sie Ihre Erfahrungen mit dem Prozess und den auftretenden Problemen teilen.

So nehmen Sie an Diskussionen über Gruppen ähnlicher Websites teil: