Cookie-Matching #89

Open
opened 3 months ago by rufposten · 2 comments
Owner

Hier mal als Vorschlag, gerne Nutzerfeedback und technische Überlegungen einbringen:

Cookie-Matching bedeutet, dass Cookies von einem Partner an einen anderen übergeben werden. Es gibt unabhängiges Matching zwischen Drittanbietern und ein zentrales, das zwischen Google und Drittanbietern abläuft ("Cookie Push"). Ich überlege, die Googlevariante als Unterpunkt zum bestehenden Google Cookiematching (cm.g.doubleclick) einzuführen. Das würde auch meine Recherche erleichtern, denn es ist überhaupt schwer, sich einen Überblick über diese Endpunkte zu verschaffen und ich dann hätte ich diese relativ klar erkennbaren Einbindungen abgehakt.

Zum Testen: Man findet sie mit dem Suchbegriff status-code:302 google_nid z.B. bei spiegel.de mit Einwilligung.

Technische Umsetzung

Das betrifft vor allem @tsmr
Option 1:
Wir verwenden das Custom-Eingabefeld und die User müssen dann die URLs selbst in das relativ große Feld eintragen:

rtb-csync.smartadserver.com/
ib.adnxs.com
sync.taboola.com

**Option 2: **
Man erhält als Unterpunkt eine weitere Auswahlliste, die man Abhaken kann:

  • taboola.com
  • smartadserver.com
  • adnxs.com

Text wäre dann z.B.:

Folgende Anbieter erhielten im Rahmen von Googles "Cookie-Push" eine eindeutige, anbieterspezifische ID, die auf dem IDE-Cookie von Google basiert und mich identifzierbar macht:
Taboola (taboola.com)
Xandr (adnxs.com)

Drittanbieter-Matching ohne Google

Die anderen Cookie-Matching-Dienste werde ich wohl einzeln führen, wobei es sicher sinnvoll ist, sie vordergründig danach zu benennen, z.B. "Cookie-Matching Adobe" und "Cookie-Matching Xandr", weil man sie in der Netzwerkanalyse leicht am Statuscode gemeinsam erkennt und abarbeiten kann.
Zum Testen: Man findet sie bei wetter.de auch ohne Einwilligung mit status-code:302, z.B. https://ib.adnxs.com/getuid?

Die Einbindungen setzen fast immer ein eigenes Cookie, was sie grundsätzlich einwilligungspflichtig macht. Daneben findet sich aber eben oft auch der Nachweis des Matchings, hier wird z.B. das Cookie von Xandr an einen Drittanbieter gesendet.
https://ads.stickyadstv.com/user-registering?dataProviderId=209&gdpr=0&gdpr_consent=&userId=5903755531853940381

Auch hier ist die Frage, ob man sich den Aufwand machen will, das mit optionalen Felder in die Beschwerde hineinzubekommen oder ob man sich darauf beschränkt, den Zweck zu erwähnen und dann nur gegen das Setzen des eigenen Cookies vorgeht.

