Wie lässt sich prüfen, ob ein Anti-Detect-Browser zuverlässig ist? Vollständige Checkliste und Bewertungstabelle

Einen Anti-Detect-Browser zu prüfen, darf nicht damit enden, eine Erkennungsseite zu öffnen und einen grünen Hinweis zu sehen. Eine Erkennungsseite kann nur die Felder beobachten, die sie implementiert. Sie kann weder beweisen, dass Umgebungen langfristig stabil bleiben, noch dass verschiedene Umgebungen keine Daten vermischen, noch dass ein Proxy-Ausfall das lokale Netzwerk nicht offenlegt, noch dass Team-Berechtigungen, Wiederherstellung nach versehentlichem Löschen und Upgrade-Kompatibilität sauber sind.

Ob ein Produkt zuverlässig ist, sollte in fünf Fragen zerlegt werden: Ist dieselbe Umgebung bei wiederholten Starts konsistent? Werden verschiedene Umgebungen planmäßig getrennt? Stimmen Netzwerkausgang, WebRTC, DNS und IPv6 mit der Proxy-Richtlinie überein? Sind echte Geschäftsseiten kompatibel? Sind Teamdaten, Berechtigungen und Wiederherstellung kontrollierbar? Nur wenn Sie diese fünf Testkategorien wiederholen und die Ergebnisse speichern, kommen Sie zu einer vergleichbaren Schlussfolgerung.

Warum reicht ein „Ein-Schritt-Test" nicht aus?

Wenn Sie sich nur auf Drittanbieter-Erkennungsseiten für Fingerabdrücke verlassen, ist es leicht, sich von einer „alles grün"-Oberfläche überzeugen zu lassen. Die Probleme sind:

• Verschiedene Erkennungsseiten erfassen unterschiedliche Felder, sodass ihre Abdeckung nicht einheitlich ist;
• Eine Seite, die „kein Leck" anzeigt, sagt nichts über die Sicherheit bei einem Proxy-Ausfall;
• Ein einzelnes Ergebnis kann keine Stabilität über Neustarts und Upgrades hinweg zeigen;
• Zufällig generierte Felder können einmal sinnvoll erscheinen, sich aber langfristig häufig ändern;
• Erkennungsseiten kennen das Risikomodell der Zielplattform nicht;
• Sie können keine Mitgliederberechtigungen, Cloud-Daten, Backups oder Audit-Protokolle sehen;
• Selbst eine technisch einwandfreie Umgebung kann keine falschen Profile, Spam-Inhalte oder ungewöhnliche Aktivitäten ausgleichen.

Eine Drittanbieter-Erkennungsseite ist also ein Messwerkzeug und kein Sicherheitszertifikat. Nutzen Sie sie als Quelle beobachtbarer Signale und nicht als endgültige Antwort.

Definieren Sie zuerst Ihre Akzeptanzkriterien für „zuverlässig"

Schreiben Sie vor dem Test die Anforderungen als beobachtbare Ergebnisse auf:

Dimension	Beispiel für ein Bestehenskriterium	Fehlersymptom
Fingerabdruck-Konsistenz	Stabile Felder bleiben nach einem Neustart derselben Umgebung gleich	Canvas, GPU oder Sprache ändern sich ohne Grund
Parameterkohärenz	UA, Kernel, OS und Schriften sind gegenseitig stimmig	Behauptet macOS, zeigt aber klar eine Windows-Kombination
Umgebungsisolierung	Cookies, lokaler Speicher und Erweiterungen vermischen sich nicht zwischen Umgebungen	Der Login-Zustand von A erscheint in B
Netzwerkausgang	IP, WebRTC, DNS und IPv6 stimmen mit der Richtlinie überein	Proxy-IP und lokaler Ausgang erscheinen gleichzeitig
Fehlerbehandlung	Klare Blockierung oder Warnung bei Proxy-Ausfall	Fällt stillschweigend auf das lokale Netzwerk zurück
Kompatibilität	Kernseiten, Uploads, Zahlungen und Video funktionieren	Seitenabstürze, Verifikationsschleifen, defekte Erweiterungen
Wiederherstellbarkeit	Löschen, Gerätewechsel und Upgrade sind über einen definierten Prozess wiederherstellbar	Konfiguration oder Sitzungen gehen dauerhaft verloren
Team-Governance	Least Privilege, Protokolle und Entzug bei Ausscheiden sind umsetzbar	Jeder nutzt ein Admin-Konto

