1 Punkte von GN⁺ 2023-08-09 | 1 Kommentare | Auf WhatsApp teilen
  • Auf einer für die Arbeit benötigten GitLab-Seite blieb Cloudflares Browser Integrity Check in einer „secure connection loop“ hängen; danach wurde auch der Zugriff per Firefox auf eine separate interne Website blockiert.
  • Das Problem beim GitLab-Zugriff ließ sich durch Ändern von privacy.resistFingerprinting in Firefox beheben, doch am nächsten Tag erschien auf einer nicht damit zusammenhängenden internen Website eine Blockierungsseite, und auch das Zurücksetzen des Werts half nicht.
  • Unter denselben Bedingungen – gleiches Arbeitsgerät, Firmen-VPN und Sicherheitszertifikat – war Chrome erreichbar, während nur Firefox blockiert wurde; daraus ergibt sich die Vermutung, dass die Sperrentscheidung mit dem Browser-Fingerprint oder dem Fehlen eines solchen zusammenhing.
  • Für interne Arbeitsseiten muss vorerst Chrome verwendet werden, und wie viele weitere interne oder externe Websites, die durch Cloudflare „geschützt“ werden, betroffen sein könnten, ist für Nutzer schwer absehbar.
  • Wenn Entwicklungen wie Remote Attestation, Web Integrity API und Passkeys Unternehmen noch mehr Macht geben, könnten Einzelpersonen die Wahlfreiheit bei Hardware, Betriebssystem und Software verlieren und sich an unsichtbare Regeln anpassen müssen.

Cloudflares secure connection loop

  • Cloudflare stellt für große Teile des Internets Content-Delivery-Networks, Schutz vor Distributed-Denial-of-Service-Angriffen und weitere Netzwerk-Infrastrukturdienste bereit.
  • Viele Websites, die Cloudflare nutzen, schalten vor dem Zugriff einen Browser Integrity Check vor.
    • Ziel ist es, böswillige Akteure, Bots und unerwünschten Traffic abzuwehren und sicherzustellen, dass echte Menschen die Website wie vorgesehen nutzen.
    • Auch legitime Nutzer mit guten Absichten können auf dieser Sicherheitsseite hängen bleiben.
  • Eine secure connection loop bedeutet, dass Cloudflare nach Eingabe einer URL die Anfrage abfängt und die Seite „Checking if the site connection is secure“ anzeigt, der Check aber nie abgeschlossen wird.
    • Die Ladeanzeige dreht sich endlos weiter, oder nach einer erneuten Mensch-Verifikation wird die Seite immer wieder aktualisiert.
    • Selbst wenn Nutzer die verlangten Schritte ausführen, werden sie erneut dazu aufgefordert und kommen nicht weiter.
  • Sucht man nach „Cloudflare checking if the site connection is secure“, findet man neben der offiziellen Cloudflare-Dokumentation zahlreiche Fragen von Nutzern, die diese Seite umgehen wollen; das Problem scheint also recht häufig zu sein.

Problem beim GitLab-Zugriff und Änderung der Firefox-Einstellung

  • Als auf einem Arbeitsrechner zur Überprüfung wissenschaftlicher Software auf GitLab zugegriffen wurde, erschien Cloudflares Browser-Integrity-Check-Seite.
  • Das Prüfen von Fehlern in der Entwicklerkonsole, das vorübergehende Deaktivieren von Erweiterungen, ein privates Fenster und ein Neustart des Computers halfen nicht, aus der Schleife herauszukommen.
  • In den Suchergebnissen fand sich der Vorschlag, in Firefox unter about:config die Option privacy.resistFingerprinting zu deaktivieren.
    • Zu diesem Zeitpunkt stand der Wert bereits auf false.
    • Nachdem der Wert auf true gesetzt wurde, wurde der Browser Integrity Check bestanden und der Zugriff auf die gewünschte Software war möglich.

