|
Wanzen in der WebseiteSicherlich kennen viele von Ihnen das folgende Szenario: Auf irgendeinerbeliebigen Webseite abonnieren Sie einen Newsletter. schon bald landet die erste Ausgabe im eigenen E-Mail-Postfach - natürlich schick formatiertin HTML. Wenn Sie später mal wieder auf die Mail schauen, geschieht etwas: Das E-Mail-Programm möchte online gehen. Warum sollte es das tun, die Mail ist doch schon da? Dasselbe kann beim Ansehen einer lokal gespeichertenWebseite geschehen.Des Rätsels Lösung sind die "Web-Bugs". Dabei handelt es sich in der Regel um eine kleine Grafik, die nur 1 mal 1 Bildpunkt groß und zudem auch noch transparent ist. Sichtbar ist diese Grafiken nicht, dennoch wird Ihr E-Mail-Programm dieses Bild darstellen wollen. Nun ist esso, dass es aber nicht mitgeschickt wurde, es liegt noch auf dem Server, das Programm greift auf das Internet zu. Wird die Grafik vom Server geladen, so wird dies dort mitprotokolliert. So kann der Betreiber des Newsletters sehen, wann und wie viele Leser den Newsletter geöffnet haben. Seriöse Argumente für solche "Web-Bugs" sind daher die Anfertigung von Statistiken. Letztlich möchten die meisten Webmaster Geld mit ihrer Site verdienen und ein potentieller Werbekunde möchte wissen, wie oft die E-Mail denn nun wirklich geöffnet wird. Da der Besuch von Webseiten derzeit i.A. kostenlos ist, ist dies ein durchaus legitimes Argument. Printmedien wissen schließlich auch, wie viele Zeitschriften verkauft wurden.Als Leser können Sie aber nicht feststellen, ob einfach nur gezählt wird, oder ob Ihre Schritte mitprotokolliert werden. Mit "Web Bugs" in E-Mails läßt sich also feststellen, ob und wann eine
Mail geöffnet wurde, was auch feststellbar macht, wann und ob Werbemails (SPAM)
gelesen wurden. Sie lassen sich auch verwenden, um den Cookie des Browsers mit einer
bestimmten Mailadresse zu verknüpfen, so daß ein Besucher bekannt ist,
wenn er später eine Website aufruft. Wenn jemand mit dem Outlook Express
oder dem Netscape Messenger Mitteilungen in einer Newsgroup liest, so lassen sich
mit einem "Web Bug" auch diese Leser identifizieren.
Man kann aber noch eins draufsetzen. Statt der Grafik wir ein Skript
aufgerufen, welches seinerseits die Grafikdaten zurückgibt und so das
E-Mail-Programm oder den Browser zufriedenstellt. Das Skript kann nun alle
möglichen Daten über den User ermitteln oder aus einer Menge von Grafiken
eine bestimmte auswählen (per Zufallsgenerator oder nach anderen Kriterien).
Selbst wer Cookies und Skriptsprachen abgeschaltet hat, entkommt dem
"Web-Bug" nicht. Der Code in einer HTML-Seite könnte beispielsweise so
aussehen:
<B>Diese Seite zeigt am unteren Ende eine Grafik,
die von einen CGI-Skript generiert wird.</B>
<p>
<hr><center>
<img src="/cgi-bin/bug.cgi"></center>
Man kann Verzeichnis und Dateiname natürlich noch "unverfänglicher"
gestalten. Ein Demoscript ist ebenfalls schnell gemacht:
#!/usr/bin/perl
use strict;
# HTTP-Vorspann
print "Content-Type: image/gif\n";
print "\n";
# GIF schicken
open(DAT,"1pix.gif");
print while (<DAT>);
close(DAT);
# Irgendwas protokollieren
open(DAT,">>bug.log");
print DAT "Killroy was here\n";
close(DAT);
Wenn man jetzt die Namen der Grafik dynamisch (z. B. benutzerbezogen)
generiert, kann man alleine über den Namen der Grafik schon ein
Benutzerprofil erstellen und - falls jede Webseite einen "Bug" enthält -
sogar den Weg durch das eigene Angebot verfolgen.
Mehr dazu findet man in der
Web Bug FAQ
von Richard M. Smith.
|
|
|