„Jedes Feld ist anders" ist kein Bestehenskriterium. Ein Fingerabdruck sollte mit der voreingestellten Umgebung kohärent bleiben, und dieselbe Umgebung sollte nicht bei jedem Start nur um der Abwechslung willen neu aufgebaut werden.

Richten Sie ein wiederholbares Testlabor ein

Testobjekte

Bereiten Sie mindestens Folgendes vor:

• 1 Basisumgebung mit nativem Browser;
• Anti-Detect-Browser-Umgebungen A und B;
• Zwei Test-Proxys mit unterschiedlichen Regionen oder Protokollen;
• Ein Hauptgerät und ein Ersatzgerät für Gerätewechsel-Tests;
• Nur für Tests gedachte Konten für Ihre eigenen Seiten; nutzen Sie keine Kundendaten im Produktivbetrieb.

Der entscheidende Punkt hier ist, dass die „getesteten Umgebungen" Test-Arbeitsbereiche sein müssen, die Sie jederzeit neu aufbauen und klar benennen können. Wenn Sie im PurpleMark-Webapp einen Arbeitsbereich erstellen, können Sie Umgebungsgruppen nach Plattform oder Konto aufbauen, die Testumgebungen A und B, Test-Proxys und dedizierte Testkonten in einer Gruppe zusammenhalten und jeder Umgebung ein explizites OS, eine Sprache und eine Zeitzone zuweisen, damit sich später leichter feststellen lässt, welche Konfiguration den Unterschied verursacht hat.

Aufzeichnungsbogen

Notieren Sie bei jedem Test Datum, Produktversion, Browser-Kernel, Betriebssystem, Umgebungs-ID, Proxy, Erkennungsseite, Ergebnis-Screenshot und Abweichungen. Bei Screenshots nur notwendige Felder behalten und IPs, Konten, Schlüssel und Gerätekennungen maskieren.

Wiederholen Sie an vier Zeitpunkten: direkt nach der ersten Erstellung, nach Schließen und erneutem Öffnen, nach einem Computer-Neustart und nach einem Produkt- oder Kernel-Upgrade. Ein einziger Test kann Stabilitätsprobleme über die Zeit nicht aufdecken.

Schritt 1: Eine native Browser-Basislinie aufbauen

Führen Sie die Erkennung zuerst in einem normalen Chrome, Firefox oder Edge aus, um zu verstehen, welche Felder dieses Gerät normalerweise offenlegt. Eine Basislinie ist nicht die „richtige Antwort"; sie hilft zu erkennen, ob der Anti-Detect-Browser voreingestellte Elemente tatsächlich geändert hat und ob er offensichtliche lokale Merkmale hinterlässt.

EFFs Cover Your Tracks zeigt, wie Tracker einen Browser sehen, und bietet einen Überblick über die aussagekräftigsten Merkmale. Es eignet sich zur Beobachtung von Eindeutigkeit und Tracking-Schutz, aber die Ergebnisse werden von Besuchergruppe, Browserversion und Testzeit beeinflusst. Lesen Sie es also nicht einfach als „je weniger eindeutig, desto sicherer".

Erfassen Sie folgende Felder:

• Browser- und Kernel-Versionen;
• Betriebssystem und Architektur;
• Bildschirmgröße, Farbtiefe und Zoom;
• Zeitzone, Sprache und Region;
• Schrift- und Mediengeräte-Offenlegung;
• Zusammenfassungen für Canvas, WebGL, Audio usw.;
• Client Hints, Berührungspunkte und Hardware-Parallelität;
• Remote-IP, IPv6 und WebRTC-Kandidatenadressen.

Schritt 2: Die zeitliche Konsistenz derselben Umgebung testen

Führen Sie in Umgebung A der Reihe nach Folgendes aus:

1. Starten und erste Erkennung abschließen;
2. Umgebung schließen, neu starten und erkennen;
3. Nach einem Computer-Neustart erneut erkennen;
4. Netzwerk wechseln, ohne die Umgebungskonfiguration zu ändern, dann erkennen;
5. Nach dem Upgrade von Produkt oder Kernel erneut erkennen.

Vergleichen Sie die Ergebnisse nach Kategorien:

• Sollten stabil bleiben: Umgebungsname, voreingestelltes OS, Sprache, Schriftstrategie, Bildschirm und Canvas/WebGL-Strategie;
• Können sich mit dem Netzwerk ändern: öffentliche IP, Netzwerkstandort und Latenz;
• Können sich mit der Version ändern: Kernel, UA und Client Hints, aber die Änderung sollte zum Upgrade passen;
• Bedarfen einer Erklärung: GPU, Schriften, Gerätename oder Zeitzone, die ohne Konfigurationsänderung springen.