Sperre auf einer nicht zusammenhängenden internen Website

  • Am nächsten Tag erschien beim Zugriff auf eine für die Arbeit benötigte interne Webseite eine Blockierungsseite.
  • Im Ablauf wurde zunächst die Cloudflare-Prüfschleife nicht bestanden; nachdem zur Umgehung davon eine datenschutzbezogene Firefox-Einstellung geändert worden war, erfolgte die Sperre auf einer anderen Arbeitswebsite.
  • Der gesamte Vorgang fand auf einem Arbeitsgerät hinter dem Firmen-VPN statt.
    • Der Zugriff auf dieses VPN setzt voraus, dass ein bestimmtes Sicherheitszertifikat auf dem Gerät installiert ist.
    • Da Cloudflare dieses Zertifikat angefordert hatte, wird davon ausgegangen, dass Cloudflare von dessen Existenz wusste.
  • Als starke Daten zur Identitätsprüfung kamen ein nutzerbezogenes Sicherheitszertifikat und die IP-Adresse des Firmen-VPNs infrage.
    • Im Original wurde zunächst die MAC-Adresse erwähnt, in einer Fußnote aber korrigiert, dass Cloudflare wahrscheinlich nicht die MAC-Adresse, sondern nur die IP-Adresse hinter dem Firmen-VPN sehen konnte.
  • Es wurden keine zusätzlichen Erweiterungen installiert, kein Headless Browser verwendet, kein User-Agent geändert und weder Tor noch ein nicht standardmäßiges Protokoll genutzt; geändert wurde nur eine datenschutzbezogene Browsereinstellung.
  • Auch nachdem die Einstellung auf den ursprünglichen Wert zurückgesetzt wurde, blieb die Sperre bestehen, wodurch der Zugriff auf für die Arbeit nötige Ressourcen unsicher wurde.

Vermutete Ursache der Sperre und Vergleich mit Chrome

  • Wegen der secure connection loop stellte der Browser in kurzer Zeit mehrfach Anfragen an dieselbe Seite; Cloudflare könnte diese hohe Frequenz von Anfragen und Ablehnungen als verdächtiges Muster erkannt haben.
    • Das ist keine gesicherte Ursache, sondern eine mögliche Erklärung.
    • Danach könnte die erste Anfrage trotz Fingerprinting-Schutz durchgegangen sein, Cloudflare aber die gesamte Abfolge als bösartiges Verhalten interpretiert und den Browser als verdächtig markiert haben.
  • Beim Zugriff auf die interne Website mit Google Chrome trat keine Sperre auf.
  • Dass nur Firefox blockiert wurde, Chrome jedoch nicht, führt zu der Einschätzung, dass Cloudflares Sperre auf dem Browser-Fingerprint oder dem Fehlen eines solchen basiert.
    • Beide Anfragen erfolgten mit demselben Sicherheitszertifikat, demselben Firmen-VPN, demselben Gerät und zur selben Zeit.
    • Der einzige Unterschied war der verwendete Browser.
  • Chrome verfügt nach dieser Einschätzung nicht über dieselbe Auslegung von Datenschutz- und Sicherheits-Härtung wie Firefox und wehrt Fingerprinting nicht in vergleichbarem Maß ab beziehungsweise verlangt keine entsprechende Konfigurationsänderung.

Auswirkungen auf die Arbeit

  • In nächster Zeit muss für den Zugriff auf interne Arbeitsseiten Chrome verwendet werden.
  • Es ist unklar, wie viele weitere interne oder externe Websites, die durch Cloudflare „geschützt“ werden, noch blockiert sein könnten.
  • Eine Neuinstallation von Firefox wäre zwar einen Versuch wert, doch weil bereits spekulative Gegenmaßnahmen die Situation verschlimmert haben, ist unklar, welcher nächste Schritt sinnvoll ist.
  • Da es kein klares Verfahren gibt, das Nutzer selbst durchführen können, könnte es nötig werden, im internen Verzeichnis den zuständigen Systemadministrator für diese Seite zu finden und um Freischaltung zu bitten.

