Chromes irreführende Aufweichung von Third-Party-Cookies

 (brave.com)
1 Punkte von GN⁺ 2024-08-30 | 1 Kommentare | Auf WhatsApp teilen
  • Chromes Related Website Sets (RWS) erlauben auch nach dem Auslaufen von Third-Party-Cookies ausnahmsweise den Informationsaustausch zwischen verbundenen Websites und könnten so den Schutz der Web-Privatsphäre schwächen
  • Die Funktion beruht auf der Annahme, dass Nutzer Eigentumsverhältnisse zwischen Websites erkennen können, doch in einer Studie mit 30 Personen waren etwa 42 % aller Einschätzungen falsch und etwa 73 % lagen mindestens einmal daneben
  • Selbst wenn Chrome Websites als „verwandt“ einstuft, hielten Nutzer etwa 37 % davon für nicht verwandt, wodurch websiteübergreifendes Tracking zwischen für Nutzer unerwarteten Seiten möglich werden kann
  • Um die Beziehung zu prüfen, muss man eine Website zuerst öffnen; schon beim Anblick von gemeinsamem Branding oder Logos entstehen damit Möglichkeiten für Informationsaustausch und Tracking
  • Brave, Firefox und Safari lehnten RWS beziehungsweise den früheren Namen First-Party Sets ab, und der Vorschlag wurde auch aus der W3C Privacy Community Group entfernt

RWS verändert die Grundannahmen zur Web-Privatsphäre

  • Related Website Sets (RWS) ist eine von Google vor dem Ende der Third-Party-Cookies in Chrome eingeführte Funktion
  • Google argumentiert, RWS reduziere Kompatibilitätsprobleme von Websites und helfe dabei, den Login-Status über verwandte Domains hinweg aufrechtzuerhalten
  • Brave kritisiert, dass RWS die Interessen von Werbetreibenden über die Interessen der Nutzer stellt und auch nach dem Ende der Third-Party-Cookies weiterhin Verknüpfungen zwischen Websites erlaubt
  • Die zentrale Annahme lautet: Wenn zwei Websites von derselben Organisation betrieben werden, können Nutzer den Informationsaustausch erwarten, und der Browser müsse keine Sperren auf dem Niveau von Third-Party-Cookies anwenden
    • Als Beispiel werden instagram.com und facebook.com genannt, die von Meta betrieben werden
  • Diese Annahme schwächt das Web-Privatsphärenmodell in Richtung der Vorstellung ab, dass Tracking zwischen Websites allein wegen derselben organisatorischen Eigentümerschaft erlaubt sein sollte

Nutzerstudie: Beziehungen zwischen Websites sind schwer zu erkennen

  • Die Studie prüft die Kernannahme von RWS: „Können Webnutzer die Beziehung zwischen zwei Websites korrekt einschätzen?“
  • Die Forschenden legten 30 Webnutzern, die über Social Media rekrutiert wurden, jeweils 20 Website-Paare vor
    • Die Website-Paare wurden zufällig aus Chromes RWS-Liste und der Liste populärer Websites Tranco ausgewählt
    • Die Teilnehmenden sollten beurteilen, ob die beiden Websites ihrer Meinung nach von derselben Organisation betrieben werden
    • Da einige Teilnehmende nicht alle Fragen beantworteten, wurden insgesamt 430 eindeutige Bewertungen von Website-Paaren gesammelt
  • Die Erwartungen der Nutzer weichen häufig von der RWS-Liste ab
    • Etwa 73 % der Teilnehmenden beurteilten die Beziehung zwischen zwei Websites mindestens einmal falsch
    • Etwa 42 % aller Bewertungen waren falsch
    • Selbst bei tatsächlich nach RWS verwandten Website-Paaren hielten Nutzer etwa 37 % für nicht verwandt
  • Diese Ergebnisse zeigen, dass RWS auch in Situationen, die Nutzer nicht erwarten, wieder ein Verhalten ermöglichen kann, das Third-Party-Cookies ähnelt
  • Das vollständige Paper ist als arXiv-Paper veröffentlicht und soll auf der Internet Measurement Conference 2024 präsentiert werden

