Es gibt nur ein winziges Problem: Die Nutzer haben einen Weg gefunden, sich zu wehren! Fast alle modernen Browser verfügen mittlerweile über eine standardmäßig aktivierte Popup-Unterdrückung, unterstützen das Blockieren von Cookies oder haben Plugins wie Adblock oder Ghostery, um die Website vollständig von jeglicher Art von Tracking oder Werbung zu säubern. Und es scheint zu funktionieren, wie eine kürzlich durchgeführte Kampagne verschiedener deutscher Online-Verlage zeigt. Diese Verlage forderten ihre Leser auf, die Adblocking-Software zu deaktivieren, mit der Begründung, dass diese mehr Schaden als Nutzen anrichten und zu erheblichen Einnahmeverlusten führen würde.
Das Feedback auf diese Kampagne war, wie zu erwarten, gemischt. Viele erklärten, dass sie Adblocking lediglich als Mittel der Selbstverteidigung nutzen: Die Werbung sei zu aggressiv in der Farbe, ablenkend, schlecht platziert oder zu fett für mobile Geräte bei einer Verbindung mit geringer Bandbreite. Für meinen Geschmack durchaus stichhaltige Gründe – und selbst die Verlage gaben zu, dass sie Sinn machen. Eine erschreckend geringe Anzahl von Nutzern antwortete, dass sie Werbung nicht explizit blockieren, sondern lediglich die Ausführung von JavaScript standardmäßig nicht zulassen; und als Nebeneffekt so ziemlich alle Tags abschalten, die JavaScript benötigen, um das HTML-DOM im Browser anzupassen, damit die Werbung angezeigt oder das statistische Tracking durchgeführt werden kann.
Warum also sollten diese Benutzer – die ursprünglich sowieso nur eine relativ kleine Gruppe waren – JavaScript deaktivieren? Die einfache Antwort wäre, sie einfach als paranoide Freaks zu bezeichnen. Aber dann, als weiterer Nebeneffekt der Kampagne, verdoppelten oder verdreifachten sich die Downloads von Adblock-Plugins während besagter Kampagne, und die Spenden an die Entwickler stiegen ebenfalls. Vielleicht haben also einige der Leute einfach nur die Nase voll von der Werbung, die ihren Browser übernimmt, und dem Mangel an Privatsphäre aufgrund der ganzen Verfolgung und Datenauswertung? Oder vielleicht ist die Wahrheit, dass sie – wie ich zu einem gewissen Grad – paranoid genug sind, um diesen Anzeigen nicht zu trauen, JavaScript auszuführen (oder schlimmer noch, das Flash-Plugin zu starten). Denn was viele nicht wissen, ist, dass die Anzeigenschaltung oft ein rekursiver Prozess ist: Während der Webmaster vielleicht nur den Ad-Tag von seinem Adserver der Wahl eingebettet hat, kann der eigentliche ausgelieferte Inhalt von einer völlig fremden Maschine bedient worden sein, von der zusätzlicher Code heruntergeladen wurde, oder nachdem die Stelle auf der Website mehrmals neu verkauft wurde. Letzteres passiert, weil ein Adserver, wenn es keine aktuelle Buchung für einen Slot gibt, kein leeres Bild ausliefert, sondern stattdessen auf eine andere verwendete Anzeige zurückgreift.
Das mag dem Website-Betreiber zwar immer noch einen kleinen Umsatz bescheren, aber das rekursive Nachschlagen von Hostnamen sowie das Herunterladen von zusätzlichen JavaScript- und Mediendateien ist ein ziemlicher Performance-Drain für das Gerät des Endnutzers. Und es reduziert die Vertrauenswürdigkeit des eigentlichen Inhalts, da niemand wirklich sagen kann, woher das Skript kommt, wenn es seinen Weg zum Browser gefunden hat. Selbst wenn also die Firma, die den Adserver betreibt, den Sie in Ihre Website einbinden, behaupten kann – hoffentlich zu Recht -, dass ihre Server sicher sind, hat sie kaum Einfluss auf die Inhalte, die sie ausliefert.
Ein verwandtes – wenn auch nicht unbedingt offensichtliches – Problem ist die eigentliche Einbettung des Ad-Tags. Während es mit deaktiviertem JavaScript auf Browserebene einfach nicht funktioniert, gibt es auch einige andere technische Probleme. Es wird behauptet, dass die Tatsache, dass die XML-Version von HTML (auch bekannt als XHTML) nicht gerade erfolgreich war, sowohl was den Marktanteil als auch die Browserunterstützung angeht, zum Teil mit der Art und Weise zusammenhängt, wie Werbung in Websites eingebettet werden muss. Die meisten Dienste erfordern das Hinzufügen eines <script>
-Elements in den <head>
-Abschnitt des Dokuments sowie einen Inline-Funktionsaufruf überall dort, wo eine Anzeige auf der Seite erscheinen soll. Was aus der Entwicklungsperspektive bequem erscheint, ist jedoch technisch gesehen eine wirklich schlechte Wahl: Erstens macht das Inline-Scripting Annahmen darüber, wie der Browser das Html verarbeitet, und zweitens zwingt es den Browser, das Parsen des Markups zu stoppen und in die Ausführung von JavaScript zu wechseln – nur um danach wieder zum Parsen zurückzukehren. Das Problem ist, dass bei der Verwendung eines XML-Parsers statt eines SGML-Parsers viele Dinge, die JavaScript ermöglicht, wie document.write(), nicht genutzt werden können und somit nicht funktionieren. Das hat zur Folge, dass das Inline-Skript möglicherweise nicht wie erwartet funktioniert oder sogar gar nicht ausgeführt wird.
In den Tagen, als XHTML definiert wurde, ignorierten die Adserver-Firmen diese Probleme zunächst und sagten jedem, der sich beschwerte, er solle zurück zu HTML 4 wechseln oder den Browser in den Compat- oder Quirksmode zwingen, um ihn daran zu hindern, den XML-Parser zu verwenden. Nach einer Weile änderten die Adserver-Anbieter, anstatt das eigentliche Problem – die Verwendung von Inline-Skripten – zu beheben, lediglich den Skriptcode so, dass er ohne die problematischen Funktionen funktionierte, so dass er in HTML- und XHTML-Varianten funktionierte. Und während das im ersten Moment wie eine „gut genug"-Lösung erscheint, war das Problem schon längst wieder da. Und, voila, im Jahr 2013 ist das Problem wieder da.
In einem Versuch, XSS-Angriffe (Cross Site Scripting) zu verhindern, haben Mozilla, Apple und Google einen neuen Sicherheitsmechanismus namens Content Security Policy, abgekürzt CSP, in ihre jeweiligen Browser implementiert. Die Idee hinter der CSP ist einfach, aber höchst effektiv: Nur externe JavaScript-Quellen von Whitelist-Domains (individuell vom Webmaster definiert) zulassen und jegliches Inline-Scripting abschalten. Unter der Annahme, dass ein Angreifer nicht in der Lage ist, die Liste der erlaubten Domains zu ändern, während er gleichzeitig Code in den Inhalt injiziert, wäre es nicht mehr möglich, aktives Scripting in das HTML zu injizieren.
Während dieser Ansatz technisch gesehen die XSS-Probleme auf der falschen Seite behebt, fühlt es sich wieder ein wenig wie Selbstverteidigung an: Da die Backend-Entwickler es offensichtlich nicht schaffen, die Ausgabe richtig zu escapen – obwohl XSS schon Jahrzehnte alt ist und jeder Entwickler wissen sollte, wie er seine Website schützen kann – scheint der Browser die letzte Verteidigungslinie zu sein.
Natürlich, wie bei so ziemlich allen Lösungen, die versuchen, Dinge an der falschen Stelle zu beheben, wird der Schutz nicht 100%ig sein: Mir fallen schon jetzt mehrere Möglichkeiten ein, diese „Einschränkungen“ zu umgehen, und ich wette, die bösen Jungs werden sich in kürzester Zeit noch mehr einfallen lassen. Aber zumindest werden die Adserver-Anbieter gezwungen sein, ihre Adtags endlich so zu verbessern, dass sie ohne Inline-Scripting und ohne das Herunterladen von zusätzlichem Code aus unbekannten Quellen funktionieren. Besser als nichts.