Wie die Verbreitung von Programmen im Internet überprüfen?

Hin und wieder hat sich mir als Entwickler von Erweiterungen für Joomla die Frage gestellt, wie ich denn die Verbreitung dieser Addons überprüfen kann. Mit Programmen sind hier also Anwendungen für das Internet gemeint. Auch wenn ich keine der hier im folgenden genannten Mehoden angewendet habe, sind mir die meisten in der Zwischenzeit schon begegnet.

Problemstellung

Ja was nimmt man jetzt als Referenz für die Verbreitung einer Online-Anwendung? Die Anzahl der Downloads ist nicht wirklich aussagekräftig, da die einzelnen Packete meist auf mehreren Plattformen angeboten werden. Teilweise werden da dann auch nur die Absolutzahlen gezählt (der Counter also bei einem Versionsupdate nicht auf 0 gesetzt). Des Weiteren wird dann ein heruntergeladenes Packet auf mehreren Webseiten eingesetzt oder umgekehrt ein Packet häufig heruntergeladen, aber nie eingesetzt. Also ist das Bestreben eine Möglichkeit zu finden Programme im Live-Einsatz zu finden.

Ich möchte an dieser Stelle noch einmal darauf aufmerksam machen, dass ich hier Methoden beschreibe, die meiner Meinung nach grenzwertig sind, was den Datenschutz in hier Deutschland betrifft, die aber teilweise genau so eingesetzt werden.

Übermittlung der Information von der Installation an die Entwickler

Das prinzipielle Vorgehen bei dieser Methode ist es an ein Script auf dem Webserver der Entwickler Daten z.B. per GET zu übergeben:

http://www.die-entwickler-seite.de/scripts/script.php?version=5.1&website=http://www.installations-seite.de

Daten mit PHP übermitteln

Wie schon erwähnt ist es aus der Sicht eines Entwicklers sinnvoll die Daten von sich im Einsatz befindlichen Installationen zu erhalten. Da die Anwendungen meistens auf PHP basieren, kann man ein Script einbauen, welches zum Beispiel bei der Installation oder Bearbeitung der Konfigurationseinstellungen Daten an ein Script auf dem Entwickler-Server übermittelt.

Dies ist z.B. mit der Funktion fopen oder mit einer cURL-Session möglich. Der große Vorteil ist, dass der User von dieser Anfrage nichts mitbekommt und diese nicht blockieren kann, so lange er nicht in den Quelltext schaut.

Das Problem mit fopen ist, dass der Zugriff auf externe URLs mit der PHP-Einstellung allow_url_fopen blockiert werden kann. Das Problem gibt es bei cUrl nicht, aber das Packet ist nicht auf jedem Webserver installiert. Problematisch ist diese Art der Einbindung, wenn es sich um lokale oder interne Installationen handelt, die keinen Zugriff auf das Internet haben.

Daten mit Bildern übermitteln

Hierbei basiert die Informationsübertragung darauf, dass Browser auch Bilder laden, die eigentlich gar keine Bilder sind.

<img src="http://www.die-entwickler-seite.de/scripts/script.php?version=5.1&website=http://www.installations-seite.de" alt="Statistik" />

Dies ist ein Beispiel für eine Bildeinbindung, welche als Quelle ein PHP-Script auf einer externen Seite hat und welches vom Browser aufgerufen wird, weil es sich ja auch um ein dynamisch erzeugtes Diagramm o.ä. handeln könnte. Tatsächlich sammelt das PHP-Script aber nur die übergebenen Daten und gibt z.B. ein transparentes 1x1px-Bild zurück. Oder wie es auch häufig verwendet wird, zeigt das Bild an ob die verwendete Version noch aktuell ist.

Auch wenn ein richtiges externes Bild verlinkt ist, so kann man aus den Server-Logfiles eine Refferer-Auswertung machen, da die Webseite, die das externe Bild einfügt als Refferer gelistet wird.

Wenn der Client also in einer internen Anwendung surft, aber selbst eine Verbindung zum Internet hat, so funktioniert diese Methode der Informationsübertragung trotzdem, da der Browser in der Lage ist über die bestehende Internetverbindung das "Bild" nachzuladen.

Da die Umgebung des Clients um einiges variabler ist (Plugins zum Blockieren externer Bild oder Firewalls, die das Laden von dynamisch erzeugten Bildern verhindern), als die des Servers ist die über PHP funktionierende Methode sicherer, deckt aber keinen so großen Bereich ab.