Ein zuverlässiges Produkt sollte Änderungen „vorhersehbar, erklärbar und prüfbar" machen. Wenn sich bei jedem Start zufällige Felder ändern, klären Sie die Designabsicht mit dem Anbieter und testen Sie, ob das Zielgeschäft wiederholte Verifikationen auslöst.

Wenn Sie in PurpleMark testen, liegt der Schwerpunkt dieses Schritts darauf zu prüfen, dass „das Öffnen derselben gleichnamigen Umgebung zweimal die voreingestellten Parameter beibehält". Nach Schließen und erneutem Öffnen derselben Umgebung sollten idealerweise konfigurierte Elemente wie OS, Sprache, Zeitzone und WebRTC gleich bleiben, statt jedes Mal einen neuen Fingerabdruck zu erzeugen; wenn Sie unerklärliche Sprünge sehen, prüfen Sie die Fingerabdruck- und Geräteparameter-Seite dieser Umgebung, statt die Erkennungsseite zu beschuldigen.

Schritt 3: Isolierung und Kohärenz über verschiedene Umgebungen vergleichen

Die Umgebungen A und B müssen sich nicht in jedem Feld unterscheiden, aber sie sollten keine Daten teilen, die sie nicht teilen sollten. Testen Sie:

• Bleibt B nach dem Login in A auf der Testseite abgemeldet?
• Wenn A Cookies, lokalen Speicher und IndexedDB schreibt, sind diese Daten in B unsichtbar?
• Wenn A eine Erweiterung installiert oder ein Lesezeichen hinzufügt, bleibt B wie konfiguriert unabhängig?
• Wenn A Proxy, Sprache und Zeitzone ändert, bleibt B unberührt?
• Wenn beide Umgebungen gleichzeitig laufen, sind Zwischenablage, Download-Verzeichnis und Dateizugriffsgrenzen klar?
• Wenn das Team A teilt, werden die Ressourcen von B versehentlich mitgeteilt?

AmIUnique definiert Browser-Fingerprinting als systematische Erfassung von Informationen wie Browser, OS, Bildschirm, Architektur, Schriften, Plugins, Mikrofon und Kamera, um die Vielfalt von Browser-Fingerprints zu untersuchen. Die Seite erläutert ihre Daten- und Cookie-Behandlung; lesen Sie vor dem Test den Datenschutzhinweis und übermitteln Sie keine Daten in Umgebungen mit sensiblen Geschäftsdaten.

Vergleichen Sie bei der Überprüfung über Umgebungen hinweg, ob die „Kombination sinnvoll ist", statt nur, ob Hashes unterschiedlich sind. Zwei unterschiedliche Hashes können nur eine irrelevante Feldänderung widerspiegeln; zwei identische Hashes bedeuten nicht zwangsläufig, dass alle Sitzungsdaten geteilt werden.

Wenn A und B zwei unabhängige PurpleMark-Umgebungen sind, können Sie auch prüfen, dass ihre Login-Zustände, Cookies und lokalen Daten getrennt bleiben und dass das Öffnen einer Umgebung nicht die Sitzung der anderen anzeigt. Genau darum geht es bei der Akzeptanzprüfung der Umgebungs- und Datenisolierung.

Schritt 4: IP, WebRTC, DNS und IPv6 prüfen

Die Netzwerktests sollten mindestens vier Situationen abdecken: Proxy aktiv, Proxy getrennt, Proxy gewechselt und Systemnetzwerk geändert.

Öffentliche IP

Die von der Remote-Seite gesehene öffentliche Adresse sollte dem voreingestellten Proxy entsprechen. Erfassen Sie IPv4 und IPv6; wenn der Proxy nur IPv4 verarbeitet, kann das System-IPv6 einen weiteren Ausgang bilden.

WebRTC

Der BrowserLeaks-WebRTC-Test zeigt Ihre Remote-IP, WebRTC-Unterstützung, Kandidatenadressen und Mediengeräte-Berechtigungen. Prüfen Sie, ob lokale oder öffentliche Adressen erscheinen, die nicht offengelegt werden sollten, und ob die Browsereinstellung deaktiviert, ersetzt, weiterleitet oder dem Proxy folgt.

