Trend: Client-side Webpage Hacking
Greasemonkey? Nie gehört!
Greasemonkey ist eine kostenlos verfügbare Erweiterung, die so genannte user scripts laden und ausführen kann. Diese greifen auf den HTML-Quellecode der angezeigten Webseite zu und können ihn automatisch modifizieren. Auf der Greasemonkey-Website wird das so erklärt:
Greasemonkey is a Firefox extension which lets you to add bits of DHTML („user scripts“) to any webpage to change it’s behavior. In much the same way that user CSS lets you take control of a webpage’s style, user scripts let you easily control any aspect of a webpage’s design or interaction.
For example you could:
– Make sure that all URLs displayed in the browser are clickable links
– Improve the usability of a site you frequent
– Route around common and annoying website bugs
Die Besonderheit von Greasemonkey: Es ist kostenlos erhältlich und jederzeit um beliebige user scripts erweiterbar, die ebenfalls kostenfrei zum Download angeboten werden. Diese user scripts sind einfach zu erstellen und können ganz simpel sein, durchaus aber auch sehr komplexe Aufgaben übernehmen.
Allerdings: Greasemonkey ist beileibe nicht die einzige Anwendung, die den HTML-Quelltext automatisch modifizieren kann. Das machen Werbeblocker, andere Firefox Extensions, Internet-Security Tools, der Internet-Explorer (bei bestimmten Sicherheitseinstellungen) und sogar die neue Google Toolbar (die dafür viel Kritik einstecken musste). Allein: Greasemonkey ist die flexibleste und weitreichendste all dieser Anwendungen.
Wo liegt der Sinn?
Den HTML-Quelltext lokal an bestimmte Bedürfnsse anzupassen, hat zweifellos seinen Sinn. Wenn beispielsweise nicht-klickbare Webadressen automatisch in klickbare Links verwandelt werden ist das durchaus im Sinne der Usability für den Betrachter – auch wenn der Autor der Seite im Einzelfall konkrete Gründe haben kann, gerade hier keinen Link zu setzen. Und auch Workarounds für Bugs und Browserinkompatibilitäten sind zweifellos hilfreiche Anwendungen. Und wenn der Browser potenziell gefährliche Inhalte blockiert und aus dem Quelltext (temporär) entfernt, ist auch das nützlich – solange ich als Nutzer nicht bevormundet werde, sondern die blockierten Inhalte trotzdem aufrufen kann.
gut!
Geschäftsmodell-Eingriff:
problematisch!
Überhaupt sind alle Modifikationen auf der Nutzer-Seite durchaus gewünscht – wenn nicht, kann er die entsprechende Funktion ja problemlos ausschalten. Allerdings kann es durchaus sein, dass der Content-Anbieter gar nicht erfreut darüber ist.
Nun gut, wenn der aber doch Fehler auf seinen Seiten hat oder böswillig gefährliche Inhalte in die Seiten einbaut? In diesem Fall wird wohl jeder den Sinn der Modifikation einsehen. Leider aber sind die Möglichkeiten des Client-side Webpage Hackings nicht auf diese Fälle beschränkt. Sie können vielmehr die Geschäftsgrundlage des Anbieters zerstören oder den Webdesigner arbeitslos machen…
Und was ist das Problem?
Vielleicht finden Sie, das sei ein übertriebenes Horror-Szenario: Aber wenn das Konzept weiter um sich greift, dann könnten sich die Geschäftsmodelle vieler Websites in Luft auflösen. Werden zum Beispiel Google Ads automatisch ausgeblendet (und dafür gibt es bereits heute ein Greasemonkey-Skript), dann entgehen den Seitenbetreibern potenzielle Werbeerlöse. Schon heute kann man feststellen, dass ein großer Teil der Webnutzer Online-Werbung ausblendet – aber mit der freien Verfügbarkeit flexibel anpassbarer Werbeblocker-Lösungen könnte das Problem noch weiter zunehmen.
Auch könnten aggressive Greasemonkey-Plugins die Referrer-Codes für Partnerprogramm-Links, wie sie in den Links zu Amazon-Seiten integriert sind, entfernen oder gar durch andere Codes austauschen. Theoretisch wäre es sogar denkbar, dass dies ohne Wissen des Nutzers geschieht. Längst gibt es einige Services wie einen Amazon-Pricewatch per RSS, die sich allein aus den Partnerprogramm-Erlösen refinanzieren … zumeist ohne Wissen der Käufer.
Und noch ein Beispiel: Die vielgescholtene Autolink-Funktion der Google Toolbar 3 (beta) verlinkt ISBN-Nummern automatisch mit der Detailseite zum Buch bei Amazon.com. Dabei unterscheidet sie nicht, auf welcher Website sich die ISBN befindet. So kann plötzlich ein anderer Online-Buch-Shop beim Betrachten durch den Anwender automatisch um Links zum großen Konkurrenten Amzon ergänzt werden. Kann das noch im Sinne des Anbieters sein?
In Zukunft könnte es zudem noch schwieriger für Webdesigner werden, Support für ihre Webseiten zu leisten. Schon heute ist es zum Teil problematisch, aus den rudimentären Fehlerbeschreibungen der Nutzer auf die Ursache zu schließen, wie wir bei eDings selbst immer wieder beobachten können. Wenn neue Fenster nicht geöffnet werden oder Funktionen einfach nicht ausgeführt werden, ist heute oft schnell ein Werbeblocker oder ein schlecht konfigurierter Browser verantwortlich. Zukünftig aber könnte es sein, dass der Nutzer mit einer modifizierten Seite arbeitet und das Problem durch die Modifikation auftritt, ohne dass der Webdesigner dies überhaupt ahnen kann. Spätestens dann, wenn Erweiterungen wie Greasemonkey populär werden und unbedarfte Nutzer zahlreiche user scripts installieren, deren Auswirkungen sie aber gar nicht durchschauen.
Und auch die Erweiterung von Anwendung um neue Features oder das Anbieten von kostenpflichtigen Premium-Diensten könnte zukünftig schwieriger werden: Für GMail, den noch im Beta-Test befindlichen E-Mail-Dienst von Google, existieren bereits Greasemonkey Scripts, die statische Suchfunktionen „nachrüsten“, die der Betreiber so gar nicht vorgesehen hat. Auch für Google Maps stehen bereits Funktionserweiterungen bereit: Einfach das entsprechende Greasemonkey-Skript installieren und es wird immer ausgeführt, sobald die entsprechenden Seiten angesurft werden.
Die Auswirkungen für Anbieter und Webdesigner können gravierend sein: Niemand wird für eine Funktion zahlen, die bereits als kostenloses Skript Client-seitig nachgerüstet werden kann. Und der Designer steht schnell im Wettkampf mit Programmierern, die quasi seine Arbeit der Webseiten-Optimierung übernehmen – gerade für populäre Websites. Wenn zudem die Refinanzierung der Content-Angebote durch Online-Werbung und Affiliate-Programme zurückgeht, weil die Betrachter werbende Inhalte automatisch ausblenden lassen, könnte manches Web-Business gefährdet werden.
Die Zukunft: Kämpfen oder kooperieren?
Was wird die Zukunft bringen? Unzweifelhaft ist, dass die Nutzer von den angebotenen Möglichkeiten, die Seiteninhalte nach ihren Wünschen anzupassen, Gebrauch machen werden – sofern dies ohne großen Aufwand möglich ist. Greasemonkey ist ein Schritt in diese Richtung … und vermutlich nicht der letzte.
Solange es keine akzeptierte Kennung z.B. in den Metatags der Webseiten gibt, die verdeutlicht, dass eine Client-seitige Modifikatin der Seite unerwünscht ist, und an die sich alle Tools halten, müssen Anbieter sich aktiv mit den auf sie zukommenden Problemen beschäftigen. Und dass eine solche Kennung kommt und verbindlich berücksichtigt wird, ist sehr unwahrscheinlich: Es würde Werbeblocker beispielsweise wertlos machen.
So bleibt für Anbieter: Sie können kämpfen und versuchen, sich gegen solche Modifikationsversuche zu schützen. Da alle bisherigen Ansätze auf dem HTML-Quelltext aufsetzen, könnte beispielsweise der Einsatz von Java und Flash dazu führen, dass die Ausblendung einzelner Inhalte (wie Werbung) deutlich erschwert wird. Auch die regelmäßige Veränderung des HTML-Quelltextes macht die vorhandenen user scripts wertlos, da sie nach bestimmten Mustern suchen und diese ersetzen. Analysiert der Webdesigner also die verfügbaren Webmonkey-Skripte, so kann er sie leicht aushebeln – allerdings riskiert er so den Frust der Nutzer, was in der Regel nicht gewünscht ist.
Die andere – und vermutlich bessere – Variante ist die der Kooperation: Warum nicht selbst Erweiterungen übernehmen, die Greasemonkey-Skripte überflüssig machen? Und für besondere Anwendungen könnte es durchaus sinnvoll sein, selbst Greasemonkey-Skripte anzubieten … beispielsweise um die Accessability einer Seite für Nutzer mit bestimmten Behinderungen zu verbessern. Was die Unterminierung der Geschäftsmodelle betrifft, so muss das Modell den Nutzern verdeutlicht werden – und die Folgen, wenn diese Refinanzierung zusammenbricht. Zusätzlich kann in Einzelfällen wiederum Client-seitig mittels JavaScript geprüft werden, ob Partnerprogramm-IDs und Links noch unverändert sind.
Insgesamt gibt das „Client-side Webpage Hacking“ den Nutzern ungeahnte Freiheiten im Umgang mit dem zur Verfügung gestellten Content. Diese Freiheiten können – wie so oft – zum allseitigen Vorteil eingesetzt aber auch geschäftsschädigend ausgenutzt werden. Hier sind auch die Programmierer der user scripts gefordert, verantwortungsvoll zu handeln. Es muss aber auch gesagt werden, dass die Möglichkeiten des Client-side Webpage Hackings begrenzt sind: Greasemonkey basiert darauf, die Seiteninhalte zu manipulieren – was sich nicht aus dem Quelltext ableiten lässt, kann auch Greasemonkey nicht anbieten. Zuküftig könnten aber durchaus auch Systeme entstehen, die die Inhalte verschiedener Webseiten, sogar potenziell von Anbieter, miteinander verknüpfen könnten.