96dpi

Hintergrundgeschichte
Shaun Inman hat das Statistik-Werkzeug Mint entwickelt. Es ist eine PHP-Anwendung, die Seitenbetreibern detaillierten Einblick in Anzahl, Art und Ausstattung von Besuchern gibt. Sozusagen der große Bruder von ShortStat, dass vielen WordPress-Nutzern sicher ein Begriff ist. Die Software glänzt durch eine gute Plug-In Architektur. Man installiert Mint im Rahmen des eigenen Webhostings. Das ist natürlich angenehm, weil die Daten damit – je nach Hosting – vollständig unter der eigenen Kontrolle sind.

Damit möglichst viele Anwender Mint nutzen können, ist die Software nicht encodiert. Kodierte PHP-Scripts funktionieren nur, wenn das Hosting Enkoder von IonCube oder Zend integriert. Das ist bei vielen Hostern nicht der Fall. Mint ist nicht kostenlos. Daher ist Piraterie für die künftige Entwicklung Gift. Besonders dreist sind die Versuche einiger Softwarepiraten für gecrackte Versionen Support zu erhalten.

Hier fängt das Problem an: Kann man in Umgebungen wie PHP, Ruby oder Python, die alle zu offenem Quelltext neigen, kommerzielle Software anbieten? Bei Python und Ruby kenne ich mich nicht gut genug aus, um darauf eine schlüssige Antwort zu liefern. Daher beschränke ich mich in diesem Artikel nur auf die Situation bei PHP.

• Ansatz 1: Gehostete Lösungen
  Gerade am Beispiel von Statistiklösungen scheidet diese Lösung für viele – vor allem kommerzielle Anbieter aus. Ich würde mich unwohl fühlen, wenn die Details über meine Besucher bei einem externen Anbieter liegen. Selbst wenn die Nutzungsbedingungen den Datenschutz gewährleisten ist man nie davor sicher, dass der Hoster gehackt wird oder anderweitig nicht mehr verfügbar ist. Zudem würde der gesammelte Datenbestand des Hosters diesen zu einem viel attraktiveren Ziel machen.

  Gerade für kleine Unternehmen dürfte es zudem in der Entwicklungsphase schwierig sein, genügend Kapazitäten vorzuhalten, um einem eventuell entstehenden Ansturm am Anfang gerecht zu werden. Selbst Google mit enormen Mitteln und Kenntnissen im Loadbalancing und mit verteilten Anwendungen war dem Anstum auf Google Analytics nicht gewachsen. Wir soll eine One-Man-Show damit fertigwerden.

• Ansatz 2a: Security through Obfuscation/Obscurity/Secrecy
  Für diejenigen die das noch nicht gelesen haben: Es geht darum, die Sicherheit einer Software durch deren künstliche Komplexität und den undurchschaubaren Aufbau zu erzielen. Das ist zumindestens meiner Meinung nach der Ansatz.

  Das verzögert einen Hack aber nur. Kerckhoffs’ Gesetz: Moderne und sichere Verschlüsselungen sind immer so ausgelegt, dass die Sicherheit nicht kompromittiert wird, wenn das Verfahren vollständig bekannt ist. Das ist z.B. bei Private-/Public-Key-Verfahren der Fall. Ein solcher Ansatz ist – meines Wissens – ohne eine Authorisierungsstelle, also den Private Key, im Moment bei PHP nicht drin. Durch den Verzicht auf eine gehostete Lösung fällt aber der aber ins Wasser und die Lösung ist durch.

  Jeder als unhackbar proklamierte Kopierschutz ist bislang umgangen worden. Systeme, die robust genug sind um einfachen Angriffen zu widerstehen haben zudem oft gravierende andere Nachteile. Insbesondere in Serverumgebungen dürfte der softwarebasierte Schutz schwerfallen.

• Ansatz 2b: Encoder
  Hier kommen wir der Lösung näher. Die verfügbaren kostenpflichtigen Encoder dekodieren kompilierte Scripts. Dadurch wird es deutlich schwieriger, den Kopierschutz zu umgehen. Diese Lösungen setzen aber eine entsprechende PHP-Umgebung voraus, die bei kaum einem Webhoster angeboten wird. Daher ist der Ansatz eher im Bereich dezidierter oder gemanagter Server erfolgversprechend. Für eine Anwendung mit großer Zielgruppe – z.B. das oben erwähnte Mint – schränkt das die Nutzerbasis so stark ein, dass der wirtschaftliche Erfolg ausgeschlossen ist.
• Ansatz 3: Browserextensions/Verfolgung
  Hier ist die Idee, das Auffinden einer Software durch eine Extension an einen zentralen Server zu melden. Gerade Statistikprogrammen hinterlassen einen meinst charakteristischen Fingerabdruch im HTML-Quelltext der Seite, auf der diese eingesetzt werden. Das könnte durch eine Extension erkannt und gemeldet werden.

  Ich glaube nicht, dass so eine Herangehensweise effektiv ist. Der Fingerprint einer webbasierten Anwendung kann zu einfach geändert werden, wenn der Quelltext offen ist. Die Extension würde außerdem genau das machen, wofür Microsoft bei der Veröffentlichung von XP Schelte kassierte: Nach Hause telefonieren. Zudem müsste eine breite Nutzerbasis die entsprechenden Extensions installieren. Das Zusammenspiel der Faktoren macht eine Lösung unwahrscheinlich. Selbst wenn man diese Infos sammeln würde, steht die Durchsetzbarkeit der eigenen Rechte vor allem international auf einem anderen Blatt. Wegen der Höhe des Schadens würde die Verfolgung der Täter sicher schnell einschlafen und der Erfolg stünde in keinem Verhältnis zum Einsatz von Zeit, Mitteln und Nerven.

• Ansatz 4: Support/Patches nur für registrierte Anwender
  Dieses Mittel ist einfach umzusetzen und bei komplexer Software sehr effektiv. Nur Käufer, die eine Legitimation nachweisen können, erhalten Unterstützung und und Bugfixes. Jede “Seriennummer”, die illegal auftaucht wird gesperrt. Damit erhöht man die Hemmschwelle bei einigen Käufern und verringert den Arbeitsaufwand für Support, der nicht zur Kundenbindung beiträgt. Natürlich hält das niemanden davon ab, die Software dennoch zu kopieren.

  Letztlich sind viele Softwarepiraten faul. Wenn eine Software – gerade wenn sie sehr günstig ist – zu viele Zicken macht, nimmt man vielleicht doch das Geld in die Hand, um die Probleme abzuschaffen.

  Für das Web ist eine weitere Variante interessant: Die Softwarepiraten an den Pranger stellen. Besonders wenn die Software irgendwie in Richtung Blogs tendiert, hilft es ungemein, den Benutzer auf den Diebstahl hinzuweisen. Gehäufte Kritk hat schon in der Vergangenheit das reumütige Einlenken des Bösewichts zur Folge gehabt.