Meldet dich ein Wechsel des VPN-Servers aus dem Shop ab?
Eine neue Ausgangsadresse leert den Cookie-Speicher nicht. Entscheide zuerst, ob du den Netzwerkpfad, die angemeldete Sitzung oder gespeicherte Websitedaten testest.
Wechsle den VPN-Ausgang, während ein Shop in einem anderen Tab geöffnet ist, und der Warenkorb ist meist noch da. Das ist kein VPN-Fehler; es ist der Browser, der genau das tut, was ihm gesagt wurde. Ein Cookie wird vom Browser gesendet, und ein neuer Netzwerkpfad ändert nicht, was der Browser speichert. Hinter „die Seite kennt mich noch“ stecken drei verschiedene Fragen, und die Antwort hängt davon ab, welche du tatsächlich stellst.
Drei Fragen, ein Symptom
Erstens: Erkennt die Seite ein gespeichertes Cookie? Zweitens: Erkennt sie ein angemeldetes Konto, das unabhängig von jedem einzelnen Cookie fortbesteht? Drittens: Erkennt sie etwas am Browser oder Gerät statt an einem gespeicherten Zustand? Jede hat ihren eigenen Test und ihr eigenes Mittel.
| What you changed | What it actually tests |
|---|---|
| VPN exit address | Whether the site treats a different network origin differently |
| Cookie jar for one site | Whether a stored identifier was doing the recognition |
| Browser profile or account | Whether identity, rather than storage, links the visits |
Die meiste Verwirrung entsteht, weil man das Erste ändert und erwartet, dass das Zweite folgt. Eine Netzwerkadresse und ein Browserspeicher sind getrennte Systeme, die zufällig von derselben Seite genutzt werden.
Was ein Cookie tatsächlich trägt
HTTP-Zustandsverwaltung, wie sie in RFC 6265 spezifiziert ist, ist bewusst einfach: Der Server setzt einen Namen und einen Wert mit einem Geltungsbereich, und der Browser gibt sie bei Anfragen zurück, die zu diesem Bereich passen. Der Wert kann eine Sitzungskennung, eine Einstellung oder ein undurchsichtiges Token sein, das der Server einem Warenkorbdatensatz zuordnet. Nichts an dem Mechanismus erwähnt die Adresse des Clients.
Dieses Design ist der Grund, warum gewöhnliche Anmeldungen und Warenkörbe einen Netzwerkwechsel überstehen, und es ist auch der Grund, warum sie ihn bei Trackern überstehen. Derselbe Mechanismus dient beiden Zwecken und unterscheidet nicht zwischen ihnen. Es gibt kein Feld im Protokoll für die Adresse des Clients, also gibt es nichts, was ein neuer Ausgang ungültig machen könnte. Eine Seite, die ein Cookie an einen Netzwerkursprung binden wollte, müsste diese Logik selbst hinzufügen.
Wenn eine Seite ein Cookie zurückschickt, sucht der Server den Datensatz, auf den dieser Wert zeigt. Die Route zu ändern, die die Anfrage genommen hat, ändert die Suche nicht, und das ist die ganze Erklärung für die Beobachtung mit dem Warenkorb.
Entscheide, was dein Test misst
Bevor du etwas änderst, schreib den Zustand auf, von dem du ausgehst: welches Browserprofil, welches Konto, welche Websitedaten, welcher Netzwerkpfad. Ändere dann genau eines davon und beobachte. Ein Test, der Ausgangsadresse und Browserprofil gleichzeitig ändert, beweist nichts über eines von beiden.
curl -sS -c /tmp/jar.txt -b /tmp/jar.txt -o /dev/null -w '%{http_code}\n' https://shop.example/cart
curl -sS -c /tmp/jar.txt -b /tmp/jar.txt -o /dev/null -w '%{http_code}\n' --interface 198.51.100.44 https://shop.example/cartBeide Befehle verwenden dieselbe Cookie-Datei wieder, und der zweite erzwingt eine andere lokale Quelladresse, wo der Host es zulässt. Die Warenkorbantwort ist in beiden Fällen dieselbe, weil der Server nie eine andere Client-Identität gesehen hat, nur einen anderen Pfad. Das ist der Mechanismus in einem reproduzierbaren Paar von Anfragen.
Wenn das Ziel ist zu sehen, ob die Seite dich ohne gespeicherten Zustand erkennt, lösche die Daten dieser Seite und wiederhole es. Wenn sie dich weiterhin erkennt, sind die nächsten Verdächtigen das angemeldete Konto, ein Link, dem du gefolgt bist, oder Browsereigenschaften statt eines Cookies.
Lösche den richtigen Zustand, nicht das Netzwerk
Das Entfernen des Speichers einer einzelnen Seite gehört zu den eigenen Bedienelementen des Browsers, und es meldet dich oft ab oder setzt Einstellungen als Nebenwirkung zurück. Es löscht nicht das Konto oder die Datensätze, die der Dienst bereits führt; dafür braucht es den eigenen Vorgang des Dienstes.
Website-übergreifende Beschränkungen behandeln einen anderen Teil des Problems. Browser können Speicher blockieren oder aufteilen, den eingebettete Dienste sonst seitenübergreifend teilen würden, während eine Anmeldung aus erster Hand weiter funktioniert. Eine erfolgreiche Anmeldung ist daher kein Beweis dafür, dass seitenübergreifendes Tracking funktioniert.
Private Fenster sind ein weiteres Werkzeug mit einem engeren Umfang, als Leute erwarten. Seiten können während der Sitzung weiterhin Cookies setzen, und eine Anmeldung identifiziert weiterhin das Konto. Das Beenden der privaten Sitzung ist es, was den temporären Zustand verwirft, was bedeutet, alle privaten Fenster zu schließen statt nur einen Tab.
Betrachte Fingerprinting schließlich als Möglichkeit und nicht als erste Erklärung. Geräte- und Browsereigenschaften können Besuche ohne jedes gespeicherte Cookie verknüpfen, und das Löschen des Speichers berührt sie nicht. Prüfe zuerst die einfachen Ursachen, weite dann die Untersuchung aus und notiere, welchen Zustand du geändert hast, damit der nächste Vergleich aussagekräftig ist.