Tracking-Möglichkeiten entstehen vor der eigentlichen Beurteilung

  • Die Intuition hinter RWS ist, dass Nutzer zuerst die Beziehung zwischen Website A und Website B erkennen und Website B nur dann besuchen, wenn sie diese Beziehung akzeptieren
  • In der Praxis muss ein Nutzer Website B jedoch zunächst laden, um gemeinsames Branding oder Logos von Website B zu sehen
  • In dem Moment, in dem die Seite geladen wird, entstehen bereits Möglichkeiten für Informationsaustausch und websiteübergreifendes Tracking
  • Daher kann RWS Privatsphärenschäden verursachen, noch bevor Nutzer die Beziehung zwischen zwei Websites beurteilen

Dieselbe Eigentümerschaft ist keine Grundlage für erlaubtes Tracking

  • RWS beruht auf der Vorstellung, dass es harmlos oder zulässig sei, wenn der Browser den Schutz der Privatsphäre zwischen zwei Websites verringert, sobald diese miteinander verwandt sind
  • Brave hält diese Annahme für falsch
    • Wenn ein Nutzer ein Facebook-Konto und ein Instagram-Konto mit unterschiedlichen E-Mail-Adressen und unterschiedlichen Informationen registriert, können moderne Browser verhindern, dass Meta erkennt, dass beide Konten derselben Person gehören
    • Massenmarkt-Browser wie Brave, Firefox und Safari sowie Spezialbrowser wie Tor Browser und Icefox können diesen Schutz auch als Standardverhalten bereitstellen
  • Einige Unternehmen versuchen, den Privatsphärenschutz von Browsern mit Link Decoration oder Bounce-Tracking zu umgehen
  • Der entscheidende Unterschied ist: Während datenschutzorientierte Browser Techniken zum Blockieren websiteübergreifenden Trackings erproben, entwirft Chrome Funktionen, die Verknüpfungen zwischen Websites erlauben

Reaktionen von Browsern und Standardisierungs-Community

  • RWS wurde wie ein allgemeiner Web-Vorschlag präsentiert, ist aber nach Prüfung bereits von mehreren Akteuren im Web-Ökosystem abgelehnt worden
  • Brave, Firefox und Safari haben öffentlich erklärt, dass RWS beziehungsweise der frühere Name First-Party Sets weder für Nutzer noch für das Web gut sei
  • Der Vorschlag wurde aus der W3C Privacy Community Group entfernt und wird in den datenschutzorientierten Gruppen des W3C nicht weiter behandelt

Eigentümerwechsel und Sprachbarrieren

  • Domains in der RWS-Liste können später an andere Eigentümer übergehen
    • Nur weil die Domains A, B und C heute von derselben Organisation betrieben werden, gibt es keine Garantie, dass das morgen noch so ist
    • Das entspricht Risiken, wie man sie aus Fällen kennt, in denen Browser-Erweiterungen von vertrauenswürdigen Akteuren an böswillige Akteure verkauft wurden oder populäre Softwarebibliotheken und ihre Abhängigkeiten übernommen wurden
    • Selbst wenn eine Website zum Zeitpunkt der Aufnahme in die Liste sinnvoll mit anderen verbunden war, bleibt die Sorge, dass es keinen Mechanismus gibt, sie zu entfernen, wenn sich die Eigentümerschaft stillschweigend ändert
  • Hinzu kommen Sprach- und Wahrnehmungsprobleme
    • Selbst wenn englischsprachige Nutzer englischsprachige Websites bewerten, erkennen sie oft nicht die Beziehungen zwischen Websites, die Google als verwandt einstuft
    • Wenn Nutzer Websites in einer ihnen unbekannten Sprache besuchen, könnte es noch schwieriger werden, diese Beziehungen zu beurteilen