Hier mal als Vorschlag, gerne Nutzerfeedback und technische Überlegungen einbringen: ## Das ist Cookie-Matching Cookie-Matching bedeutet, dass Cookies von einem Partner an einen anderen übergeben werden. Es gibt unabhängiges Matching zwischen Drittanbietern und ein zentrales, das zwischen Google und Drittanbietern abläuft ("Cookie Push"). Ich überlege, die Googlevariante als Unterpunkt zum bestehenden Google Cookiematching (cm.g.doubleclick) einzuführen. Das würde auch meine Recherche erleichtern, denn es ist überhaupt schwer, sich einen Überblick über diese Endpunkte zu verschaffen und ich dann hätte ich diese relativ klar erkennbaren Einbindungen abgehakt. Zum Testen: Man findet sie mit dem Suchbegriff `status-code:302 google_nid` z.B. bei spiegel.de mit Einwilligung. ## Technische Umsetzung Das betrifft vor allem @tsmr **Option 1:** Wir verwenden das Custom-Eingabefeld und die User müssen dann die URLs selbst in das relativ große Feld eintragen: ``` rtb-csync.smartadserver.com/ ib.adnxs.com sync.taboola.com ``` **Option 2: ** Man erhält als Unterpunkt eine weitere Auswahlliste, die man Abhaken kann: - [ ] taboola.com - [ ] smartadserver.com - [ ] adnxs.com Text wäre dann z.B.: > Folgende Anbieter erhielten im Rahmen von Googles "Cookie-Push" eine eindeutige, anbieterspezifische ID, die auf dem IDE-Cookie von Google basiert und mich identifzierbar macht: Taboola (taboola.com) Xandr (adnxs.com) ## Drittanbieter-Matching ohne Google Die anderen Cookie-Matching-Dienste werde ich wohl einzeln führen, wobei es sicher sinnvoll ist, sie vordergründig danach zu benennen, z.B. "Cookie-Matching Adobe" und "Cookie-Matching Xandr", weil man sie in der Netzwerkanalyse leicht am Statuscode gemeinsam erkennt und abarbeiten kann. Zum Testen: Man findet sie bei wetter.de auch ohne Einwilligung mit status-code:302, z.B. https://ib.adnxs.com/getuid? Die Einbindungen setzen fast immer ein eigenes Cookie, was sie grundsätzlich einwilligungspflichtig macht. Daneben findet sich aber eben oft auch der Nachweis des Matchings, hier wird z.B. das Cookie von Xandr an einen Drittanbieter gesendet. https://ads.stickyadstv.com/user-registering?dataProviderId=209&gdpr=0&gdpr_consent=&userId=5903755531853940381 Auch hier ist die Frage, ob man sich den Aufwand machen will, das mit optionalen Felder in die Beschwerde hineinzubekommen oder ob man sich darauf beschränkt, den Zweck zu erwähnen und dann nur gegen das Setzen des eigenen Cookies vorgeht.
rufposten added the
enhancement
question
labels 3 months ago
tsmr was assigned by rufposten 3 months ago
Collaborator

Also habe ich das Projekt jetzt in einem neuen Branch gestartet. Da ich das schon länger geplant hatte, arbeite ich parallel dazu an einer automatisierten Analyse von har-Dateien.

So soll es die Möglichkeit geben, eine har-Datei direkt im Browser mit dem Tracktor zu analysieren und die Tracker werden dann automatisch ausgewählt (ich hab das jetzt einfach mal Tracktorlytics genannt 😆 ).

Neben den eigentlichen Trackern soll auch das Cookie-Matching automatisch erkannt werden. Zusätzlich zu der automatisierten Analyse soll es ein noch "Labor" (aktuell über den Footer erreichbar) geben, in dem man die Cookies und die Beziehungen untereinander besser analysieren kann. Wenn dann auf ein Cookie geklickt wird, werden rechts in der Netzwerkanzeige alle zu dem Cookie zugehörigen Anfragen aufgelistet, die dann wie bei der Netzwerkanalyse genauer untersuchen werden können.

Das ist alles noch sehr experimentell, aber ich dachte, es wäre sinnvoll, wenn du gleich zu Beginn deinen Senf dazu gibts, damit die Analysen für dich auch einfacher werden :^).

Es gibt bereits einen Ordner mit Beispiel-Har-Dateien, der ist aber noch etwas leer und kann gerne mit weiteren Beispielen gefüllt werden :).

Also habe ich das Projekt jetzt in einem neuen Branch gestartet. Da ich das schon länger geplant hatte, arbeite ich parallel dazu an einer automatisierten Analyse von har-Dateien. So soll es die Möglichkeit geben, eine har-Datei direkt im Browser mit dem Tracktor zu analysieren und die Tracker werden dann automatisch ausgewählt (ich hab das jetzt einfach mal Tracktorlytics genannt 😆 ). Neben den eigentlichen Trackern soll auch das Cookie-Matching automatisch erkannt werden. Zusätzlich zu der automatisierten Analyse soll es ein noch "Labor" (aktuell über den Footer erreichbar) geben, in dem man die Cookies und die Beziehungen untereinander besser analysieren kann. Wenn dann auf ein Cookie geklickt wird, werden rechts in der Netzwerkanzeige alle zu dem Cookie zugehörigen Anfragen aufgelistet, die dann wie bei der Netzwerkanalyse genauer untersuchen werden können. Das ist alles noch **sehr** experimentell, aber ich dachte, es wäre sinnvoll, wenn du gleich zu Beginn deinen Senf dazu gibts, damit die Analysen für dich auch einfacher werden :^). Es gibt bereits einen Ordner mit Beispiel-Har-Dateien, der ist aber noch etwas leer und kann gerne mit weiteren Beispielen gefüllt werden :).
Poster
Owner