„Keine Adresse erscheint" bedeutet nicht, dass die WebRTC-Funktionalität zwangsläufig nutzbar ist. Für Video-Konferenzgeschäfte müssen Sie dennoch Kamera, Mikrofon und Echtzeitverbindung testen, um zu bestätigen, dass die Datenschutzrichtlinie erforderliche Funktionen nicht zerstört hat.

DNS

Prüfen Sie, ob die Domainauflösung über den Proxy, ein Unternehmens-DNS oder das lokale Netzwerk läuft. Wenn die Proxy-IP in der Zielregion liegt, DNS-Anfragen aber aus einer anderen Region kommen, entsteht eine Inkonsistenz. Die genaue Richtlinie hängt vom Proxy-Typ und den Geschäftsanforderungen ab.

Proxy-Ausfall

Dies ist der wichtigste und am häufigsten übersehene Test:

1. Umgebung starten und Proxy-IP bestätigen;
2. Den Netzwerkstatus auf der Testseite fortlaufend aktualisieren;
3. Den Proxy aktiv stoppen oder falsche Anmeldedaten eingeben;
4. Beobachten, ob die Seite offline geht, einen klaren Hinweis zeigt oder auf den lokalen Ausgang zurückfällt;
5. Nach Wiederherstellung des Proxys bestätigen, ob die alte Verbindung neu aufgebaut wird;
6. Zeit, Protokolle und Screenshots speichern.

Für kritische Geschäfte ist in der Regel Fail-Closed oder ein klarer Hinweis besser als stilles Direktverbinden. In PurpleMark werden Proxys zuerst als separate Ressourcen gepflegt und dann an Umgebungen gebunden. Beim Ausfalltest können Sie zuerst die Ausgangs-IP dieses Proxys in der Proxy-Liste prüfen, ihn stoppen und dann beobachten, ob die getestete Umgebung einen Hinweis gibt und offline bleibt, statt sich still auf das lokale Netzwerk umzuschalten; dies bestätigt auch, dass die Bindung zwischen Proxy-Ressource und Umgebung klar ist.

Schritt 5: Prüfen, ob sich Fingerabdruckparameter widersprechen

Zu den häufigen anomalen Kombinationen gehören:

• Der UA behauptet eine Browserversion, aber die tatsächlichen Kernel-Fähigkeiten passen eindeutig nicht;
• OS, Schriften, Scrollbalken und Systemsteuerungen sind nicht kohärent;
• Zeitzone, Sprache und geografischer Standort haben keine sinnvolle Erklärung angesichts der Proxy-Region;
• Die Bildschirmauflösung passt nicht zum Gerätetyp;
• Die Kombination aus WebGL-Renderer und OS ist anomal;
• Es wird ein mobiles Gerät behauptet, während nur auf Desktop beschränktes Verhalten offengelegt wird;
• Client Hints und User-Agent sind inkonsistent.

Ändern Sie nicht manuell jedes Feld auf die „am wenigsten verbreitete" Kombination. Bevorzugen Sie die kohärenten Vorlagen des Produkts und passen Sie dann nur die Elemente an, die Ihr Geschäft wirklich benötigt. Dokumentieren Sie jede Anpassung, damit sie zurückgerollt werden kann. Die beim Erstellen einer Umgebung in PurpleMark verfügbaren Optionen für OS, Chromium-Kernel, UA, Zeitzone, Sprache, geografischen Standort, WebRTC und UDP sollen diese Parameter selbstkonsistent halten; gehen Sie beim Testen von der kohärenten Standardkonfiguration aus und ändern Sie nur die Felder, die das Geschäft erfordert, wobei Sie zuerst die Originalwerte notieren, um vergleichen und zurücksetzen zu können.

Schritt 6: Echte Geschäftskompatibilitätstests durchführen

Erkennungsseiten können echte Arbeit nicht ersetzen. Verwenden Sie die eigenen Testkonten Ihres Unternehmens, um Folgendes zu verifizieren:

• Anmeldung, Abmeldung und Zwei-Faktor-Verifizierung;
• Bild-, Video- und Datei-Uploads;
• Kamera, Mikrofon und WebRTC;
• Zahlungs-Sandbox oder Testkasse;
• Karten, Zeitzone und Lokalisierung;
• Erweiterungen, Passwort-Manager und Zwischenablage;
• Lange Sitzungen, Aufwachen aus dem Schlafmodus und abnormaler Beendigungszustand.