Fazit

  • RWS kann der Web-Privatsphäre auf drei Arten schaden
    • Die Annahme, dass Nutzer vorhersagen können, welche Websites miteinander verwandt sind, stimmt nicht mit dem tatsächlichen Nutzerverhalten überein
    • Noch bevor Nutzer beurteilen können, ob zwei Websites von derselben Organisation betrieben werden, entstehen bereits Möglichkeiten für websiteübergreifendes Tracking
    • Es verankert auf Plattformebene die Annahme, dass eine Organisation Nutzer zwischen ihren Websites verfolgen darf, wenn sie diese Websites besitzt
  • Browser, die die Privatsphäre respektieren, bewegen sich in die Richtung, Tracking auf allen Websites unabhängig von der besitzenden Organisation zu blockieren

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-08-30
Meinungen auf Hacker News
  • Ich nutze seit Langem Firefox und hatte keine größeren Probleme. Früher, als Arbeitsspeicher knapp war, verbrauchte Chrome zwar weniger Speicher, aber Firefox bietet ebenfalls einen Nur-HTTPS-Modus, verschlüsseltes DNS ohne Fallback-Pfad, SOCKS und Unterstützung für Encrypted Client Hello.
    Allerdings wird Encrypted Client Hello nur von sehr wenigen Websites unterstützt. Beim Arbeitsspeicher ist es besser, einfach mehr zu kaufen; eine Ausnahme könnte sein, wenn man das Glück hat, Apple-Produkte zu nutzen.
    Browser sollten auf der Seite der Nutzer stehen und nicht mit Marketingfirmen zusammenarbeiten. Mehr noch: Sie sollten Tracking und Fingerprinting von Nutzern erschweren. Man muss nicht den Browserverlauf von Nutzern verfolgen; man kann einfach ein besseres Produkt als die Konkurrenz bauen, in Reviews und Vergleichen Platz eins erreichen und dann Influencer-Werbung kaufen.
    Es wäre gut, wenn Browser das Lesen von Canvas-Daten, das Auslesen des GPU-Namens, das Auflisten von Audiokarten, das Erkennen installierter Erweiterungen usw. blockieren würden, um Fingerprinting zu erschweren. Neue Web-APIs sollten garantieren, dass keine zusätzlichen Fingerprinting-Daten entstehen, oder hinter Berechtigungen verborgen werden.
    Für Drittanbieter-Cookies sollte der Browser statt fragwürdiger Listen wie RWS einfach einen Button anbieten, mit dem man sie als Ausnahme für alte Websites zulässt, die darauf angewiesen sind. Allerdings besteht das Risiko, dass Zeitungen, Blogs und Q&A-Websites Nutzer zwingen, diesen Button zu drücken, um Inhalte sehen zu können.
    • Browser sollten ursprünglich User Agents sein, die für die Nutzer arbeiten. Heutzutage wird es immer schwieriger, einen Browser zu finden, der nicht auf Kosten der Nutzer für Werbefirmen arbeitet.
      Der Existenzzweck von Chrome ist Datensammlung, und Firefox lässt sich zumindest derzeit mit gehärteten Einstellungen auf die Nutzerseite bringen und kann dann erhebliches Fingerprinting verhindern. Aber auch Mozilla ist inzwischen ein Ad-Tech-Unternehmen geworden, und die Entscheidung, Firefox standardmäßig Nutzer überwachen zu lassen, damit diese Daten an Marketer verkauft werden können, zeigt mangelnden Respekt gegenüber Firefox-Nutzern.
      Derzeit kann man diese Überwachung in about:config abschalten, indem man dom.private-attribution.submission.enabled auf false setzt.
      Siehe https://news.ycombinator.com/item?id=41311479 und https://web.archive.org/web/20240827185708/https://make-fire.... Wie lange diese Option erhalten bleibt und wie oft man sie nach Updates wieder auf false zurücksetzen muss, ist unklar.
      Wir brauchen wirklich einen neuen Browser, der im Interesse der Nutzer handelt.
    • Dass neue Web-APIs garantieren, keine weiteren Fingerprinting-Daten bereitzustellen, ist praktisch unmöglich. Denn schon die Tatsache, ob ein Nutzer in einer Berechtigungsabfrage eine Option ausgewählt hat – und falls ja, welche –, wird bereits zu einem Datenpunkt.
      Deshalb heißt es oft, die einzige Lösung für dieses Problem sei Regulierung, und diese Sichtweise hat einiges für sich.
    • https://news.ycombinator.com/item?id=40703546 — das ist von vor zwei Monaten.
    • Wenn der führende Browser von einer Werbefirma entwickelt wird, ist es ziemlich schwierig, nutzerfreundliche Richtlinien umzusetzen. Schlimmer noch: Dasselbe Unternehmen trägt auch zur Firefox-Stiftung bei und treibt Web-„Standards“ voran.
      Das wirkt alles wie Kartellabsprachen, und dass Browser inzwischen komplexer geworden sind als die Betriebssysteme, auf denen sie laufen, scheint eine absichtliche Struktur zu sein, die kleine Teams daran hindern soll, den Markt aufzumischen. Die sture Lösung besteht darin, das Web so weit wie möglich zu meiden und sich auf Computing in menschlichem Maßstab zu konzentrieren.
    • Die oberste Priorität der Browserhersteller sollte sein, Fingerprinting des Browsers der Nutzer zu verhindern.
      Alle Nachrichten und politischen Diskussionen rund um Cookies wirken wie eine begrenzte Offenlegung.
  • Dieses Ergebnis scheint ziemlich vorhersehbar. Related Website Sets (RWS) sollen so funktionieren, dass Unternehmen Beziehungen zwischen Websites erklären, damit der Browser für bestimmte Zwecke eingeschränkten Zugriff auf Drittanbieter-Cookies erlaubt.
    Bedeutet das also, dass Websites selbst „gesegnete“ Domains deklarieren können, mit denen sie die Blockierung von Drittanbieter-Cookies umgehen? Große Websites suchen ständig nach Wegen, die Versuche der Nutzer, sich selbst zu schützen, zu umgehen und auszunutzen. Wie kann man darauf vertrauen, dass solche Sites das nicht missbrauchen?
    • Websites deklarieren das nicht selbst. Es gibt eine Masterliste, die eingereicht werden muss, und einen Genehmigungsprozess.
      Aber wie der Artikel zeigt, ist schon der Inhalt der vorläufigen Liste beunruhigend. Die Idee „Google als Schiedsrichter für alles, was mit Werbung zu tun hat“ ist ein Fehlschlag.
      Andererseits sind die Alternativen auch nicht gut. Das derzeitige System mit Drittanbieter-Cookies ermöglicht noch viel schlimmere Dinge. Wir brauchen bessere Ideen.
    • Ich kenne mich im Detail nicht aus, aber ich frage mich, ob das dem ähnelt, was ich kürzlich in Safari gesehen habe. Als ich eine zugehörige Microsoft-Website besuchte, erschien ein Popup, ob ich das Teilen von Cookies für den Login erlauben möchte, und ich konnte zustimmen oder ablehnen.
      Diese Implementierung wirkt besser.
  • Das ist eine schwierige Situation. Beziehungen zwischen Domains können und werden missbraucht werden, um Nutzer auf eine Weise zu tracken, die sie nicht erwarten.
    Es gibt aber auch legitime Anwendungsfälle. Die Websites der Stack-Exchange-Familie zum Beispiel sind eindeutig miteinander verbunden und haben auch eine einheitliche Marke, nutzen aber unterschiedliche Domains. In Firefox, wenn Drittanbieter-Cookies blockiert sind, muss man sich bei jeder Domain separat anmelden; wenn man also bei stackoverflow.com eingeloggt ist und dann superuser.com besucht, ist man dort nicht bereits angemeldet. Genau dieses Problem sollen First Party Sets lösen.
    Man könnte sagen, es wäre besser gewesen, wenn diese Sites Subdomains einer einzigen gemeinsamen Domain gewesen wären. Aber als die Sites entstanden, funktionierten Drittanbieter-Cookies problemlos, daher gab es keinen starken Grund, das so zu machen. Eine App auf eine andere Domain umzuziehen, ohne Nutzern Probleme zu bereiten, kann wirklich schmerzhaft und teuer sein.
    Das heißt nicht, dass man First Party Sets unverändert akzeptieren sollte, aber es ist ein Versuch, ein reales Problem zu lösen. Eine Lösung zu finden, die die Privatsphäre der Nutzer schützt und zugleich eine gute Nutzererfahrung bei tatsächlich zusammengehörenden Sites bewahrt, ist schwierig oder vielleicht sogar unmöglich.
    • Wenn man nach dem Login bei stackoverflow.com auch bei superuser.com automatisch eingeloggt sein soll, würde ich ein Berechtigungs-Popup erwarten wie: „Diese Website möchte Cookies mit stackexchange.com teilen. Klicken Sie auf Erlauben, um sich anzumelden, auf Ablehnen, um dies dauerhaft zu verweigern, oder auf Ignorieren, um später zu entscheiden.“