Oft sind die hier genannten Möglichkeiten mit einer Überprüfung auf neue Versionen gekoppelt. Die nette Information, dass man die momentan aktuelle Version im Einsatz hat basiert oft auf einer der hier beschriebenen Techniken und ist somit geeignet auch das Feedback an die Entwickler zu geben.

Nutzung des Services von Suchmaschinen

Suchmaschinen indizieren inzwischen einen Großteil des Internets. Also kann man dieses große Archiv dazu nutzen um Rückschlüsse auf die Verwendung seiner Addons nutzen. Eine Möglichkeit wäre zum Beispiel nach diversen Bestandteilen in der URL zu suchen. Ein Beispiel für z.B. eine Joomla-Komponente würde dann etwas so aussehen: inurl:com_deineComponente. Das Problem ist aber, dass im Zuge der SEF-Optimierung genau dieser Part durch eine aussagekräftigere Bezeichung wie z.B. bilder ersetzt wird.

Also ist es effektiver, wenn man auf der Webseite einen eindeutigen String einfügt, den man dann z.B. per CSS und/oder Javascript ausblendet. Der normale User sieht dies dann nicht, die Spider von Suchmaschinen nehmen den Text dann trotzdem in ihr Archiv auf und so können gezielt Seiten indiziert werden, die das eigene Addon einsetzen.

Intranetanwendungen, Lokalinstallationen und Bereiche nur für registrierte User werden dann entsprechend von den Spidern der Suchmaschinen nicht mit in den Index aufgenommen und können somit auch nicht gefunden werden. Außerdem ist diese Technik problematisch, da manchmal eine Webseite mehrere Domains hat und in den Suchergebnissen auch einige Unterseiten mit gelistet werden. Ganz unpraktisch ist hierbei auch, wenn zum Beispiel Versionsnummern o.ä. mit in diesen Text geschrieben werden. Ist eine Sicherheitslücke für diese Version bekannt, dann haben auch Cracker leichtes Spiel die Webseiten mit potentiellen Lücken über den Service von Suchmaschinen zu finden.

Zu viel Daten

Natürlich will man als Entwickler verlässliche Zahlen über die Verbreitung seiner Programme haben. Aber ist es das wirklich wert, dass dafür die Webseiten der Anwender potentiell angreifbar werden? Auch bei der Version der Informationsübertragung direkt an ein Script auf dem Webserver der Entwickler ist es problamtisch von den Daten der User eine Datenbank anzulegen. Man stelle sich vor jemand entdeckt eine Sicherheitslücke in einem Programm und nutzt diese Sicherheitslücke z.B. auf der Demoseite der Entwickler um an die Datenbank mit dem Verzeichnis sämtlicher Webseiten zu gelangen, die das Programm mit der Sicherheitslücke verwenden. Ein komplettes Verzeichnis von potentiellen Angriffszielen auf dem Silbertablett?

Auch muss man als Anwender aufpassen, welche Daten denn von den eingesetzten Programmen alles an den Entwickler übertragen werden. Teilweise werden z.B. auch Emailadressen der Webseitenadministratoren mit übertragen. Begründet wird dies z.B. mit der Möglichkeit die Anwender über sicherheitskritische Updates informieren zu können. Natürlich schön versteckt im Hintergrund und ohne dem Anwender überhaupt eine Wahl zu geben, ob er das denn überhaupt möchte. Die rechtliche Seite einer solchen Datensammlung werde ich hier besser nicht weiter beleuchten!

Negative Auswirkungen

Mit diversen „Skripten, die nach Hause telefonieren” kann man sich auch ganz schnell bei den Usern unbeliebt machen. Spätestens wenn die komplette Anwendung ausfällt, da die Verbindung zum Heimserver nicht zustandekommt, fängt auch der übliche DAU an sich Gedanken über den Sinn dieser Funktion zu machen.

Fazit

Natürlich gibt es Möglichkeiten Erhebungen über die Verbreitung seiner Programme zu machen. Das ganze natürlich ohne die Anwender zu informieren. Aber ist dies wirklich im Sinne der Anwender? Eine einfache Möglichkeit anzubieten, an einer Erhebung zur Nutzung der Software teilzunehmen, wirft da doch ein viel besseres Bild auf die Anwendung an sich und bietet Anwendern die Möglichkeit auch ein persönliches Feedback mitzugeben.

Zurück