Nutzer-Tracking standardmäßig ohne Opt-Out?

    Nicht wirklich. Webseiten setzen heute auch auf Flexbox und Grids, obwohl doch auch Tabellen als Layout-Werkzeug missbraucht werden könnten, was von noch mehr Browsern unterstützt wird. Webstandards, welche von jedem modernen Browser unterstützt werden, werden in der Praxis benutzt. Das ist so. Sobald es die Browser-Abdeckung des Hyperlink Auditings zulässt, wird auch das mehr Verwendung finden. Firefox ist der letzte Browser von Bedeutung, der das deaktiviert hat.

    Dass Erweiterungen Dinge blockieren können, ist kein Argument für einen Entwickler. Als Entwickler oder auch Datenanalyst weiß man, dass die erhobenen Daten nicht 100 Prozent der Nutzer abbilden. Es gibt immer Nutzer, die Dinge blockieren, auch JavaScript oder Werbung. Und trotzdem gibt es beides auf den meisten Webseiten. Und wenn man Daten von nur 99 Prozent der Nutzer hat, selbst bei nur 60 Prozent der Nutzer, dann sind Daten wie welcher Link geklickt wird, immer noch ziemlich repräsentativ.

    Zitat von Sören Hentzschel


    Firefox ist der letzte Browser von Bedeutung, der das deaktiviert hat.

    Genau hier verstehe ich die ganze Diskussion über dieses Thema nicht mehr! Bei den anderen "großen" Browsern ist es doch eh schon Standard, aber wieder wollen nun einige vom Firefox weg. Also mir ist es lieber, daß eine Organisation das öffentlich macht wie eben jetzt Mozilla und nicht hintenrum und heimlich wie Google, Microsoft und Apple. Wenn ich mir da so einige Kommentare in manchen "IT-Foren" (z. B. Heise) dazu ansehe, dann könnte ich mich beinahe schon einpi*** vor lachen ob der Dummheit!

    Zitat von popcorn


    ... bau ich doch gleich noch die alternativen Methoden zur Erfassung ein.


    Welches sind denn hier konkret die anderen Methoden und warum lassen sich diese nicht ohne Weiteres in den Griff bekommen? Bislang lese ich dazu nur Behauptungen / Thesen, aber keine Details. :-???

    Mit Behauptungen kannst du meine Beiträge nicht meinen, zumal ich es bereits in einfachsten Worten erklärt habe… Ich kann es aber gerne detaillierter ausführen:

    Was ist denn ein Ping? Ein Ping ist nichts anderes als eine Anfrage an einen Server. Einen Event-Listener auf einen Link setzen (oder alternativ einen Trigger im Tag Manager anlegen) und darin dann einen XMLHttpRequest an einen Server senden, den Code dafür hab ich in 30 Sekunden geschrieben. XMLHttpRequests erfolgen aus den verschiedensten Gründen auf zig Millionen Webseiten. Nicht einmal unbedingt in der Funktion als Ping, aber grundsätzlich kann jede beliebige Anfrage gleichzeitig als Ping verstanden werden, wenn der Empfänger es denn so will. Denn letztlich geht es ja nur darum, dass die Webseite weiß, dass ein Link angeklickt worden ist.

    Das kannst du nicht unterbinden, ohne sämtliche XMLHttpRequests oder gar JavaScript komplett zu deaktivieren. Und die damit verbundenen Auswirkungen gehen weit darüber hinaus, nur Pings zu deaktivieren. Eine Unterscheidung auf technischer Ebene, ob eine solche Anfrage vom Empfänger als Ping verwendet wird oder nicht, ist logischerweise nicht möglich. Du kannst vielleicht feststellen, ob eine Anfrage an einen Server gesendet wird. Du weißt aber nicht, ob die Anfrage nur dem Zweck dient, Daten nachzuladen, ein Formular abzusenden oder was auch immer, oder ob das nicht gleichzeitig auch in die Analyse mit einfließt. Also müsste man XMLHttpRequests oder komplett JavaScript schon, um Pings zu unterbinden, vollständig und ohne Kompromisse blockieren, mit all seinen Auswirkungen.

    Das Schöne am ping-Attribut, um welches es hier geht, ist die Tatsache, dass es einen klar definierten Zweck hat und daher durch eine Erweiterung ganz gezielt ausgeschaltet werden kann, ohne sonst irgendwelche unerwünschten Nebenwirkungen zu verursachen. Wird nur der Ping blockiert, hat das null Auswirkungen auf die sonstige Funktionalität von Webseiten, was auf anderem Weg so nicht gewährleistet werden könnte. Das ist also auch für den Endnutzer viel zielführender, wenn das verwendet wird - vor allem für den Nutzer, der das unterbinden möchte. Aber ich wiederhole mich, das habe ich ja nun schon ein paar Mal geschrieben.

    Zitat von Thor Branke


    Welches sind denn hier konkret die anderen Methoden und warum lassen sich diese nicht ohne Weiteres in den Griff bekommen? Bislang lese ich dazu nur Behauptungen / Thesen, aber keine Details. :-???

    Zitat von https://heise.de/-4404235

    Verbreitet ist es, einen Link auf den Tracking-Dienst zu setzen und den ursprünglichen Link als GET-Paramter in der URL zu übergeben. Nachdem der Klick gezählt wurde, bekommt der Browser per HTML-Header 301 oder 302 die Anweisung, zum eigentlichen Ziel umzuleiten. Dieses Verfahren dauert für den Besucher etwas länger. Google nutzt dieses Verfahren zum Beispiel bei seinen Suchergebnissen. Wer den Link herauskopiert und weiterleitet, bekommt eine unnötig lange Zeichenkette. Für Laien ist nicht zu erkennen, auf welche Seite der Link zeigt:
    Google leitet Links auf externe Seite über den eigenen Tracking-Dienst um. Kopiert man den Link heraus, muss man genau hinsehen, wohin er führt.

    Alternativ kann der Entwickler ganz auf einen klassischen Link verzichten, stattdessen per JavaScript auf das Klick-Ereignis reagieren, per HTTP-Aufruf den Klick registrieren und die gewünschte Seite öffnen.

    Y: "All your data will be safe. It will be just between me and you. Oh and this company over here who's gonna make sure it's gonna be safe."
    Me: "I think just me and you was safer."

    Zitat

    Ein Kandidat zur Behebung dieser ... Maßnahme: Simple Ping Blocker.


    Dummenfänger, Firefox kann ping selbst reglementieren. ein/aus, origin, self, sind drei Optionen in den prefs. Ab Firefox 67 oder 68. Bei älteren Firefox ist das nicht relevant, da ist es per Standard eh aus.

    Wir sind keine Beschwerdestelle, hier gibt es nur Lösungen! Meine Glückszahl hier: 93.

    Zitat von .DeJaVu

    Mozilla hat sich letzte Woche dazu geäußert - etwas vage, aber enthält doch die Hoffnung, dass man nicht alles über den Haufen werfen muss

    Anfang September war das bereits. ;)

    Alles über den Haufen wird man definitiv nicht werfen müssen. Was das ursprüngliche Thema betrifft, hier ging es ja eigentlich um Hyperlink Auditing, hat selbst Gooles Implementierung des Manifest v3 nichts damit zu tun. Der Themenersteller war damals schon recht zusammenhangslos auf das Manifest-Thema gekommen, was aber ein ganz eigenes Thema ist. Das Manifest v3 würde sich nur dann auf uBlock Origin auswirken, was ja seine Sorge war, wenn es dazu führen würde, dass es die Erweiterung überhaupt nicht mehr geben würde. Es ist durchaus möglich, dass es uBlock Origin für Chrome bald nicht mehr gibt, nachdem Google die Tage die neueste Version von uBlock Origin abgelehnt hat. Aber solange der Entwickler daraus nicht die Konsequenz zieht, uBlock Origin für Firefox einzustellen, hat das keine Auswirkungen auf Firefox, da Mozilla das, was Google für Erweiterungen wie uBlock Origin einschränken will, explizit nicht tun möchte. Bei dem Manifest-Thema ging es ja vor allem um einen funktional kritischen Teil der webRequest-API und dazu sagte Mozilla klar, dass es derzeit keinen Plan gibt, diesen Part aus Firefox zu entfernen. Es könnte durch das Manifest v3 definitiv auch in Firefox Änderungen geben, welche zwingend Anpassungen der Erweiterungen erfordern, weil sie ansonsten nicht mehr funktionieren. Aber ich bin mir sicher, auch Gorhill geht es nicht darum, dass er seine Erweiterung anpassen muss, sondern darum, ob am Ende weiterhin das möglich ist, was er für den vollen Funktionsumfang von uBlock Origin braucht. Mozilla hat jedenfalls in der Ankündigung deutlich gemacht, dass sie gewillt sind, von Googles Plänen abzuweichen, wo es in ihren Augen notwendig ist.

    autsch, 3.9., stimmt auffallend, habe mich wohl vom Hinweis diese Tage verleiten lassen. Google hat so ziemlich andere Ansichten von Werbeblockern, spätestens unter Android ist das mehr als deutlich geworden.

    Wir sind keine Beschwerdestelle, hier gibt es nur Lösungen! Meine Glückszahl hier: 93.