Erfassen Sie Seitenfehler, wiederholte CAPTCHAs, Leistung und Ressourcennutzung. Führen Sie eine Kontoeinschränkung nicht automatisch auf den Fingerabdruck zurück; schließen Sie zuerst Profil, Netzwerk, Zahlung, Inhalt, Verhalten, Berechtigungen und Plattformrichtlinie aus.

Schritt 7: Upgrades, Wiederherstellung und Austritt testen

Zuverlässigkeit umfasst auch die Wiederherstellung nach Fehlern:

1. Eine Nicht-Produktions-Testumgebung duplizieren;
2. Ein Client-Upgrade und ein Kernel-Update simulieren;
3. Prüfen, ob Cookies, Erweiterungen, Proxys und Tabs erhalten bleiben;
4. Ein versehentliches Löschen simulieren und aus dem Papierkorb wiederherstellen;
5. Die Umgebung auf dem Ersatzgerät übernehmen;
6. Die Konfiguration und Geschäftsaufzeichnungen exportieren, die exportiert werden dürfen;
7. Den Cloud-Daten-Löschprozess nach dem Schließen des Kontos verifizieren.

Wenn ein Anbieter nur „Erstellung erfolgreich" zeigt, aber keine Antworten zu Backup, Rollback und Migration geben kann, eignet er sich nicht für kritische Geschäfte. Beim Verifizieren in PurpleMark können Sie zuerst eine versehentlich gelöschte Testumgebung aus dem Papierkorb wiederherstellen (Daten im Papierkorb werden eine Zeit lang aufbewahrt und dann automatisch bereinigt; sie eignen sich für kurzfristige Wiederherstellungsübungen, aber nicht als dauerhaftes Backup) und dann auf Haupt- und Ersatzgerät bestätigen, ob dieselbe Umgebung normal übernommen werden kann und ob Konfiguration und Login-Zustand übergehen.

Schritt 8: Team-Berechtigungen und Audit testen

Erstellen Sie drei Testmitgliedertypen — Administrator, Operator und extern — und verifizieren Sie Punkt für Punkt:

• Wer kann Proxy-Passwörter sehen;
• Wer kann Fingerabdruck- und Netzwerkeinstellungen ändern;
• Wer kann Cookies oder Daten exportieren;
• Wer kann Umgebungen löschen, übertragen oder teilen;
• Ob Schlüsselaktionen Mitglied, Zeit und Objekt aufzeichnen;
• Ob Sitzungen, Schlüssel und Umgebungszugriff beim Ausscheiden sofort widerrufen werden können.

Ein Admin-Passwort, das viele teilen, ist keine zuverlässige Unternehmenslösung, selbst wenn der technische Fingerabdruck gut aussieht. Hier kommen die Mitglieder, Rollen, autorisierten Gruppen und Betriebsprotokolle von PurpleMark ins Spiel: Weisen Sie zuerst verschiedenen Mitgliedertypen verschiedene Rollen und Autorisierungen zu, prüfen Sie dann, wer Proxy-Passwörter sehen und wer die Netzwerkkonfiguration ändern kann, und bestätigen Sie schließlich in den Betriebsprotokollen, dass Schlüsselaktionen Mitglied, Zeit und Objekt aufgezeichnet haben. Simulieren Sie außerdem, wie einem ausscheidenden Mitglied der Umgebungszugriff entzogen wird.

Die 100-Punkte-Bewertungstabelle

Position	Punkte	Bewertungsmethode
Zeitliche Konsistenz derselben Umgebung	20	Keine unerklärlichen Sprünge stabiler Felder über 5 Tests
Datenisolierung zwischen Umgebungen	15	Kein Teilen von Cookies, Speicher, Erweiterungen oder Konfiguration
Parameterkohärenz	15	UA, Kernel, OS, Sprache, Zeitzone und GPU sind sinnvoll
Netzwerk- und Leckbehandlung	20	IP, WebRTC, DNS und IPv6 stimmen mit der Richtlinie überein; kein stilles Direktverbinden bei Ausfall
Echtseiten-Kompatibilität	10	Kernabläufe und Medienfunktionen bestehen
Update, Wiederherstellung und Migration	10	Upgrade, versehentliches Löschen, Gerätewechsel und Export sind machbar
Berechtigungen, Protokolle und Entzug	10	Least Privilege und Austrittsabläufe sind umsetzbar

