Inhaltsübersicht: Wenn bei Ihrer Geschäftsprüfung WebRTC einen Leak anzeigt, sollten Sie zunächst keine wichtigen Konten anmelden oder bedienen, die aktuelle Umgebung schließen und dann die Proxy-Verbindung, den WebRTC-Modus, IPv6 und Proxy-Bypass-Regeln überprüfen. Für MostLogin-Benutzer sind die häufigsten Maßnahmen: Bestätigen, dass der Proxy erfolgreich erkannt wurde, und den WebRTC-Modus der Umgebung auf Private (Privat) setzen; wenn das Geschäft weder Web-Audio/Video noch Peer-to-Peer-Kommunikation benötigt, kann auch Disabled (Deaktiviert) gewählt werden; gleichzeitig sollte die Schutzregel aktiviert werden, die das Öffnen der Umgebung bei Proxy-Fehlern verhindert.
Beachten Sie, dass das Erscheinen mehrerer Adressen auf einer Testseite nicht unbedingt einen Leak bedeutet. Nur wenn die Seite Ihre echte öffentliche IPv4, echte öffentliche IPv6 oder einen nicht zu dieser Umgebung gehörenden Netzwerkausgang anzeigt, handelt es sich um ein Hochrisikoproblem, das sofort behandelt werden muss.
Was ist WebRTC? Warum kann es gewöhnliche Proxy-Einstellungen umgehen?
WebRTC steht für „Web Real-Time Communication", also „Echtzeit-Kommunikation im Web". Es ermöglicht Browsern, direkt Sprachanrufe, Videokonferenzen, Bildschirmfreigaben und Peer-to-Peer-Datenübertragungen durchzuführen. Viele Online-Meeting-Tools, Kundenservice-Systeme und Kollaborationsplattformen nutzen es.
Um eine verfügbare Verbindung zwischen zwei Geräten zu finden, sammelt WebRTC über ICE mehrere „Kandidatenadressen". Diese können Geräte-Netzwerkschnittstellenadressen, über STUN-Server ermittelte öffentliche Zuordnungsadressen und über TURN-Server vermittelte Adressen umfassen. Die MDN-Dokumentation zu ICE-Kandidatentypen zeigt, dass host-Kandidaten direkte Geräteadressen darstellen, srflx-Kandidaten durch STUN/TURN-Interaktion erzeugt werden und relay-Kandidaten über TURN weitergeleitet werden. MDN WebRTC-Verbindungsdokumentation
Dies ist auch der Grund für WebRTC-Leaks: Webseiten erstellen über JavaScript WebRTC-Verbindungen und lesen ICE-Kandidaten aus. Wenn der Browser diese Adressen nicht korrekt einschränkt, können die von der Webseite gesehenen Netzwerkinformationen vom Proxy-Ausgang abweichen. Die MDN weist ausdrücklich darauf hin, dass ICE-Kandidatenadressen Gerätestandort- und Netzwerktopologieinformationen preisgeben können, die über die Erwartungen der Benutzer hinausgehen, und für Browser-Fingerprinting verwendet werden können. MDN RTCIceCandidate-Sicherheitshinweise
Einfach erklärt: Normale Webseitenanfragen können über den Proxy laufen, aber WebRTC sucht zusätzlich nach Echtzeit-Kommunikationswegen. Wenn diese beiden Wege nicht einheitlich eingeschränkt sind, kann die Webseite gleichzeitig die „Proxy-IP" und „eine andere Gruppe von Netzwerkadressen" sehen.
Wann handelt es sich um einen WebRTC-Leak?
Um einen Leak zu erkennen, darf man nicht nur prüfen, ob auf der Testseite eine IP erscheint, sondern muss vergleichen, „was die Seite anzeigt" mit „was die Umgebung anzeigen sollte".
| Testergebnis | Ist es ein Leak? | Risikobewertung |
|---|---|---|
| WebRTC-öffentliche IP stimmt mit der von MostLogin erkannten Proxy-IP überein | Normalerweise nein | Normal, weiter DNS, Zeitzone und Geolocation-Konsistenz prüfen |
| Zeigt die echte öffentliche IP von Heim-Breitband, Firmennetzwerk oder mobilem Hotspot | Ja | Hohes Risiko, Kontovorgänge in der aktuellen Umgebung sofort stoppen |
| Proxy ist IPv4, aber die Testseite zeigt echte öffentliche IPv6 | Ja | Hohes Risiko, IPv6 ist möglicherweise nicht vom Proxy abgedeckt |
Zeigt 192.168.x.x, 10.x.x.x oder andere private Adressen | Nicht unbedingt | Dies ist eine Offenlegung von LAN-Informationen, normalerweise kein Leak des öffentlichen Ausgangs, erhöht aber die Netzwerk-Fingerprint-Informationen |
Zeigt zufällige .local-Namen | Normalerweise nein | In den meisten Fällen das Ergebnis von mDNS zur Verschleierung lokaler Adressen |
| Zeigt mehrere Adressen, aber alle gehören zum selben Proxy- oder Relay-Ausgang | Normalerweise nein | Können IPv4, IPv6 oder verschiedene ICE-Kandidatentypen sein |
Moderne Browser können mDNS-Hostnamen statt LAN-IPs verwenden. Daher bedeutet das Erscheinen einer zufälligen Zeichenfolge mit .local auf der Testseite nicht, dass die echte öffentliche IP offengelegt wurde. Wirklich beachtet werden muss: Ob die echte öffentliche ISP-IP erscheint, die außerhalb der Browser-Umgebung abgefragt wurde.
Welche Folgen hat ein WebRTC-Leak?
1. Proxy-Identität und echte Netzwerkidentität stehen im Widerspruch
Angenommen, eine MostLogin-Umgebung ist mit einem New Yorker Proxy konfiguriert, und Webseitenanfragen zeigen ebenfalls die New Yorker IP, aber WebRTC enthüllt die öffentliche IP des lokalen Netzwerks des Benutzers. Die Plattform sieht keine natürliche, stabile Browse-Umgebung, sondern zwei Verbindungssignale mit widersprüchlichen geografischen Standorten oder Netzwerkprovidern.
Dies beweist nicht automatisch, wer der Benutzer ist, aber es schwächt die Proxy-Isolierung und kann ein Signal für abnormales Risikomanagement, zusätzliche Überprüfungen oder Sitzungsprüfungen sein.
2. Verschiedene Browser-Umgebungen können über dieselbe echte IP verknüpft werden
Teams erstellen für verschiedene Testprojekte mehrere unabhängige Umgebungen, jede mit einem anderen Proxy. Wenn alle diese Umgebungen über WebRTC dieselbe öffentliche Büro-IP preisgeben, kann die Webseite ein umgebungsübergreifendes Wiederholungssignal erhalten. Selbst wenn Cookie, Canvas und WebGL jeweils isoliert sind, verringert der wiederholt erscheinende echte Netzwerkausgang die Unabhängigkeit zwischen den Umgebungen.
3. Ungefährer Standort, Netzbetreiber und Netzwerkstruktur werden offengelegt
Öffentliche IPs können normalerweise zur Bestimmung von Land, Stadtregion und Netzbetreiber verwendet werden; LAN-Adressen, IPv6 oder verschiedene Netzwerkschnittstellen können zusätzliche Netzwerktopologiemerkmale offenbaren. IPs können allein normalerweise keine genaue Adresse oder den echten Namen bestimmen, aber sie können mit Login-Konten, Cookies, Geräte-Fingerprints und Verhaltensdaten kombiniert werden.
4. Videokonferenzen und Web-Anrufe können „Datenschutz vs. Nutzbarkeit"-Konflikte verursachen
Das direkte Deaktivieren von WebRTC kann die Angriffsfläche reduzieren, aber Videokonferenzen, Sprach-Kundenservice, Bildschirmfreigaben oder direkte Dateiübertragungen, die auf WebRTC angewiesen sind, funktionieren möglicherweise nicht mehr. Daher ist der richtige Ansatz nicht, WebRTC in allen Szenarien pauschal zu deaktivieren, sondern je nach Geschäftsbedarf zwischen Private und Disabled zu wählen.
Anti-Detect-Browser zeigt WebRTC-Leak: Führen Sie zuerst diese 6 Schritte durch
Schritt 1: Empfindliche Vorgänge in der aktuellen Umgebung pausieren
Wenn die Testseite bereits die echte öffentliche IP anzeigt, fahren Sie nicht mit Anmeldungen, Zahlungen, Veröffentlichungen oder dem Wechsel wichtiger Konten fort. Notieren Sie zunächst die Testergebnisse, einschließlich:
- Die von der normalen IP-Erkennung angezeigte Adresse;
- Die von der WebRTC-Erkennung angezeigten IPv4- und IPv6-Adressen;
- Die in MostLogin konfigurierte Proxy-Adresse und Land/Region;
- Testzeit, Umgebungsname und ob ein VPN verwendet wurde.
Das Notieren der Informationen dient der Problemdiagnose. Es wird nicht empfohlen, Proxy-Passwörter, Konto-Cookies oder andere Anmeldedaten in Screenshots zu speichern.
Schritt 2: „Echte IP – Proxy-IP – WebRTC-IP"-Vergleich erstellen
Führen Sie drei Überprüfungen durch, ohne Geschäftskonten zu öffnen:
- Fragen Sie in einem normalen Browser ohne Proxy die aktuelle öffentliche IPv4 und IPv6 ab als echte Netzwerkbasis.
- Klicken Sie in MostLogin im
Proxy-Tab auf die Proxy-IP-Überprüfung und notieren Sie den erwarteten Ausgang. - Öffnen Sie die entsprechende Umgebung und lesen Sie die Kandidatenadressen auf der WebRTC-Testseite ab.
Wenn das WebRTC-Ergebnis der ersten Basisgruppe entspricht, aber nicht dem zweiten Proxy-Ausgang, kann ein Leak bestätigt werden. Wenn das Ergebnis mit der Proxy-IP übereinstimmt, handelt es sich wahrscheinlicher um eine normale WebRTC-Kandidatenanzeige.
Schritt 3: Zuerst den Proxy reparieren, dann WebRTC anpassen
WebRTC-Einstellungen können einen bereits offline, fehlgeschlagen authentifizierten oder falsch konfigurierten Proxy nicht beheben. Gehen Sie zur Bearbeitungsseite der Zielumgebung, öffnen Sie den Proxy-Tab, überprüfen Sie Protokoll, Host, Port, Benutzername und Passwort und führen Sie dann die Proxy-IP-Überprüfung durch. Die offizielle MostLogin-Anleitung zum Erstellen von Umgebungen besagt, dass derzeit direct, http, https und socks5 konfiguriert werden können und das Verbindungsergebnis über „Check proxy IP" überprüft werden kann. MostLogin: Neue Umgebung erstellen
Fahren Sie erst fort, wenn die Proxy-Überprüfung erfolgreich war und das angezeigte Land und die Stadt den Erwartungen entsprechen.
Schritt 4: Den geeigneten WebRTC-Modus in MostLogin auswählen
Der Pfad ist normalerweise:
Profiles (Umgebungsliste) → Zielumgebung auswählen → Edit (Bearbeiten) → Fingerprint (Fingerabdruck) → WebRTC
Die aktuelle offizielle MostLogin-Dokumentation zeigt die WebRTC-Dropdown-Einstellungen, wobei Private verwendet wird, um die echte IP zu verbergen, während die WebRTC-Funktionalität erhalten bleibt. Zusätzlich können Public und Disabled verfügbar sein. MostLogin: WebRTC-Fingerprint-Einstellungen
| Modus | Empfohlenes Szenario | Hinweise |
|---|---|---|
| Private | Tägliches Browsen, Browser-Audio/Video, Kundenservice oder Kollaborationstools | Bevorzugt wählen; nach dem Speichern erneut testen, um Bestätigung mit dem Proxy zu erhalten |
| Disabled | Umgebungen, die keinerlei Videokonferenzen, Audio oder P2P-Funktionen benötigen | Klarere Datenschutzgrenzen, aber relevante Webseitenfunktionen können fehlschlagen |
| Public | Nur für Entwicklungs- oder Kompatibilitätstests, die explizit öffentliche Netzwerkkandidaten erfordern | Nicht geeignet für Proxy-Umgebungen, die den echten Netzwerkausgang verbergen müssen |
Für gewöhnliche Proxy-Umgebungen wird empfohlen, zunächst Private zu verwenden. Nur wenn das Geschäft nicht von WebRTC abhängt oder der Private-Modus die Isolationsanforderungen nicht erfüllt, sollte Disabled getestet werden. Glauben Sie nicht allein aufgrund von „WebRTC enabled" auf der Testseite, dass ein Leak vorliegt; entscheidend ist, welche Adresse zurückgegeben wird.
Schritt 5: Proxy-Fehlerschutz aktivieren und Proxy-Bypass-Liste prüfen
Gehen Sie zu den globalen Einstellungen oder Umgebungspräferenzen von MostLogin und aktivieren Sie den folgenden Schutz:
- Umgebung bei Proxy-Netzwerkfehler nicht öffnen;
- Umgebung bei Änderung der Proxy-IP nicht öffnen;
- Umgebung bei Änderung des Proxy-IP-Landes oder der Region nicht öffnen;
- Umgebung bei Synchronisierungsfehler nicht öffnen.
MostLogin beschreibt diese Einstellungen als Schutzmaßnahmen vor dem Start. Der Proxy-Netzwerkfehlerschutz verhindert, dass bei einem Proxy-Ausfall versehentlich die echte ISP-IP offengelegt wird. MostLogin: Profile preferences
Überprüfen Sie auch Settings → Proxy bypass. Domains, die in die Bypass-Liste aufgenommen werden, verwenden direkt das lokale Netzwerk anstatt den Proxy der aktuellen Umgebung. Die offizielle MostLogin-Dokumentation bestätigt ebenfalls, dass Bypass-Domains über echte lokale Verbindungen zugreifen. MostLogin: Proxy bypass Wenn Testseiten, Authentifizierungsdomains oder deren API/CDN-Domains hier aufgeführt sind, entfernen Sie unnötige Ausnahmen und speichern Sie.
Schritt 6: Umgebung vollständig schließen und erneut öffnen, dann Kreuzprüfung durchführen
Nach dem Speichern der Einstellungen schließen Sie die gesamte Browser-Umgebung und starten Sie sie neu, anstatt nur die Testseite neu zu laden. Verwenden Sie mindestens zwei unabhängige Testseiten zur Überprüfung:
- Die normale öffentliche IP, die der Browser nach außen anzeigt;
- Die IPv4 unter den WebRTC-Kandidaten;
- Die IPv6 unter den WebRTC-Kandidaten;
- Ob DNS, Zeitzone, Sprache und Geolocation mit der Proxy-Region übereinstimmen.
Die Kriterien für das Bestehen der erneuten Prüfung sind: Die Testseite zeigt keine echte ISP-öffentliche IPv4/IPv6 mehr an; die von WebRTC angezeigte öffentliche Adresse sollte mit dem Proxy, dem Relay-Ausgang oder dem erwarteten Produktverhalten übereinstimmen; die Ergebnisse bleiben nach dem Neustart der Umgebung stabil.
MostLogin-Anwendungsbeispiel: New Yorker Proxy-Umgebung erkennt echte IPv6
Szenario
Ein regionenübergreifendes Website-QA-Team hat eine MostLogin-Umgebung namens US-NewYork-QA-01 erstellt. Die HTTP-Proxy-Überprüfung zeigt New York, USA, IPv4. Nach dem Öffnen der Testseite bleibt die normale IP weiterhin New York, aber der WebRTC-Bereich zeigt eine öffentliche IPv6 des lokalen Providers an.
Diagnose
Dies ist ein echter Leak und kein normaler Fall von „mehreren angezeigten IPs". Der Grund ist, dass der HTTP-Proxy die IPv4-Webseitenanfragen abdeckt, aber der IPv6-Netzwerkpfad des Hosts nicht gleich behandelt wird, sodass WebRTC-Kandidaten diese Adresse weiterhin preisgeben können.
Behebung
- Umgebung schließen, um weitere Login-Tests zu vermeiden.
- Überprüfen, ob der Proxy-Dienst explizit IPv6 unterstützt; wenn nicht, eine Proxy-Lösung verwenden, die IPv4/IPv6 vollständig abdeckt, oder den ungeschützten IPv6-Pfad auf Systemnetzwerkebene deaktivieren.
- Umgebung bearbeiten und unter
Fingerprint → WebRTCdie Option Private auswählen. - „Umgebung bei Proxy-Netzwerkfehler nicht öffnen" aktivieren.
- Proxy-Bypass-Liste überprüfen und Ausnahmedomains im Zusammenhang mit der Testseite entfernen.
- Umgebung erneut öffnen und überprüfen, dass die echte IPv6 nicht mehr erscheint.
In diesem Szenario kann das bloße Wechseln des WebRTC-Modus die Erkennung vorübergehend beseitigen, aber die Proxy-Abdeckung für IPv6 bleibt das Grundproblem. Daher müssen beide Aspekte überprüft werden.
MostLogin-Anwendungsbeispiel: Testseite zeigt .local an, aber öffentliche IP stimmt mit Proxy überein
Szenario
Ein Benutzer verwendet einen britischen Proxy. Sowohl die normale IP als auch die öffentliche WebRTC-Adresse zeigen Großbritannien. Die Testseite listet zusätzlich eine zufällige Zeichenfolge mit .local am Ende auf, was fälschlicherweise als Leak interpretiert wird.
Bewertung
.local ist normalerweise das Ergebnis davon, dass der Browser mDNS-Namen verwendet, um lokale Netzwerkadressen zu verbergen. Solange keine echte ISP-öffentliche IPv4/IPv6 erscheint und die öffentlichen Kandidaten mit dem britischen Proxy übereinstimmen, kann nicht allein aufgrund von .local auf einen echten IP-Leak geschlossen werden.
Behebung
Die aktuelle Private-Einstellung beibehalten, das Ergebnis notieren und zur Kreuzprüfung eine andere Testseite verwenden. In diesem Fall kann häufiges Wechseln des Proxys, zufälliges Anpassen der Fingerprints oder Neuerstellen der Umgebung stattdessen mehr Veränderungen in einer eigentlich stabilen Testumgebung verursachen.
MostLogin-Anwendungsbeispiel: Videokonferenz kann nach Deaktivierung von WebRTC keine Verbindung herstellen
Szenario
Das Remote-Support-Team hat WebRTC auf Disabled gesetzt, und danach können Web-Kundenservicegespräche und Bildschirmfreigaben keine Verbindung mehr herstellen.
Behebung
Die Umgebung auf Private umstellen, den Proxy normal verbunden lassen und dann die WebRTC-Adresse erneut testen. Wenn die echte IP nicht mehr erscheint und gleichzeitig Audio/Video wieder funktioniert, sind Funktionalität und Netzwerkisolierung vereinbar. Wenn im Private-Modus weiterhin ein Leak auftritt, sollten Proxy-Protokoll, IPv6, VPN-Splitting und Bypass-Domains überprüft werden, anstatt direkt auf Public zu wechseln, um die Anrufe wiederherzustellen.
Leak besteht weiterhin nach der Behebung – wo könnte das Problem liegen?
Wenn MostLogin auf Private eingestellt ist, aber der Test weiterhin die echte öffentliche IP anzeigt, können Sie die folgenden Punkte in dieser Reihenfolge überprüfen:
- Proxy ist tatsächlich nicht verbunden. Bei falschen Anmeldedaten, abgelaufenem Knoten oder offline Proxy-Server kann der Browser den erwarteten Ausgang nicht erhalten.
- IPv6 nicht abgedeckt. Der Proxy verarbeitet nur IPv4, der Host kann weiterhin über die echte IPv6 auf das Netzwerk zugreifen.
- Proxy-Bypass-Regeln. Die Testseite oder verwandte Subdomains sind auf Direktverbindung eingestellt.
- VPN-Splitting oder System-Routing-Konflikte. Die gleichzeitige Verwendung von VPN, System-Proxy und Umgebungs-Proxy kann unterschiedliche Netzwerkpfade erzeugen.
- Alter Umgebungsprozess läuft noch. Wenn die Umgebung nach dem Speichern der Einstellungen nicht vollständig geschlossen wurde, verwendet der alte Prozess weiterhin die ursprüngliche Konfiguration.
- Browser-Erweiterungen ändern das Netzwerkverhalten. VPN-, Proxy-, Datenschutz- oder WebRTC-Erweiterungen können mit den Umgebungseinstellungen in Konflikt geraten.
- Testseite Fehlinterpretation oder Cache. Verwenden Sie eine zweite Testseite und starten Sie die Umgebung neu zur Überprüfung, statt sich auf ein einzelnes Ergebnis zu verlassen.
Wenn zwei unabhängige Testseiten stabil dieselbe echte öffentliche Adresse anzeigen, speichern Sie Screenshots ohne sensible Anmeldedaten, die MostLogin-Versionsnummer, das Betriebssystem, das Proxy-Protokoll und die Reproduktionsschritte, und kontaktieren Sie dann den MostLogin-Support oder den Proxy-Anbieter.
WebRTC-Leak-Schutz-Checkliste
Führen Sie nach der ersten Verwendung jeder neuen Umgebung, nach Proxy-Wechsel, Client-Update oder Netzwerkwechsel die folgende Überprüfung durch:
Häufig gestellte Fragen
Bedeutet die Anzeige mehrerer IPs im WebRTC-Test unbedingt einen Leak?
Nicht unbedingt. Mehrere Ergebnisse können von IPv4, IPv6, LAN-Schnittstellen, STUN-Zuordnungen, TURN-Relays oder mDNS stammen. Nur wenn echte ISP-öffentliche IPs, nicht zugehörige Netzwerkausgänge oder öffentliche Adressen, die offensichtlich im Widerspruch zum Proxy-Standort stehen, erscheinen, sollte dies als Hochrisiko-Leak betrachtet werden.
Welche IP sollte WebRTC nach Verwendung eines Proxys anzeigen?
Im Idealfall sollte die Webseite Ihre echte ISP-öffentliche IP nicht sehen können. Abhängig von Browser- und Produktstrategie kann die Testseite die Proxy-Adresse, Relay-Adresse, versteckte lokale Kandidaten oder überhaupt keine verfügbare Adresse anzeigen. Das Kriterium ist nicht „es darf nur eine IP erscheinen", sondern „die echte öffentliche IP, die isoliert werden soll, darf nicht erscheinen".
Sollte ich in MostLogin Private oder Disabled wählen?
Wenn Web-Audio/Video, Kundenservicegespräche oder Bildschirmfreigaben erforderlich sind, wählen Sie bevorzugt Private und testen Sie erneut; wenn WebRTC-Funktionen überhaupt nicht verwendet werden, kann Disabled gewählt werden. Disabled kann Webseitenfunktionen beeinträchtigen und ist daher nicht für alle Umgebungen die optimale Standardlösung.
Kann ein WebRTC-Leak den echten Namen und die genaue Adresse preisgeben?
Normalerweise können allein anhand der IP weder der echte Name noch die genaue Wohnadresse ermittelt werden. Aber öffentliche IPs können ungefähre Regionen und Provider offenlegen und können mit Konten, Cookies, Browser-Fingerprints und Verhaltensaufzeichnungen kombiniert werden, um stärkere Zuordnungshinweise zu bilden.
Reicht es aus, nach einem aufgetretenen Leak nur die Einstellungen zu reparieren?
Die Reparatur kann nur weitere Offenlegungen verhindern, nicht aber die Daten zurückziehen, die die Webseite bereits erhalten hat. Für wichtige Geschäftsvorgänge sollte der Zeitraum des Leaks, die betroffenen Umgebungen und Login-Protokolle überprüft werden; gegebenenfalls alte Sitzungen beenden, Anmeldedaten aktualisieren und beobachten, ob auf der Plattform anomale Überprüfungen auftreten.
Fazit
Der Kern eines WebRTC-Leaks ist nicht „ob WebRTC aktiviert ist", sondern ob er echte öffentliche Adressen preisgibt, die nicht mit der aktuellen Proxy-Umgebung übereinstimmen. Nach der Entdeckung von Anomalien sollten zunächst empfindliche Vorgänge pausiert und dann ein Vergleich mit den drei Datensätzen – echte IP, Proxy-IP und WebRTC-IP – durchgeführt werden. MostLogin-Benutzer können das Problem in der Regel lösen, indem sie die Proxy-Verbindung überprüfen, WebRTC auf Private setzen, den Proxy-Fehlerschutz aktivieren, unnötige Proxy-Bypass-Regeln bereinigen und den IPv6-Pfad überprüfen.
Die WebRTC-Überprüfung in den festen Prozess vor dem Start einer neuen Umgebung aufzunehmen, ist zuverlässiger als das Beheben von Problemen, nachdem Kontoanomalien aufgetreten sind. Nur durch erneutes Testen nach jedem Proxy-, Netzwerk- oder Client-Versionswechsel kann sichergestellt werden, dass der Netzwerkausgang und der Browser-Fingerprint langfristig konsistent bleiben.