Sorge um das Web insgesamt

  • Dass selbst bei starken Identitätsnachweisen schon eine kleine Abweichung vom erwarteten Verhalten den Zugang zu notwendigen Ressourcen verhindern kann, nährt Sorgen über die Zukunft des Webs.
  • Wenn Remote Attestation und andere „Sicherheits“-Maßnahmen auf Bereiche wie Online-Banking ausgeweitet werden, könnte das fast alle Bereiche des Privatlebens betreffen.
  • Nutzer eines de-Googled Android müssen oft erheblichen Aufwand betreiben, damit Hardware-Attestation für die Nutzung von Banking-Apps korrekt funktioniert.
    • Der Attestation Compatibility Guide von GrapheneOS ist ein solches Beispiel.
    • Es wird bemängelt, dass es kaum einen Mittelweg gibt zwischen dem Zugriff auf Geld über das eigene Gerät und dem Zulassen, dass Google die Geräteinteraktion überwacht.
  • Web-Vorschläge, die Unternehmen mehr Macht geben als Einzelpersonen, obwohl diese schwerer zur Verantwortung zu ziehen sind, könnten Situationen vermehren, in denen Nutzer orientierungslos unsichtbaren Regeln folgen müssen.
  • Erst in den letzten Jahren wurden Unternehmen bei Verstößen gegen Datenschutzgesetze überhaupt spürbar sanktioniert; ein Beispiel ist die Strafe von 1,2 Milliarden Euro gegen Facebook wegen GDPR-Verstößen.

Fragen, die Web Integrity API und Passkeys aufwerfen

  • Der Vorschlag zur Web Integrity API löste Widerstand gegen die denkbare Zukunft des Webs aus.
    • Wenn Finanzunternehmen auf Websites Remote-Attestation-Richtlinien einführen, könnten die Arten von Hardware, Betriebssystemen und Software, die Einzelpersonen verwenden dürfen, weiter eingeschränkt werden.
    • Es mag legitime Gründe geben, alte und nicht patchbare verwundbare Geräte auszuschließen, doch Unternehmensentscheidungen könnten zulasten individueller Freiheit oder Rechte vor allem die Kontrolle der Unternehmen ausweiten.
  • Das erste Beispiel im Web-Integrity-API-Vorschlag betrifft eine werbefinanzierte Website, auf der Werbekunden dafür zahlen können sollen, dass ihre Anzeigen von Menschen statt von Bots gesehen werden.
    • Dadurch müssten letztlich echte Nutzer die Last tragen, zu beweisen, dass sie Menschen sind.
    • Auch die Tatsache, dass der Verfasser des Vorschlags zu Google gehört, dessen Werbeumsätze immens sind, wird kritisch gesehen.
  • Die Einführung von Passkeys kann ein nützlicher Ansatz für sichereren und einfacheren Website-Zugang sein.
    • Wenn jedoch, wie in der Cloudflare-Erfahrung, selbst starke Identitätsnachweise ignoriert werden können, ist schwer abzusehen, wie Passkeys von Dienstanbietern wie Cloudflare behandelt würden.
  • Bei Passkeys bleiben mehrere praktische Fragen offen.
    • Können Nutzer Passkeys selbst erstellen und synchronisieren?
    • Wenn nur bestimmte Software Passkeys verwenden darf, wer legt diese Kriterien fest?
    • Sind bestimmte Hardware- oder Softwareanforderungen nötig, etwa TPM, DeviceCheck oder die Integrity API?
    • Lassen sich Passkeys jederzeit von einem Dienstanbieter exportieren und zu einem anderen übertragen?
    • Wenn ein Passkey mit einem verdächtigen Vorfall verknüpft wird, überträgt sich diese Markierung auf andere Geräte, die denselben Passkey verwenden?
    • Werden auch Geräte, die verdächtige Passkeys enthalten, als verdächtig markiert, und beeinflusst das dann sogar den Zugriff dieses Geräts auf andere, unabhängige Websites?
  • Passwörter haben viele Nachteile, aber sie haben den Vorteil, dass Einzelpersonen sie selbst erstellen, auf ihren eigenen Geräten erzeugen und nach Wunsch verwalten können.
  • Selbst wenn Technologien wie VPN, Zertifikate und Fingerprinting Schwächen von Passwörtern und der Computersicherheit ausgleichen sollen, ist ihr Nutzen begrenzt, wenn man für grundlegende Aufgaben den Datenschutz aufgeben muss und trotzdem blockiert werden kann.