Wow, das wäre ziemlich genial! Dann könnte man in die Anschreiben nämlich die Details aus der Analyse einfügen, was die eigene Betroffenheit rechtlich präziser macht. Im Gegenzug könnte man die ganzen hätte-hätte-Fahrradkette-Formulierungen kürzen.

Es gäbe im Prinzip drei grundlegende Prüfungen, die man programmieren müsste:

  1. Cookie/Key mit Namen XYZ und Inhalt ABC wird als 1P-Cookie / als 3P-Cookie / im Local Storage geschrieben
  2. Diese ID wird im Parameter DEF an URL example.com übertragen
  3. Diese ID wird im Cookie-Matching als Redirect (location) als Parameter GHI an example2.com übertragen

Hier mal ein Beispiel für den 3. Fall: Das Cookie uuid von mathtag wird über einen Redirect an "location" als Parameter userID an stickyadstv.com gesendet. Hier die Antwortkopfzeile des Requests (https://sync.mathtag.com/sync/img?mt_exid=44&gdpr=0&gdpr_consent=&redir=https://ads.stickyadstv.com/user-registering?dataProviderId=183&userId=[MM_UUID]):

HTTP/1.1 302 Moved Temporarily
Date: Fri, 09 Jul 2021 11:25:33 GMT
Content-Type: image/gif
Content-Length: 0
Connection: keep-alive
Keep-Alive: timeout=360
Server: MT3 3799 851f7e8 master zrh-pixel-x28
Cache-Control: no-cache
P3P: CP="NOI DSP COR NID CURa ADMa DEVa PSAa PSDa OUR BUS COM INT OTC PUR STA"
set-cookie: uuid=34e060e8-322d-4600-ad04-cd4a381d7a70; domain=.mathtag.com; path=/; expires=Sat, 06-Aug-2022 11:25:33 GMT; SameSite=None; Secure
location: https://ads.stickyadstv.com/user-registering?dataProviderId=183&userId=34e060e8-322d-4600-ad04-cd4a381d7a70&gdpr=0&gdpr_consent=
Expires: Fri, 09 Jul 2021 11:25:32 GMT

Idealerweise gestalten wir aus jeder Prüfung einen einheitlichen Satz, der mit entsprechenden Variable (check1 check2,check3) irgendwo in den Trackingtext eingefügt wird. Das sollte die meisten Fälle abdecken. Nur Google Cookie-Matching ist komplizierter und vielleicht gibt es auch mal einen Tracker, der mehrere IDs nutzt.

Die Frage ist noch, ob wir die Analyse langfristig nur mit HAR-Datei umsetzen oder eine manuelle Variante behalten (müssen). Ich denke, dass sowohl Poweruser als auch Einsteiger mit der HAR-Analyse besser zu Recht kommen.

Die visuelle Analyse (Labor) halte ich für schön, aber unnötig. Man wird dort viele verwirrende Verbindungen (insbesondere die Content-Management-Plattformen) sehen, die dann unheimlich wirken, aber rechtmäßig sind. Für diejenigen wiederum, die sich zutrauen, eine eigene manuelle Analyse zu machen, ist die Netzwerkanalyse vertraut und auch fehlerfrei. Aber es sieht natürlich schön aus, also wenn du Spaß daran hast, gerne!

Was ein Labor für mich hingegen wirklich leisten könnte, wäre folgendes:

  1. Eine Liste, welche IDs aus Cookies und localStorage geschrieben wurden und dann als Parameter an welche Adresse gingen. So kann ich sofort sehen, wer ein Cookie einsetzt.

  2. Ein Fingerprintingtest, der drei HAR-Dateien vergleicht: Zwei vom gleichen Browser aber mit zwischendrin gelöschtem Storage und eine dritte von einem anderen Browser. Finden sich bei bei den ersten beiden ein identischer Cookie/Key/URL-Parameter, der aber beim dritten ein anderer ist, liegt höchstwahrscheinlich Fingerprinting vor.

Wow, das wäre ziemlich genial! Dann könnte man in die Anschreiben nämlich die Details aus der Analyse einfügen, was die eigene Betroffenheit rechtlich präziser macht. Im Gegenzug könnte man die ganzen hätte-hätte-Fahrradkette-Formulierungen kürzen. Es gäbe im Prinzip drei grundlegende Prüfungen, die man programmieren müsste: 1. Cookie/Key mit Namen XYZ und Inhalt ABC wird als 1P-Cookie / als 3P-Cookie / im Local Storage geschrieben 2. Diese ID wird im Parameter DEF an URL example.com übertragen 3. Diese ID wird im Cookie-Matching als Redirect (location) als Parameter GHI an example2.com übertragen Hier mal ein Beispiel für den 3. Fall: Das Cookie uuid von mathtag wird über einen Redirect an "location" als Parameter userID an stickyadstv.com gesendet. Hier die Antwortkopfzeile des Requests (https://sync.mathtag.com/sync/img?mt_exid=44&gdpr=0&gdpr_consent=&redir=https://ads.stickyadstv.com/user-registering?dataProviderId=183&userId=[MM_UUID]): ``` HTTP/1.1 302 Moved Temporarily Date: Fri, 09 Jul 2021 11:25:33 GMT Content-Type: image/gif Content-Length: 0 Connection: keep-alive Keep-Alive: timeout=360 Server: MT3 3799 851f7e8 master zrh-pixel-x28 Cache-Control: no-cache P3P: CP="NOI DSP COR NID CURa ADMa DEVa PSAa PSDa OUR BUS COM INT OTC PUR STA" set-cookie: uuid=34e060e8-322d-4600-ad04-cd4a381d7a70; domain=.mathtag.com; path=/; expires=Sat, 06-Aug-2022 11:25:33 GMT; SameSite=None; Secure location: https://ads.stickyadstv.com/user-registering?dataProviderId=183&userId=34e060e8-322d-4600-ad04-cd4a381d7a70&gdpr=0&gdpr_consent= Expires: Fri, 09 Jul 2021 11:25:32 GMT ``` Idealerweise gestalten wir aus jeder Prüfung einen einheitlichen Satz, der mit entsprechenden Variable (check1 check2,check3) irgendwo in den Trackingtext eingefügt wird. Das sollte die meisten Fälle abdecken. Nur Google Cookie-Matching ist komplizierter und vielleicht gibt es auch mal einen Tracker, der mehrere IDs nutzt. Die Frage ist noch, ob wir die Analyse langfristig nur mit HAR-Datei umsetzen oder eine manuelle Variante behalten (müssen). Ich denke, dass sowohl Poweruser als auch Einsteiger mit der HAR-Analyse besser zu Recht kommen. Die visuelle Analyse (Labor) halte ich für schön, aber unnötig. Man wird dort viele verwirrende Verbindungen (insbesondere die Content-Management-Plattformen) sehen, die dann unheimlich wirken, aber rechtmäßig sind. Für diejenigen wiederum, die sich zutrauen, eine eigene manuelle Analyse zu machen, ist die Netzwerkanalyse vertraut und auch fehlerfrei. Aber es sieht natürlich schön aus, also wenn du Spaß daran hast, gerne! Was ein Labor für mich hingegen wirklich leisten könnte, wäre folgendes: 1. Eine Liste, welche IDs aus Cookies und localStorage geschrieben wurden und dann als Parameter an welche Adresse gingen. So kann ich sofort sehen, wer ein Cookie einsetzt. 2. Ein Fingerprintingtest, der drei HAR-Dateien vergleicht: Zwei vom gleichen Browser aber mit zwischendrin gelöschtem Storage und eine dritte von einem anderen Browser. Finden sich bei bei den ersten beiden ein identischer Cookie/Key/URL-Parameter, der aber beim dritten ein anderer ist, liegt höchstwahrscheinlich Fingerprinting vor.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.