Mit einem Klick könnte man die Vorteile beider Seiten haben. Um Verwirrung zu verringern, sollte jede Website eine einzige „First-Party-Domain“ haben, die für die gesamte Sub-Site gilt, und diese First-Party-Domain sollte Cookies mit keiner anderen Site als sich selbst teilen dürfen.

  • Safari und Firefox blockieren schon seit Jahren Third-Party-Cookies. Stack Overflow hatte genug Zeit, sich anzupassen und auf eine „korrekte“ Organisationsstruktur umzuziehen.
    Wenn ihnen ein einheitlicher Login über mehrere Domains hinweg wichtig gewesen wäre, hätten sie schon vor langer Zeit auf ein Subdomain-Modell wechseln sollen. Denn Nutzer von Firefox und Safari sind seit Langem negativ betroffen.
    Wenn es ihnen nicht besonders wichtig ist, ist das auch in Ordnung, aber dann sollten Chromes Third-Party-Cookie-Blockierung oder die Diskussion um First Party Sets für sie auch kaum relevant sein.
  • Stack Overflow wurde 2008 gegründet. Netscape hat 1997 einen Button zum Blockieren von Third-Party-Cookies hinzugefügt, und das Web hat im Großen und Ganzen auch mit aktivierter Funktion gut funktioniert.
  • Das erinnert daran, wie Google trotz legitimer Anwendungsfälle wie Adblockern bequem auf Manifest V3 umgestellt hat. Technisch könnte V3 sicherer und besser für Nutzer sein, aber hier fühlt es sich wie eine Bewegung in die entgegengesetzte Richtung an.
  • Andere Sites scheinen dieses Problem mit Redirects und Cross-Origin-Headern gut zu lösen. Irgendwann landet man zwar bei signin.foo.com, aber aus Sicht der User Experience wirkt es so, als sei man authentifiziert, ohne sich erneut anmelden zu müssen.
  • Erwartet Google, dass andere Browser einfach ihre Liste kopieren?
    Oder sollen Entwickler verwandte Domains bei jedem Browser einreichen, und jeder Browser pflegt seine eigene Liste?
    Klingt ähnlich wie HSTS.
    [0]: https://github.com/GoogleChrome/related-website-sets/blob/ma...
  • Brave wirkt bei diesem Thema nicht wie eine gute oder objektive Quelle.
    • Brave hat offensichtlich einen kommerziellen Anreiz, sich über Chrome zu beschweren, aber das macht die Beschwerde nicht automatisch falsch.
    • Ich frage mich, ob damit gemeint ist, dass Brave ein Wettbewerber ist, oder etwas anderes.
  • Es scheint an der Zeit zu sein, /.well-known/related-website-set.json zu blockieren.
  • Die Formulierung „auch nachdem Third-Party-Cookies in Chrome abgeschafft wurden“ lässt vermuten, dass dieser Artikel vor ein paar Wochen geschrieben wurde.
    • Kann das jemand erklären?
  • Ich nutze Firefox, also ist es mir egal.
    • Firefox wird das unterstützen, oder deine Lieblingswebsites werden nicht funktionieren und du wirst am Ende zu Chrome wechseln, wo sie funktionieren.
  • Padme: Dann basiert Brave jetzt also nicht mehr auf Chrome?
    • Brave ist nicht Chrome, sondern ein Chromium-Derivat. Ich sehe nicht, warum diese Situation bedeuten sollte, dass sie aufhören müssten, ein Chromium-Derivat zu sein.
      Cookie-Richtlinien und Defaults können sie nach Belieben entwickeln und ausliefern.
    • Brave hat Software Engineers, also werden sie vermutlich genau diesen Teil des Codes deaktivieren und weitermachen, so wie sie es bei vielen Teilen der Chrome-Engine tun.
  • Es ist nicht ganz der passende Ort, aber falls jemand Forschung oder Artikel zu Chromes Ad Topics kennt, wäre ich interessiert. Ich weiß derzeit fast nichts darüber, welche Auswirkungen das auf die Privatsphäre der Nutzer hat und was mit Dritten geteilt wird.