1 Kommentare

 
GN⁺ 2023-08-09
Meinungen auf Hacker News
  • Viele Menschen, die sagen, ihnen sei Datenschutz wichtig, nutzen Chrome und wissen das oft nicht.
    Eine Seite, die in Firefox blockiert wurde, ließ sich in Chrome öffnen; Chrome ist jedoch nicht wie Firefox auf stärkeren Datenschutz und mehr Sicherheit ausgelegt, sammelt und teilt mehr Browserverlauf und persönliche Daten und ist auch weniger widerstandsfähig gegen Fingerprinting.
    Wenn es dasselbe Zertifikat, dasselbe Firmen-VPN, dasselbe Gerät und dieselbe Uhrzeit waren und man nur durch einen Browserwechsel durchkam, wirkt es so, als würde Cloudflare anhand des Fingerprints oder dessen Fehlens blockieren.
    Wer sich heutzutage auch nur ein bisschen darum kümmert, sollte Chrome nicht verwenden.

    • Ich bin kein Google-Fan, aber die Logik „Chrome kam durch, weil es mehr Informationen preisgegeben hat“ ist wenig überzeugend.
      In dieser Situation ist nicht klar, welche Informationen Chrome im Gegensatz zu Firefox bereitgestellt hat; es könnte auch einfach sein, dass Firefox als seltenerer User-Agent strenger gefiltert wurde.
      Ich habe schon gesehen, dass beim Wechsel des Browsers auf einer Website eine Rate-Limit-Meldung verschwindet; mit den begrenzten Informationen könnte die Annahme gleiche IP + anderer User-Agent = anderer Computer gewesen sein.
      Man müsste mindestens auch mit einem dritten Browser testen.
    • Heuristiken, die sogenannte „Bots“ von „Menschen“ unterscheiden sollen, sind ungeeignet, solange Menschen fälschlich als Bots eingestuft und blockiert werden.
      „Nimm Chrome“ ist keine Lösung, und Menschen, die Firefox oder andere Nicht-Google-Software verwenden, sind trotzdem Menschen.
      Der Ansatz, per JavaScript zu prüfen, dass man „kein Bot“ ist, wirkt wie ein Mittel, Nutzer dazu zu zwingen, JavaScript zu aktivieren und sich mehr Werbeeinblendungen auszusetzen.
    • Es ist leicht zu sagen, man solle Chrome nicht nutzen, aber sehr viel schwieriger zu sagen, man solle Cloudflare nicht nutzen.
      Wenn das Kriterium ist, einen Markt zu monopolisieren und die Zukunft des offenen Internets zu bedrohen, ist Cloudflare die größere Bedrohung; sobald sich die Cloudflare-Diktatur weniger wohlwollend verhält, werden es alle zu spüren bekommen.
    • Wer sich heutzutage auch nur ein bisschen darum kümmert, sollte neben Chrome auch Cloudflare nicht verwenden.
    • Dass „datenschutzbewusste Menschen häufig Chrome nutzen“, höre ich zum ersten Mal.
  • Ich bin PM für Cloudflares Challenge-Plattform und würde gern die Ursache des Problems prüfen.
    Wir bestrafen Nutzer nicht allein wegen wiederholter Aktionen, daher würde ein Browser dadurch nicht als verdächtig markiert.
    Ich persönlich nutze häufig Firefox, habe dieses Verhalten aber nicht beobachtet; wenn es ein allgemeines Firefox-Problem wäre, hätten automatische Alarme ausgelöst und wir hätten es als schwerwiegenden Vorfall behandelt.
    Wenn du an der Fehlersuche interessiert bist, kannst du mir unter amartinetti at cloudflare eine E-Mail schicken.

    • Die Ursache des Problems ist, dass die Software konstruktionsbedingt fehlerhaft ist.
      IP-Adressen sind zum Routing von Paketen da, nicht dafür, Nutzern im Hintergrund einen „Verhaltensscore“ zuzuweisen. Meine IP könnte gestern die IP einer völlig anderen Person gewesen sein.
      Per TLS-Signatur zu entscheiden, wer auf die Hälfte des Webs zugreifen darf, löst langfristig gar nichts, stärkt Browser-Monopole und widerspricht dem Geist des offenen Webs frontal.
      Ich habe mir das bis zu einem gewissen Grad selbst zuzuschreiben, weil ich als Hobbyprojekt Bots wie Crawler betreibe, aber wenn ich nur die TLS-Signatur von Chrome nachahme, funktioniert es weiterhin. Auch Freunde ohne technisches Wissen, die überhaupt nichts getan haben, sind in diese Sperre geraten.
      Cloudflares Dienst hat sehr wahrscheinlich Millionen Menschen geschadet, indem sie eines Tages plötzlich von der Hälfte des WWW ausgesperrt wurden; solche Schäden sind die logische Folge von Heuristiken, die darüber entscheiden, ob man auf Websites zugreifen darf.
      Es ist auch lächerlich, dass ein einzelnes Unternehmen außerhalb meines Landes darüber entscheidet, ob ich das Web nutzen kann, und nun muss ich mich nach zwielichtigen Orten umsehen, um Proxys zu kaufen, damit ich Firefox weiter nutzen kann.
    • Ich nutze Firefox und sehe in letzter Zeit häufiger Cloudflares vorgeschaltete Seite „Prüfen, ob Sie ein Mensch sind“.
      Normalerweise ist sie automatisch erledigt und keine große Sache, aber letzte Woche habe ich die höhere Häufigkeit gespürt.
    • Ich nutze Firefox, habe aber nicht bemerkt, dass ich häufiger CAPTCHAs lösen müsste, und die Seite „connection secure“ sehe ich auch fast nie.
      Vielleicht liegt es an der verwendeten Privacy Pass-Erweiterung; ich weiß allerdings nicht genau, was sie tatsächlich macht.
    • Mein üblicher IP-Proxy bekam Probleme, nachdem sich durch einen Eigentümerwechsel des Rechenzentrums die Zuordnung von ARIN zu RIPE geändert hatte.
      Der tatsächliche Standort ist weiterhin NYC, aber beim Zugriff auf US-Websites mit Cloudflare-Schutz sehe ich aus, als käme ich aus Großbritannien, und immer mehr Stellen wie Lokalzeitungen, Lebensmittelgeschäfte und Kreditkartenanbieter blockieren mich.
      Cloudflares IPv6-Geolokationsdaten sind kaputt, und selbst bei Zugriff über IPv4 scheint es dazwischenzufunken. Geolokationsbasierte Entscheidungen sind von vornherein keine gute Idee.
    • Wenn ich meinen Traffic über ProtonVPN route, sehe ich dieses Phänomen in Firefox.
      Es könnte daran liegen, dass andere Nutzer des VPN sich schlecht verhalten haben, aber es scheint eher mehr dahinterzustecken.
  • Ich hatte eine Zeit lang genau dasselbe Problem und konnte in meinem Browserverlauf nach „just a moment“ suchen, um die Websites zu finden, auf die ich nicht zugreifen konnte
    https://gitlab.com/users/sign_in, https://steamdb.info/login/, https://www.zabbix.com/forum/, https://casetext.com/, https://namemc.com/login, https://spinroot.com/, https://camelcamelcamel.com/
    Das Problem besteht seit Monaten, vielleicht seit Jahren, und Cloudflare scheint es nicht zu beheben; es fühlt sich an, als würde man das offene Web hassen und die Dominanz von Chrome/Chromium/Blink erzwingen wollen

    • Wenn du die rayID teilen kannst, die bei solchen wiederholten Challenges angezeigt wird, würde ich sie mir gern ansehen
      Die rayID enthält keine personenbezogenen Daten, du kannst sie also öffentlich posten oder eine Mail an amartinetti at cloudflare schicken
      Wir werden außerdem bald einen Meldemechanismus ausrollen, damit solche Probleme künftig schnell gemeldet und behoben werden können
    • Ich erlebe das auch ständig; es geht seit Jahren so und wird mit der Zeit spürbar schlimmer
      Um das Web zu nutzen, muss man auf die eine oder andere Weise einen Preis zahlen: Entweder verliert man wegen strenger Datenschutzeinstellungen den Zugriff, oder man gibt Privatsphäre preis. Man kann nicht gewinnen
    • In Waterfox hatte ich keine Probleme, aber es ist absurd, dass man inzwischen JavaScript braucht, nur um eine Website zu besuchen
    • GitLab hat mir wegen Cloudflare ebenfalls den Login verweigert, sogar als ich zahlender Kunde war
      Aus anderen Gründen zahle ich inzwischen nicht mehr, aber im Nachhinein fühlt es sich jedenfalls richtig an, damit aufgehört zu haben
    • Die Nutzer scheinen die Chrome-Dominanz zu wollen und sich nicht um das offene Web oder Firefox zu kümmern
      Es ist der führende Desktop-Browser, obwohl er in keinem Betriebssystem standardmäßig enthalten ist; Windows hat Edge und Mac hat Safari, und trotzdem laden Nutzer Chrome selbst herunter
  • Wenn ein großer Teil des Internet-Traffics von einer einzigen Quelle kontrolliert wird, folgen solche Probleme zwangsläufig
    Wenn Cloudflare willkürlich entscheidet, wer das Internet nutzen darf, wird das faktisch zum Gesetz
    Anfangs beginnt es mit einer naiven Prämisse wie „eine einfache Möglichkeit, schlechte Akteure zu blockieren“, weitet sich aber am Ende auf willkürliche Kriterien aus
    Wenn man Datenschutz verteidigen will, muss man auch schlechte Leute zulassen, aber der durchschnittliche Internetnutzer versteht diese Nuance nicht
    Selbst im harmlosesten Fall kann ein einziger fehlerhafter Commit das Internet lahmlegen, und genau so etwas ist bei Cloudflare schon passiert
    Wegen Unternehmen wie Cloudflare, Google und Meta gibt es Kartellgesetze, aber es scheint niemanden mit der nötigen Befugnis zu geben, der sie ernsthaft anwenden will. In 20 Jahren wird das Internet völlig anders aussehen als alles, was wir bisher gesehen haben, und vermutlich nicht zum Besseren

    • Du bist kein zahlender Kunde von Cloudflare; die Kunden sind die Websites, die für den Schutz ihrer Infrastruktur bezahlen
      Diese Kunden können unter mehreren CDN-/WAF-Anbietern wählen, und Cloudflare ist nicht einmal der größte Anbieter; Akamai ist größer
      Das am schnellsten wachsende CDN ist CloudFront, und der Wettbewerb scheint gesund zu sein. Ich verstehe daher nicht, warum Kartellrecht greifen sollte
    • Alle vergessen, dass Websites durch Crawler und Bots nahezu unbenutzbar werden können
      Website-Betreiber entscheiden sich für Cloudflare, um das zu verhindern; Cloudflare erzwingt das nicht
    • Das heutige Internet ist auch völlig anders als das Internet vor 20 Jahren
    • Cloudflare scheint bei Weitem keinen Marktanteil zu haben, der kartellrechtliche Bedenken auslösen würde
    • Von Kartellrecht zu sprechen ergibt nur dann Sinn, wenn Cloudflare den Wechsel zu einem Wettbewerber verhindert
  • Wenn man Cloudflares verschiedene Session-Cookies, die „Rubber-Integrity“-Seiten oder die per Man-in-the-Middle eingefügten Skripte aus dem „Super Bot Fight“-Modus auseinandernimmt, erkennt man, dass im Grunde heuristisch per Web Worker eine Browser-Integritätsprüfung durchgeführt wird
    Es wird also eine Reihe von Tests ausgeführt, die ein echter, von einem Nutzer bedienter Browser besteht, während ein von einem Bot gesteuerter Headless-Browser scheitert
    Zum Beispiel wird ein Bild auf ein Canvas gezeichnet, als PNG exportiert und der Hash verglichen, um zu prüfen, ob es sich um einen echten Browser oder nur einen rohen HTML-Parser handelt; oder es wird nach ungewöhnlichen Schriftarten von Consumer-Betriebssystemen gesucht, die leicht fehlen, wenn man Puppeteer in den Standard-Containern von Lambda/Cloud Functions ausführt
    Noch weitergehend wird etwa geprüft, ob überflüssige Mausbewegungen und Tastatureingaben vor Aktivierung des Prompts wie menschliche Fehler wirken und ob sie nicht aktuellen Mustern aus aufgezeichneten Wiedergaben ähneln
    Wenn man in der Verifizierungsschleife landet, liegt das daran, dass Browser, Gerät oder Erweiterungen diese Heuristiken so weit verschleiern oder deaktivieren, dass Cloudflare keinen eindeutigen Nachweis erhält, dass man ein Mensch ist; je nach Einstellung des Website-Betreibers versucht es dann weiter, Beweise zu sammeln, statt einen Fehlschlag zu melden
    Denn einem Bot mitzuteilen, dass er gescheitert ist, wäre im Grunde ein Signal: „Hör mit dem auf, was nicht funktioniert, und ändere die Schildfrequenz.“

    • Aus Nutzersicht sieht es einfach so aus, als wäre die Website kaputt
      Keine Konsolen-Exception, nur dieselbe Seite, die immer wieder neu lädt
    • Wenn ein Bot zehn Minuten lang in einer Cloudflare-Schleife festhängt, ist das meiner Ansicht nach ein ziemlich starkes Signal, dass etwas nicht funktioniert
    • Dann weiß ich nicht, wie man Blockierungen auf weniger verbreiteten Browsern oder weniger verbreiteten Plattformen erklären soll
  • Was gelegentlich übersehen wird: Der Betreiber einer Website, die Cloudflare nutzt, legt global fest, wie paranoid er vorgehen will, und kann zusätzlich sehr feingranulare und aggressive WAF-Regeln erstellen
    In manchen Fällen hat also der Website-Betreiber übertrieben aggressive Regeln gesetzt, aber Cloudflare bekommt den Ärger ab. Für Endnutzer sieht das Ergebnis meist gleich aus
    Ich hatte einmal eine WAF-Regel erstellt, die sämtlichen ungeprüften Bot-Traffic aus großen Rechenzentren wie Google Cloud, OVH und DigitalOcean blockierte; das war ein Fehler, weil viele Unternehmen aus irgendeinem Grund ihren Traffic über diese ASNs routen
    Diese Nutzer waren vermutlich wütend auf Cloudflare, aber die eigentliche Ursache war meine falsche Konfiguration

  • Im Programmierunterricht verwenden wir als Beispiel einen einfachen Browser. Er verarbeitet weder CSS noch JavaScript, daher ist die Darstellung primitiv, aber er funktioniert
    Auf manchen Websites klappt das, aber gerade große Sites erkennen ihn als unbekannten Browser und verweigern die Auslieferung von Inhalten. Vermutlich halten sie ihn für einen Bot
    Selbst wenn es ein Bot wäre: Solange er sich höflich verhält, sehe ich nicht, wo das Problem liegt, und frage mich, was für ein geschlossenes Web wir den Großkonzernen da zu bauen erlauben

    • Eine Website kann selbst entscheiden, ob sie auf eine Anfrage antwortet
      Sie ist nicht verpflichtet, allen einen Dienst anzubieten
    • Um einmal den Advocatus Diaboli zu spielen: Warum sollte ein Server nicht entscheiden dürfen, mit welchen Clients er spricht?
  • Es nervt auch, dass Cloudflares Prüfseite das Neuladen von Seiten in Firefox kaputtmacht
    Wenn Cloudflare zur ursprünglichen Seite zurückleitet, führt das zu einem POST. Der erste POST wird von Cloudflare abgefangen, aber wenn man die Seite neu lädt, geht dieser POST an die eigentliche Seite, die dann wahrscheinlich nicht weiß, was sie damit anfangen soll, und einen Fehler anzeigt
    Die einzige Lösung ist, in der Adressleiste Enter zu drücken, um statt eines Reloads erneut zu navigieren, oder einen Link zurück zu dieser Seite zu finden
    Ich wäre nicht überrascht, wenn man wegen solcher POSTs auf manchen Sites gesperrt wird. Sie könnten urteilen: „Du weißt, dass du an diese Seite kein POST schicken sollst, hast es aber trotzdem getan, also bist du ein bösartiger Bot, der hacken will“

  • Es ist absurd, wie oft Cloudflare einen diese 15- bis 30-sekündige Seite „checking your connection“ sehen lässt
    Für jemanden wie mich, der mit ADHS lebt, können solche Verzögerungen und Unterbrechungen, die sich über den Tag aufsummieren, erhebliche Auswirkungen haben
    Selbst wenn ich meine Medikamente richtig nehme, macht diese Maßnahme einen wirklich hilflos und die Online-Erfahrung furchtbar und zermürbend

    • Normalerweise aktiviert man so etwas bei Sites, die unter einem heftigen DDoS-Angriff stehen
      Niemand möchte Nutzern das zeigen, aber manchmal bleibt einem nichts anderes übrig
    • Das kommt nicht von Cloudflare selbst; der Kunde, der Cloudflare nutzt, hat es so konfiguriert
    • Cloudflares Privacy Pass kann helfen: https://privacypass.github.io/
      Er sollte die Zahl der CAPTCHAs, die man zu sehen bekommt, deutlich reduzieren, ohne die Privatsphäre allzu stark zu beeinträchtigen
      In Safari kann man Private Access Tokens aktivieren: https://blog.cloudflare.com/how-to-enable-private-access-tok...
      Beide Ansätze ähneln Googles Web-DRM-Vorschlag insofern, als ein externer Aussteller Tokens erzeugt; anders als Googles Versuch garantieren sie der Seite, die das Token nutzen will, aber nicht, dass der Adblocker deaktiviert ist
  • Erst gestern habe ich festgestellt, dass der PayPal-Login mit Safari oder Firefox nicht funktioniert, sondern nur mit Chromium-basierten Browsern
    Wir geraten immer tiefer in die Ära „Diese Website ist für Google Chrome optimiert“

    • Bei Twitch gibt es dieses Problem ebenfalls
      Wenn in Firefox der Schutz vor Fingerprinting aktiviert ist, kann man sich nicht einloggen, und offenbar reicht Zwei-Faktor-Authentifizierung allein nicht aus, um das Konto zu schützen
      Wenn ich Twitch nicht erlaube, meinen Computer eindeutig zu identifizieren, lassen sie mich nicht einloggen; also habe ich einfach aufgehört, Twitch-Streams anzusehen
    • Das PayPal-Problem habe ich schon seit einiger Zeit
      Es trat bei Firefox unter Windows, Linux und Android auf. Zum Glück bin ich in der App noch eingeloggt, aber weil ich mit Firefox nicht zu PayPal komme, habe ich schon einmal trotz vorhandenen PayPal-Guthabens mit Kreditkarte bezahlt