Sie können 80 Punkte als Schwelle für einen kleinen Pilotversuch festlegen, aber kritische Punkte wie Direktverbinden bei Proxy-Ausfall, Umgebungen mit vermischten Sitzungen oder die Unmöglichkeit, Mitgliederberechtigungen zu widerrufen, sollten Ausschlussfaktoren sein und nicht durch andere Punkte ausgeglichen werden.

Wie lassen sich Fehlurteile bei Erkennungsergebnissen vermeiden?

• Mit mindestens zwei Erkennungswerkzeugen unterschiedlicher Prinzipien gegenprüfen;
• Nicht viele Erkennungsseiten gleichzeitig öffnen, um Störungen durch Erweiterungen oder Ressourcen zu vermeiden;
• Unter denselben Netzwerkbedingungen wiederholen und dann jeweils eine Variable ändern;
• Die Rohfelder speichern, nicht nur die Farbe „bestanden/fehlgeschlagen";
• Produkt-, Kernel- und OS-Versionen notieren;
• Die Basislinie neu aufbauen, nachdem sich die Testwerkzeuge aktualisiert haben;
• Die Datenschutz- und Datenaufbewahrungshinweise der Erkennungsseiten lesen;
• In Testumgebungen nicht in echte Kunden-Backends einloggen.

Häufig gestellte Fragen

Kann ich in den Produktivbetrieb gehen, wenn alle Fingerabdruck-Erkennungsseiten normal anzeigen?

Nein. Sie müssen weiterhin Tests zu wiederholten Starts, Umgebungsisolierung, Proxy-Ausfall, echten Seiten, Upgrade-Wiederherstellung und Berechtigungen abschließen und mit wenigen nicht kritischen Konten pilotieren.

Bedeutet ein unterschiedlicher Canvas-Hash, dass die Umgebungsisolierung erfolgreich ist?

Nicht zwangsläufig. Ein Hash repräsentiert nur einen Teil des Rendering-Ergebnisses. Sie müssen weiterhin Cookies, lokalen Speicher, Erweiterungen, Netzwerk, Zeitzone und Team-Freigabegrenzen prüfen.

Sollte WebRTC vollständig deaktiviert werden?

Das hängt vom Geschäft ab. Funktionen wie Videokonferenzen benötigen WebRTC. Ziel ist es, das Offenlegen unerwünschter Adressen zu vermeiden und gleichzeitig die nötige Kompatibilität zu erhalten, statt alles abzuschalten.

Wie oft sollte ich erneut testen?

Testen Sie unmittelbar nach größeren Produkt- oder Kernel-Updates, OS-Upgrades, Proxy-Anbieter-Wechseln oder Berechtigungsmodell-Änderungen erneut; in stabilen Phasen mindestens vierteljährlich stichprobenartig und mit Versionsvergleichen.

Fazit

Zu prüfen, ob ein Anti-Detect-Browser zuverlässig ist, ist kein „Trick", sondern eine Reihe wiederholbarer Experimente. Drittanbieter-Seiten helfen, Felder zu beobachten; was wirklich entscheidet, ob das Produkt in Ihrem Geschäft eingesetzt werden kann, sind zeitliche Konsistenz, Umgebungsisolierung, Netzwerkfehlerbehandlung, Parameterkohärenz, Echtseiten-Kompatibilität, Wiederherstellung und Migration sowie Team-Governance.

Bauen Sie zuerst eine Basislinie auf und ändern Sie dann jeweils eine Variable; speichern Sie die Rohwerte, statt nur auf den grünen Hinweis zu schauen. Nach Erreichen der Schwelle pilotieren Sie mit nicht kritischen Konten und testen fortlaufend neu. Nur so werden Marketing-Behauptungen zu verifizierbaren technischen Schlussfolgerungen. Wenn Sie starten möchten, können Sie zuerst eine unabhängige, nur für Tests gedachte Umgebung in der PurpleMark-Webapp erstellen und die erste Runde durchführen; wenn Sie lokale Browser-Fähigkeiten benötigen, gehen Sie zur Download-Seite, um die Installation abzuschließen. Ein Test zeigt nur die Leistung unter einer bestimmten Version, einem bestimmten Gerät, Proxy und Zeitpunkt. Weder PurpleMark noch andere Browser-Umgebungswerkzeuge sollten verwendet werden, um Identitäten vorzutäuschen, Datenverkehr aufzublähen, Massen-Spam-Marketing zu betreiben oder Plattformstrafen zu umgehen, und sie können die Einhaltung von Konto- und Content-Regeln nicht ersetzen.