Ich möchte Ihnen etwas sagen, das Sie *nicht* tun sollten, um Ihre Website besser zu machen. **Fügen Sie Ihrer Website keine** Third-Party-Skripte **hinzu.**
Das mag extrem klingen, aber früher wäre das gesunder Menschenverstand gewesen. Im heutigen modernen Web klingt es wie Ratschläge eines verschwörungstheoretischen Spinner mit Aluhut. Aber nur weil ich paranoid bin, heißt das nicht, dass sie nicht hinter den Daten Ihrer Benutzer her sind.
Alles, worum ich bitte, ist, dass wir Third-Party-Skripte wie Third-Party-Cookies behandeln. Sie waren ein Fehler.
Browser beginnen nun, Third-Party-Cookies zu blockieren. Chrome zögert, weil dasselbe Unternehmen, das den Browser herstellt, auch ein Werbegeschäft betreibt. Aber selbst sie können der Flut nicht widerstehen. Third-Party-Cookies werden fast ausschließlich zum Tracking verwendet. Das war nie der Plan.
Am Anfang gab es keinen Zustand im Web. Ein Client forderte eine Ressource von einem Server an. Der Server antwortete. Dann vergaßen beide sofort daran. Das machte es schwierig, Einkaufswagen oder Logins zu erstellen. Deshalb bekamen wir Cookies.
Im Nachhinein hätten Cookies von Anfang an auf eine Same-Origin-Policy beschränkt sein sollen. Das hätte die Probleme der Authentifizierung und des Handels gelöst, ohne ein riesiges Sicherheitsloch zu öffnen, das ausgenutzt wurde, um Leute zu verfolgen, während sie von einer Website zur anderen wechselten. Das Web ging von keinem Zustand zu zu viel Zustand über.
Jetzt wird diese Schwachstelle endlich geschlossen. Aber nur für Cookies. Ich würde es lieben, wenn Third-Party-JavaScript die gleiche Behandlung erfahren würde.
Wenn Sie *irgendeine* Third-Party-Datei zu Ihrer Website hinzufügen – ein Bild, ein Stylesheet, eine Schriftart – ist das ein potenzieller Vektor für Tracking. Aber Third-Party-JavaScript-Dateien gehen noch einen Schritt weiter. Sie können beliebigen Code ausführen.
Nehmen Sie sich einfach eine Minute Zeit, um die Auswirkungen zu bedenken: Jedes Third-Party-Skript auf Ihrer Website erlaubt jemand anderem, Code auf Ihren Webseiten auszuführen. Das ist erstaunlich unsicher.
Es wird noch besser. Einer der Codes, die dieser eingeladene Eindringling ausführen kann, ist die Fähigkeit, *andere* Third-Party-Skripte einzubinden.
Sie denken vielleicht, es sei kein Schaden, dieses eine kleine Analyse-Skript hinzuzufügen. Oder dieses eine kleine Google Tag Manager-Snippet. Es ist schließlich nur ein winziges Stück Code. Aber indem Sie das tun, haben Sie einem Fremden Ihre Schlüssel übergeben. Und jetzt begrüßen sie all ihre zwielichtigen Bekannten.
Request Map Generator ist ein großartiges Werkzeug, um die Ressourcen zu visualisieren, die auf jeder Webseite geladen werden. Versuchen Sie, die URL eines interessanten Artikels von einer Nachrichten- oder Magazinwebsite einzufügen, die Ihnen kürzlich jemand geschickt hat. Dann bestaunen Sie die schiere Größe und Anzahl von Third-Party-Skripten, die über ein winziges script-Element auf der ursprünglichen Seite eingeschleust werden.
Deshalb empfehle ich, dass das Einzige, was Menschen tun können, um ihre Website zu verbessern, darin besteht, keine Third-Party-Skripte hinzuzufügen.
Leichter gesagt als getan, oder? Besonders wenn Sie an einer Website arbeiten, die für ihr Geschäftsmodell auf Third-Party-Tracking angewiesen ist. Aber dieses ausbeuterische Geschäftsmodell wird sich nicht ändern, es sei denn, Menschen wie wir sind bereit, uns am passiven Widerstand zu beteiligen.
Ich weiß, ich weiß. Wenn Sie sich weigern, dieses Third-Party-Skript hinzuzufügen, wird Ihr Chef wahrscheinlich sagen: „Gut, ich werde jemanden anderen dafür finden. Außerdem sind Sie gefeuert.“
Diese Taktik wird nur funktionieren, wenn sich alle darauf einigen, das Richtige zu tun. Wir müssen uns gegenseitig den Rücken stärken. Wir müssen uns gegenseitig unterstützen. Die Art und Weise, wie sich Menschen am Arbeitsplatz unterstützen, ist durch eine Gewerkschaft.
Also, ich denke, ich möchte meine Antwort auf die gestellte Frage ändern.
Das Einzige, was Menschen tun können, um ihre Website zu verbessern, ist, sich gewerkschaftlich zu organisieren.
Ich bin schon überzeugt, aber ich benutze immer noch diesen wunderbaren Dienst: https://polyfill.io
Es ist etwas kompliziert richtig einzurichten und könnte schließlich davon profitieren, mit anderen Websites, die es nutzen, geteilt zu werden.
Zum Beispiel gibt es dieser Website, die ich kürzlich erstellt habe: https://piercan.fr/
Nur neugierig: Wenn Sie nicht möchten, dass Leute Drittanbieter-JavaScript verwenden, dann
Die Möglichkeit, Verhalten zu analysieren, um Verbesserungen vorzunehmen, ist entscheidend für jedes Team. Die besten Anbieter für Webanalysen verwenden JavaScript, und daher müssen Sie standardmäßig Drittanbieter-JavaScript laden, wenn Sie eine Art von Analyse durchführen möchten.
Wenn so etwas also effektiv erforderlich ist, dann ist Drittanbieter-JavaScript erforderlich? Wenn nicht, würde ich gerne hören, wie man Webdaten effektiv ohne solche Dienste analysieren kann.
Ich liebe den Aufruf, aber mir fehlt die Nuance
Warum dies auf Drittanbieter-Skripte beschränken; was ist mit Drittanbieter-Code-Snippets, Stylesheets, Bildern, Videos und anderen Dateitypen?
Warum dies auf Sicherheit und Leistung beschränken; was ist mit Barrierefreiheit oder technischer (Validierung) und rechtlicher Compliance (z. B. mit der DSGVO)?
Was ist mit den Problemen, die Drittanbieter-Lösungen lösen?
Die Realität scheint zu sein, dass a) das Web schon immer Drittanbieter-Einbettungen genutzt hat und dass b) Drittanbieter-Einbettungen schon immer mangelhaft waren (technische Qualität, Transparenz über die Nutzung von Daten).
Persönlich glaube ich, dass ein Weg darin besteht, mehr von Einbettungscode zu verlangen – ihn einfach zu verwenden, qualitativ hochwertig zu machen und sicherzustellen, dass er sparsam und transparent bei der Datenverarbeitung ist. (Das ist ein Weg.)
Da das Web jedoch schon immer Drittanbieter-Einbettungen genutzt hat, erfordert die Lösung der verschiedenen Probleme, die sie mit sich bringen, möglicherweise Nuancen.
„Das ist erstaunlich unsicher.“
Das stimmt, vorausgesetzt, Sie wissen nicht, was wirklich referenziert wird.
Wenn Sie es wissen und wissen, wie es funktioniert, ist das in Ordnung, und wir haben Werkzeuge wie Subresource Integrity (SRI), um sicherzustellen, dass dieser Code nicht geändert wird.
Auch wenn Sie sich Sorgen machen, dass ein Drittanbieter-Skript ein weiteres Drittanbieter-Skript einbindet, haben wir Content Security Policies (CSP), um zu listen, was wir auf unserer Seite laden dürfen.
Es ist möglich, Drittanbieter-Code sicher zu verwenden. Es ist nur schwierig.
Alles in allem stimme ich Ihnen weitgehend zu – vermeiden Sie Drittanbieter-Skripte, wann immer Sie können.
Da Browser aus Datenschutzgründen eine „Cache-Partitionierung“ durchführen, gibt es keine Leistungsvorteile mehr, da der Browser-Cache bereits von einer anderen Website gefüllt wurde.
Und die Kontaktaufnahme mit der Domäne eines Drittanbieters beinhaltet typischerweise eine DNS-Abfrage, einen TLS-Handshake usw. – das kann ziemlich langsam sein. Preconnect-Ressourcenhinweise helfen, aber nur bis zu einem gewissen Grad.
Persönlich halte ich es jedoch für unsicherer, wenn Benutzer – typischerweise das Marketing – mit GTM losgelassen werden. Ich stoße immer wieder auf Websites, auf denen spät im Seitenladezyklus plötzlich ein Haufen Müll von GTM geladen wird.
https://andrewwburns.com/2019/06/03/why-i-dont-like-google-tag-manager/
Ein Tracking-Skript mit Subresource Integrity ist immer noch ein Tracking-Skript.
Ich bin überrascht, dass CSP nicht erwähnt wird, was eine großartige Lösung für dieses Problem ist.