Browser-Fin­ger­prin­ting: Grund­la­gen und Schutz­mög­lich­kei­ten

Seit dem 1. November 2010 haben Sie in Deutsch­land die Mög­lich­keit, Ihren Fin­ger­ab­druck in den Per­so­nal­aus­weis aufnehmen zu lassen. In Kom­bi­na­ti­on mit dem Lichtbild wird auf diese Weise eine ein­deu­ti­ge Zuordnung von Aus­weis­in­ha­ber und Ausweis si­cher­ge­stellt. Während der klas­si­sche Vergleich von Lichtbild und dem realen Er­schei­nungs­bild theo­re­tisch das Risiko be­inhal­tet, dass ein Fremder, der Ihnen ähnlich sieht und in den Besitz Ihres Ausweises gelangt ist, sich als Sie ausgibt, schließt die Ver­knüp­fung mit dem Fin­ger­ab­druck, der immer ein­zig­ar­tig ist, ein solches Szenario in jedem Fall aus.

Browser-Fin­ger­prints (dt. Browser-Fin­ger­ab­drü­cke) zeichnen sich zwar nicht durch eine solche Ein­zig­ar­tig­keit aus, bieten jedoch bei der Wie­der­erken­nung von Web-Usern immerhin eine Er­folgs­quo­te von über 80 Prozent – und das, obwohl die Erfassung dieser digitalen Fin­ger­ab­drü­cke gänzlich ohne den Einsatz von Cookies funk­tio­niert. Aus diesem Grund nutzen Marketer und Website-Betreiber die Brow­ser­spu­ren-Aus­wer­tung immer häufiger, um online Nutzer zu verfolgen und die Er­geb­nis­se zum Zweck der Website-Op­ti­mie­rung oder zur Kon­zi­pie­rung ziel­ge­rich­te­ter Werbung zu verwenden.

Um Inhalte von einem Server abrufen zu können, benötigen Sie eine Client-Software. So greifen Sie bei­spiels­wei­se auf einen E-Mail-Client zurück, um Nach­rich­ten vom Mail-Server abzuholen. Der Zugriff auf Webserver gelingt hingegen mit den bestens bekannten Web­brow­sern wie Mozilla Firefox, Safari oder Google Chrome. Über das HTTP-Protokoll fordern diese An­wen­dun­gen Daten von Websites an, um sie an­schlie­ßend nut­zer­ge­recht dar­zu­stel­len. Die Über­mitt­lung der Inhalte findet dabei über IP-Pakete statt, die neben den Nutzdaten auch In­for­ma­tio­nen zum Client enthalten und die auf Ser­ver­sei­te dazu verwendet werden können, um den Fin­ger­print des Browsers zu ermitteln.

Dabei un­ter­schei­det man grund­sätz­lich zwei Arten des Browser-Fin­ger­prin­tings:

• Passives Fin­ger­prin­ting: Unter dem so­ge­nann­ten passiven Fin­ger­prin­ting versteht man das Sammeln von Brow­ser­in­for­ma­tio­nen, die ohne Einsatz einer spe­zi­el­len Anwendung gewonnen werden. Dabei handelt es sich um In­for­ma­tio­nen, die stan­dard­mä­ßig in den Kopfdaten der IP-Pakete enthalten sind und den Webserver daher in jedem Fall erreichen. Zu diesen In­for­ma­tio­nen gehören unter anderem die IP-Adresse, der genutzte Port und der Brow­ser­typ. Aber auch grund­sätz­li­che Kon­fi­gu­ra­tio­nen wie die ge­wünsch­ten Da­tei­ty­pen (HTML, XHTML, XML), Zei­chen­sät­ze (z. B. UTF-8) oder Sprachen (in der Regel Sprache des Browsers bzw. Be­triebs­sys­tems) zählen dazu. Außerdem liefert der HTTP-Header in einigen Fällen auch In­for­ma­tio­nen über das ver­wen­de­te Be­triebs­sys­tem und die Her­kunfts­sei­te.

• Aktives Fin­ger­prin­ting: Beim aktiven Fin­ger­prin­ting fragt der Browser gezielt solche In­for­ma­tio­nen ab, die nicht au­to­ma­tisch bei einem Aufruf einer Web­res­sour­ce mit­ge­lie­fert werden. Diese Abfrage gelingt bei­spiels­wei­se mit Ja­va­Script-An­wen­dun­gen oder Plug-ins, die die Funk­tio­na­li­tät des Browsers erweitern (ins­be­son­de­re Adobe Flash und Microsoft Sil­ver­light). Unter anderem können auf diese Weise er­wei­ter­te In­for­ma­tio­nen über den Browser, aber auch aus­führ­li­che In­for­ma­tio­nen über das Be­triebs­sys­tem sowie den Bild­schirm (Breite, Höhe, Auflösung) des Nutzers gewonnen werden. Weitere Daten geben bei­spiels­wei­se Auskunft über die in­stal­lier­ten Schrift­ar­ten oder die Zeitzone, in der sich der User befindet.

Wie bereits erwähnt dient der Fin­ger­ab­druck des Browsers dazu, einen Nutzer zu iden­ti­fi­zie­ren, um ihn später wie­der­erken­nen zu können. Auf diese Weise ist es möglich, dessen Surf­ver­hal­ten zu be­ob­ach­ten, um Er­kennt­nis­se über die Funk­tio­na­li­tät und Usability des eigenen Web­pro­jekts zu gewinnen oder diesem User per­so­na­li­sier­te Inhalte zuspielen zu können. Das Browser-Fin­ger­prin­ting soll der Besucher der Seite selbst natürlich möglichst nicht bemerken, was bei der passiven Variante auch kein Problem darstellt, da die Daten ohnehin bei jedem Request über­tra­gen werden und nur auf Ser­ver­sei­te ge­spei­chert werden müssen.

Al­ler­dings mangelt es diesen au­to­ma­tisch über­mit­tel­ten In­for­ma­tio­nen häufig an Aus­sa­ge­kraft. Ins­be­son­de­re die IP-Adresse – deren Spei­che­rung auch aus recht­li­chen Gründen pro­ble­ma­tisch ist – und die genutzten TCP-Ports können ihre Rolle als ent­schei­den­de Merkmale des digitalen Fin­ger­ab­drucks aus zweierlei Gründen nicht erfüllen:

1. Dy­na­mi­sche Adress­zu­ord­nung: Wer sich mit dem Internet verbindet, erhält von seinem Zu­gangs­an­bie­ter keine feste und dau­er­haf­te IP-Adresse. Er bezieht jedes Mal eine neue, dy­na­mi­sche IP aus dem Pool ver­füg­ba­rer Adressen. Eine konkrete IP-Adresse kann also immer nur für einen be­stimm­ten Zeitraum genau einem Gerät zu­ge­ord­net werden. Wann genau ein Gerät eine neue In­ter­net­adres­se bezieht, wissen nur der Nutzer und sein Provider.
2. Netzwork Address Trans­la­ti­on (NAT): Noch pro­ble­ma­ti­scher wird es, wenn NAT (dt. Netz­werk­adress­über­set­zung) zum Einsatz kommt. Das Verfahren verbindet mehrere Geräte unter einer ge­mein­sa­men, öf­fent­li­chen IP-Adresse mit dem Internet – die Nutzer teilen sich diese IP-Adresse also. Es wird bei­spiels­wei­se von Routern ein­ge­setzt, die private Haushalte in einem LAN vereinen, aber auch von Providern, die mit der Technik ins­be­son­de­re den Mobilfunk-Sektor steuern. Auf diese Weise kommt es vor, dass sich die Mo­bil­ge­rä­te zwei un­ter­schied­li­cher Nutzer dieselbe IP-Adresse teilen.

Beide Adress­ver­ga­be-Techniken re­sul­tie­ren vor  dieses Problem in den kommenden Jahren lösen wird, bleibt ab­zu­war­ten, inwiefern dy­na­mi­sche Adressen und NAT künftig ein­ge­setzt werden.

Die TCP-Ports, die ein Client für die Kom­mu­ni­ka­ti­on mit dem Server verwendet, eignen sich ebenso wenig als Wie­der­erken­nungs­merk­mal eines Geräts. Während die Quellport-Nummer bei jedem Request zufällig generiert wird, sind für Dienste im Netzwerk immer fest ver­ein­bar­te Standard-Port­num­mern vor­ge­se­hen, weshalb alle Clients auch denselben Zielport verwenden. Für die HTTP-Anfragen an einen Webserver ist dies bei­spiels­wei­se TCP-Port 80.

Der Header des HTTP-Pro­to­kolls, das wie bereits erwähnt für die Über­mitt­lung von Web­in­hal­ten genutzt wird, hat anders als die TCP- und IP-Kopfdaten keine feste Größe. Neben der Fähigkeit, be­nut­zer­de­fi­nier­te Einträge zu enthalten, sind diverse stan­dar­di­sier­te Felder vor­ge­schrie­ben, von denen einige für die Er­stel­lung des Browser-Fin­ger­prints von ele­men­ta­rer Bedeutung sind. Dabei handelt es sich ins­be­son­de­re um folgende Header-Daten:

• „Referer“ (Her­kunfts­sei­te): Wenn ein User über einen Link von Seite A auf Seite B gelangt, wird die URL von Seite A als Referer an den Server von Seite B über­tra­gen. Unter Umständen gelangen bestimmte Nutzer immer von einer be­stimm­ten Aus­gangs­sei­te auf die Zielseite, was für die Er­stel­lung des Fin­ger­prints ebenso nützlich ist wie in der URL ent­hal­te­ne GET-Parameter.

• „User-Agent“ (Be­schrei­bung des Clients): Bei jedem HTTP-Request liefert der jeweilige Client für ge­wöhn­lich auch eine Be­schrei­bung von sich im „User-Agent“-Feld mit. Neben der Be­zeich­nung und der Ver­si­ons­num­mer bietet der HTTP-Header dort auch Platz für einen Kommentar, in dem viele Browser die zu­grun­de­lie­gen­de Plattform bzw. das Be­triebs­sys­tem aufführen.

• „Accept“ (zu­ge­las­se­ne Aus­ga­be­for­ma­te): Über das Accept-Feld teilt der Browser dem Server mit, welche In­halts­ty­pen er ver­ar­bei­ten kann und daher als mögliche Aus­ga­be­for­ma­te wünscht. Neben HTML sind hierbei vor allem XHTML (Ex­ten­si­ble Hypertext Markup Language) und XML (Ex­ten­si­ble Markup Language) gefragt. Wenn das Feld fehlt, un­ter­stützt der Client alle In­halts­ty­pen.

• „Accept-Charset“ (zu­ge­las­se­ne Zei­chen­sät­ze): Zu­sätz­lich zu dem Aus­ga­be­for­mat kann der Client auch den ge­wünsch­ten Zei­chen­satz de­fi­nie­ren, den der Server bei seiner Antwort verwenden soll. Dabei handelt es sich vor allem um UTF-8 und den ISO-Standard ISO/IEC 8859-1.

• „Accept-Encoding“ (ak­zep­tier­te Kom­pres­si­ons­for­ma­te): Um die Ladezeit des Web­pro­jekts zu op­ti­mie­ren, ist es üblich, Web­in­hal­te vor dem Versand zu kom­pri­mie­ren. Der Browser muss die kom­pri­mier­ten Daten folglich entpacken, bevor er sie dar­stel­len kann. Im Feld „Accept-Encoding“ teilt er dem kon­tak­tier­ten Server mit, welche Kom­pres­si­ons­for­ma­te er un­ter­stützt. Die Liste möglicher Verfahren, die von der IANA geführt wird, enthält unter anderem gzip, deflate, exi und br.

• „Accept-Language“ (ak­zep­tier­te Sprachen): Über den HTTP-Eintrag „Accept-Language“ teilen Clients mit, welche Sprach­ver­si­on sie prä­fe­rie­ren. Wenn diese für die auf­ge­ru­fe­ne Website vorhanden ist, liefert der Webserver sie aus. Die forcierte Sprache re­sul­tiert aus der ver­wen­de­ten Sprache des Browsers oder des Be­triebs­sys­tems. Einige Browser bieten darüber hinaus die Mög­lich­keit, in den Ein­stel­lun­gen weitere Sprach­wün­sche anzugeben.

Aktives Fin­ger­prin­ting setzt – wie der Name bereits vermuten lässt – voraus, dass der Betreiber eines Web­pro­jekts In­for­ma­tio­nen über den Client aktiv abfragt. Die erfragten Ei­gen­schaf­ten und Daten sind folglich Merkmale, die nicht aus den Kopfdaten der Client-Pakete her­vor­ge­hen. Da zu diesem Zweck An­wen­dun­gen auf Seiten des Browsers aus­ge­führt werden müssen, kann der Nutzer das Fin­ger­prin­ting theo­re­tisch jederzeit nach­wei­sen, indem er die aus­ge­hen­den Da­ten­pa­ke­te oder den HTML- bzw. Ja­va­Script-Quellcode ana­ly­siert. In den über­wie­gen­den Fällen wird der Prozess den Besuchern jedoch ebenso verborgen bleiben, wie es auch bei ver­gleich­ba­ren Tracking-Verfahren der Fall ist.

Für einen nahtlosen und schnellen Da­ten­aus­tausch zwischen Client und Server ist es üblich, aktives Browser-Fin­ger­prin­ting über AJAX-Elemente (Asyn­chro­no­us JavaScript and XML) zu im­ple­men­tie­ren. Durch diese Technik können Besucher mit einer Seite in­ter­agie­ren, ohne dass selbige bei jeder HTTP-Anfrage komplett neu geladen werden muss. Zu diesem Zweck werden lediglich die an­ge­for­der­ten Res­sour­cen im Hin­ter­grund geladen, während der User alle anderen Elemente weiterhin sehen und nutzen kann. Die In­for­ma­tio­nen, die man mithilfe der ent­spre­chen­den Skripte in Erfahrung bringen kann, lassen sich in die zwei Ka­te­go­rien Brow­ser­in­for­ma­tio­nen und Bild­schirm­in­for­ma­tio­nen einteilen. Ferner kann der Browser-Fin­ger­print mithilfe von Ja­va­Script auch um Angaben über der Zeitzone und die ein­ge­stell­ten Sys­tem­far­ben erweitert werden.

Abrufbare Brow­ser­in­for­ma­tio­nen

Bei den ab­frag­ba­ren Ei­gen­schaf­ten über den Browser des Nutzers handelt es sich zum Großteil um dieselben, die man auch beim passiven Fin­ger­prin­ting erhält. Das Tracking gelingt mithilfe des Navigator-Objekts, welches eine mögliche Ei­gen­schaft für Window-Objekte ist – also sich im Browser öffnenden Fenster. Auch wenn für das Navigator-Objekt kein all­ge­mei­ner Standard definiert ist, wird es dennoch von allen gängigen Browsern un­ter­stützt. Es leitet unter anderem die folgenden In­for­ma­tio­nen an den Webserver weiter:

• navigator.appName: Gibt den Namen des Browsers weiter, bei­spiels­wei­se „Opera“ oder „Netscape“.

• navigator.app­Ver­si­on: In­for­miert den Server über die Version des Browsers und in einigen Fällen auch über das Be­triebs­sys­tem und sogar über den Pro­zes­sor­typ. Ein möglicher Eintrag ist zum Beispiel „5.0 (Windows)“.

• navigator.coo­kie­En­ab­led: Mithilfe der coo­kie­En­ab­led-Ei­gen­schaft lässt sich über­prü­fen, ob der Browser Cookies un­ter­stützt („true“) oder ob der Nutzer diese de­ak­ti­viert hat („false“).

• navigator.language: Über diese Ei­gen­schaft lässt sich die Brow­ser­spra­che in Erfahrung bringen. Sie wird von allen gängigen Browsern un­ter­stützt (Internet Explorer ab Version 11.0; Firefox ab 1.0) und ent­spricht in etwa dem HTTP-Eintrag „Accept Language“. Beispiele für gültige Sprach­codes sind „en“, „en-US“ oder „de“.

• navigator.platform: Gibt die vom Benutzer ver­wen­de­te Plattform an. Mögliche Werte sind unter anderem Win32, MacIntel, Linux i686, iPhone, Android und SunOS.

• navigator.userAgent: Auch beim aktiven Browser-Fin­ger­prin­ting kann eine de­tail­lier­te Kennung des Browsers ein­ge­se­hen werden. Die userAgent-Ei­gen­schaft un­ter­schei­det sich dabei nicht von der gleich­na­mi­gen HTTP-Header-In­for­ma­ti­on und liefert Werte wie den Namen, die Version und die Plattform des Browsers in der Zu­sam­men­fas­sung. Das folgende Beispiel zeigt einen möglichen Auszug: „Mozilla/5.0 (Windows NT 6.1; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0“.

Trackbare Bild­schirm­in­for­ma­tio­nen

In­for­ma­tio­nen über den Bild­schirm des Web­site­be­su­chers lassen sich ebenfalls über ein Ja­va­Script-Brow­ser­fens­ter gewinnen. Als Un­ter­ob­jekt kommt in diesem Fall das Screen-Objekt zum Einsatz, das wie schon das Navigator-Objekt zwar nicht in einem Standard spe­zi­fi­ziert ist, aber von allen gängigen Browsern un­ter­stützt wird. Bis zu fünf Display-Ei­gen­schaf­ten werden mit einem ent­spre­chen­den Skript an den Server wei­ter­ge­ge­ben:

• screen.width: Dieser Wert gibt Auf­schluss über die Ge­samt­brei­te (in Pixel) des Nutz­er­bild­schirms.

• screen.height: Die Ei­gen­schaft height teilt dem Server die Ge­samt­hö­he (in Pixel) des Nut­zer­dis­plays mit.

• screen.avail­Width: Gibt die tat­säch­lich ver­füg­ba­re Dis­play­brei­te (in Pixel) an, die dem Nutzer zur Verfügung steht. Zu diesem Zweck wird die Breite von Interface-Features wie der Windows-Taskbar vom Ge­samt­wert abgezogen.

• screen.avail­H­eight: Gibt die tat­säch­lich ver­füg­ba­re Dis­play­hö­he (in Pixel) an, die dem Nutzer zur Verfügung steht. Wie bei der ver­füg­ba­ren Breite werden hierfür die Maße von Interface-Features vom Ge­samt­wert abgezogen.

• screen.co­lor­Depth: Die Ei­gen­schaft co­lor­Depth verrät dem Webserver die Farbtiefe (Bit pro Pixel), die dem User für die Dar­stel­lung von Bildern zur Verfügung steht. co­lor­Depth ist mit der Ei­gen­schaft pi­xel­Depth gleich­zu­set­zen, die ebenfalls den Wert der Farbtiefe zu­rück­gibt, aber nicht von allen Browsern un­ter­stützt wird.

Er­mitt­lung von Zeitzone und Sys­tem­far­ben

Die Zeitzone, in der sich ein Nutzer befindet, lässt sich mithilfe der Ja­va­Script-Methode get­Ti­me­zo­ne­Off­set() ermitteln. Genau genommen gibt diese die Zeit­dif­fe­renz zwischen der UTC (Universal Coor­di­na­ted Time) und der lokalen Zeit in Minuten wieder. Als Re­fe­renz­wer­te werden die Ein­stel­lun­gen des Be­triebs­sys­tems her­an­ge­zo­gen. Ein einfaches Ja­va­Script-Dia­log­fens­ter, das die Methode im­ple­men­tiert und die Differenz prä­sen­tiert, sieht wie folgt aus:

Auch für das Tracking der Sys­tem­far­ben muss lo­gi­scher­wei­se auf die Ein­stel­lun­gen des Be­triebs­sys­tems zu­rück­ge­grif­fen werden. Damit die hierfür not­wen­di­ge Ja­va­Script-Funktion get­Com­pu­ted­Style() die vom Nutzer gewählte Optik für Fens­ter­rah­men, Schalt­flä­chen und Co. erfassen kann, ist sie jedoch auf die Un­ter­stüt­zung von CSS (Cascading Style Sheets) an­ge­wie­sen. Die Style­sheet-Sprache er­mög­licht es, Website-Elemente zu kreieren, die au­to­ma­tisch die Sys­tem­f­arb­ein­stel­lun­gen des Besuchers über­neh­men. Dabei handelt es sich im Detail um die Farb­aus­wahl für diese Sys­tem­ele­men­te:

• Rahmen des aktiven Fensters (Ac­tive­Bor­der)

• Titeltext des aktiven Fensters (Ac­tive­Cap­ti­on)

• Desk­top­hin­ter­grund (Back­ground)

• Text auf Schalt­flä­chen (But­ton­Text)

• Umrandung von 3D-Elementen (Th­reeD­High­light)

Der Webserver erhält an­schlie­ßend die ent­spre­chen­den Farbwerte bzw. Be­zeich­nun­gen der Sys­tem­far­ben und kann diese in die Er­stel­lung des Fin­ger­prints ein­flie­ßen lassen.

In­ter­net­brow­ser sind ur­sprüng­lich vor allem dazu ent­wi­ckelt worden, um einfache HTML-Dokumente inklusive einzelner Bilder an­zu­zei­gen. Im Laufe der Zeit sind die Ansprüche an die Client-Programme aufgrund der immer kom­ple­xe­ren Web­pro­jek­te al­ler­dings erheblich gestiegen: Schnell haben sich neben Me­di­en­for­ma­ten wie Audio- und Vi­deo­da­tei­en auch in­ter­ak­ti­ve Elemente etabliert. Damit die Browser diese ver­schie­de­nen Inhalte wie­der­ge­ben konnten, mussten die Ent­wick­ler die Funk­ti­ons­pa­let­te der An­wen­dun­gen erweitern. Dies tat man durch Plug-ins, die bis heute zu diesem Zweck zum Einsatz kommen. Mithilfe von Ja­va­Script lassen sich die in­stal­lier­ten Plug-ins nach­wei­sen und somit zur Be­stim­mung des Browser-Fin­ger­prints verwenden.

Adobe Shockwave Flash

Das weltweit am häu­figs­ten genutzte Plug-in ist Adobe Shockwave Flash, das benötigt wird, um Flash-Ani­ma­tio­nen wie­der­zu­ge­ben. Zudem war Flash über Jahre hinweg das vor­herr­schen­de Format für Videos im World Wide Web, was die Er­wei­te­rung – die unter anderem den Flash Player enthält – zum Pflicht­pro­gramm machte. Auch wenn dank HTML5 mitt­ler­wei­le eine ernst­zu­neh­men­de und sicherere Al­ter­na­ti­ve für das Be­reit­stel­len und die Wie­der­ga­be von Vi­deo­in­hal­ten existiert, ist das Plug-in auch weiterhin in diversen Browsern in­stal­liert. Eine Ausnahme bilden die meisten Stan­dard­brow­ser mobiler Geräte, die eine ent­spre­chen­de Er­wei­te­rung nicht anbieten. Dennoch bleibt ein Scan nach Adobe Flash, inklusive der Ver­si­ons­num­mer, ein wichtiges Element, um den digitalen Fin­ger­ab­druck eines Browsers zu prä­zi­sie­ren. Ein mögliches Skript, das zu diesem Zweck auf eine „try...catch“-Anweisung zu­rück­greift und an be­lie­bi­ger Stelle im Web­pro­jekt im­ple­men­tiert werden kann, sieht fol­gen­der­ma­ßen aus:

Die Ja­va­Script-Anwendung versucht also in einem ersten Schritt, ein neues ActiveX-Object zu erstellen (funk­tio­niert nur im Internet Explorer), das im Er­folgs­fall die Ver­si­ons­num­mer ermittelt und wei­ter­lei­tet. Schlägt dieser Vorgang fehl, greift das Skript auf das mimeTypes-Objekt zurück, das dem schon auf­ge­führ­ten Navigator-Objekt un­ter­ge­ord­net ist. Selbiges ist in der Lage, alle vom Browser un­ter­stütz­ten Da­tei­for­ma­te und Wie­der­ga­be-Plug-ins (navigator.plugins) zu ermitteln. Im Rahmen des hier genutzten Skripts gibt es Rück­mel­dung, wenn es dabei auf Shockwave Flash bzw. Shockwave Flash 2.0 stößt.

Microsoft Sil­ver­light

Ähnliche Funk­tio­na­li­tä­ten wie Shockwave Flash fügt dem Browser auch die Er­wei­te­rung Sil­ver­light von Microsoft hinzu. Das Plug-in zur Un­ter­stüt­zung in­ter­ak­ti­ver Elemente ist im All­ge­mei­nen we­sent­lich weniger ver­brei­tet als bei­spiels­wei­se Adobe Flash und wird darüber hinaus von vielen gängigen Brow­ser­ver­sio­nen nicht mehr un­ter­stützt. Für das Browser-Fin­ger­prin­ting kann sich aber genau das als wertvoll erweisen, da sich ein Browser, der dieses Plug-in in­stal­liert hat, im Um­kehr­schluss von zahl­rei­chen anderen Browsern deutlich abgrenzt. In diesem Zu­sam­men­hang kann abermals ein zwei­ge­teil­tes Skript für den Fin­ger­print-Test verwendet werden, das in diesem Fall zunächst versucht, ein ActiveX-Objekt zu in­stan­zie­ren und bei einem Fehl­schlag das Objekt navigator.plugins in­spi­ziert:

Wie bereits erwähnt, versucht der erste Teil des Skripts, ein ActiveX-Objekt zu nutzen, um Microsoft Sil­ver­light nach­zu­wei­sen. Zu diesem Zweck sind im Array „v“ die drei aktuellen Versionen (Stand: Mai 2017) des Plug-ins auf­ge­lis­tet. Die Auf­lis­tung ist die Grundlage für die Funktion „is­Ver­si­onS­up­port­ed“, die für die jeweilige Version den Wert „true“ (trifft zu) oder den Wert „false“ (trifft nicht zu) ausgibt, je nachdem, ob der über­prüf­te Client diese un­ter­stützt oder nicht. Werden ActiveX-Elemente nicht un­ter­stützt, un­ter­sucht das Skript statt­des­sen das Objekt navigator.plugins.

Alle in­stal­lier­ten Plug-ins und un­ter­stüt­zen Da­tei­for­ma­te über­prü­fen

Die zwei bereits vor­ge­stell­ten Skripte sind für die Erfassung der beiden wich­tigs­ten Plug-ins geeignet und der einzige Weg, um diese Er­wei­te­run­gen bei einem User des Internet Explorers fest­zu­stel­len.

Für alle Browser, die das navigator.plugins-Objekt un­ter­stüt­zen, gibt es jedoch eine weitere Mög­lich­keit, die dem Browser-Fin­ger­print nicht nur In­for­ma­tio­nen über Shockwave Flash und Microsoft Sil­ver­light, sondern über alle in­stal­lier­ten Browser-Plug-ins hinzufügt – wiederum per „try...catch“-Anweisung:

Das Navigator-Un­ter­ob­jekt „plugins“ wird mit diesem Skript also nach in­stal­lier­ten Plug-ins inklusive Name („name“), Be­schrei­bung („de­scrip­ti­on“) und Dateiname („filename“) durch­sucht.

Auf dem gleichen Weg können auch alle Formate, die der jeweilige Client un­ter­stützt, für das Browser-Fin­ger­prin­tings ana­ly­siert werden. Denn dies­be­züg­lich gibt es durchaus Un­ter­schie­de – bei­spiels­wei­se auf un­ter­schied­li­chen Geräten – weshalb die ge­won­ne­nen Werte in vielen Fällen zur Spe­zi­fi­zie­rung des Fin­ger­ab­drucks beitragen können. Statt auf das Objekt „plugins“ muss das Skript al­ler­dings auf das bereits erwähnte Objekt „mimeTypes“ zugreifen:

Wie bereits erwähnt, lässt sich mithilfe von CSS und Ja­va­Script gezielt über­prü­fen, ob bestimmte Schrift­ar­ten auf dem Be­triebs­sys­tem des un­ter­such­ten Clients in­stal­liert sind. Das Wissen über vor­han­de­ne Fonts ist dabei aus mehreren Gründen in­ter­es­sant, die zum Teil sogar über die bloße Er­mitt­lung des digitalen Fin­ger­ab­drucks hin­aus­ge­hen. Unter anderem kann ein Blick auf die Schrift­ar­ten folgende Er­kennt­nis­se liefern:

• Er­mitt­lung der Software durch die die jeweilige(n) Schrift­art(en) in­stal­liert wurde, wie bei­spiels­wei­se Mi­cr­ro­soft Office oder Adobe Creative Cloud

• Er­mitt­lung der Software, mit der ein eigener Font (z. B. die per­sön­li­che Hand­schrift) erstellt wurde

• Rück­schlüs­se über Vorlieben und In­ter­es­sen des Client-Nutzers, bei­spiels­wei­se aufgrund von Partei-Schrift­ar­ten, Logos oder the­men­spe­zi­fi­schen Zei­chen­sät­zen

Die kurze Auf­lis­tung zeigt, dass solche Schrift­ar­ten-Un­ter­su­chun­gen nicht nur zur Spe­zi­fi­zie­rung des Fin­ger­prints beitragen, sondern auch für die Er­stel­lung ziel­ge­rich­te­ter Wer­be­kam­pa­gnen von Nutzen sein können. Dabei gilt natürlich: Je mehr der in­stal­lier­ten Fonts bekannt sind, desto bessere Er­geb­nis­se lassen sich bei der Analyse erzielen. Während mit CSS immer nur einzelne Schriften ermittelt werden können, ist es mit einer Flash-Anwendung (.swf) und der Ja­va­Script-Funktion re­ceiv­e­Fonts() möglich, das voll­stän­di­ge Font-Arsenal abzurufen und auf­zu­lis­ten. Der dafür not­wen­di­ge Code des Flash-Objekts (Ac­tion­S­cript) sieht fol­gen­der­ma­ßen aus:

Die Ein­bin­dung in das HTML-Dokument gelingt mit diesem Code, den es in den Body-Bereich ein­zu­fü­gen gilt:

Web­diens­te wie Social-Media-Platt­for­men setzen in der Regel voraus, dass der zu­grei­fen­de Nutzer über ein spe­zi­fi­sches Nut­zer­kon­to verfügt und sich mit diesem auch an­ge­mel­det hat. An­dern­falls bleibt ihm ein Großteil der Res­sour­cen verborgen, die der jeweilige Dienst zur Verfügung stellt – ein Umstand, den man sich bei der Er­stel­lung des Browser-Fin­ger­prints zu Nutze machen kann. Zu diesem Zweck muss lediglich eine Ressource des Dienstes, auf die nur an­ge­mel­de­te User zugreifen können, bekannt sein und im Rahmen eines DOM-Elements in das zu über­prü­fen­de Web­pro­jekt ein­ge­bun­den werden.

Der Typ des Elements ist dabei zweit­ran­gig, denn die ent­schei­den­den Kom­po­nen­ten, die Er­eig­nis­se onload() und onerror(), können in zahl­rei­chen HTML-Be­stand­tei­len wie zum Beispiel <img />,<frame /> oder <script /> ein­ge­setzt werden. Dort werden sie ausgelöst, wenn die verlinkte Ressource geladen wurde bzw. nicht geladen werden konnte, woraufhin der Webserver eine ent­spre­chen­de Be­nach­rich­ti­gung erhält. Ein bei­spiel­haf­tes <img>-Element, das den Log-in-Status bei Twitter überprüft, erzeugt man mit den folgenden Code­zei­len – wobei man beachten sollte, dass sich die URL jederzeit ändern kann:

Der Ratgeber zeigt, welche weit­grei­fen­den Tracking-Mög­lich­kei­ten gut kon­zi­pier­tes Browser-Fin­ger­prin­ting bietet – und damit auch, wie schnell man als Nutzer selbst ohne Cookies wie­der­erkannt und zu­rück­ver­folgt werden kann. Ob bzw. wie ein­zig­ar­tig der Fin­ger­ab­druck des eigenen Browsers ei­gent­lich ist, wird wohl nur den wenigsten bewusst sein. Dabei gibt es ver­schie­de­ne Web-Tools wie AmIUnique oder Pan­op­ticlick, mit denen man die Un­ver­wech­sel­bar­keit des eigenen Browser-Fin­ger­prints mit nur einem Klick testen kann. Wenn Sie sich also Klarheit ver­schaf­fen und Ihren Browser bei­spiels­wei­se mit erst­ge­nann­tem AmIUnique testen wollen, rufen Sie den Service einfach über die gleich­na­mi­ge Web­adres­se amiunique.org auf und klicken auf die Schalt­flä­che „View my browser fin­ger­print“. Nach­fol­gend findet eine kurze Über­prü­fung Ihres Web­brow­sers statt, wodurch dieser mit über 370.000 anderen Browsern (Stand: Mai 2017) ver­gli­chen wird.

Bei den zunächst prä­sen­tier­ten Werten handelt es sich nicht um die einzigen Daten, die das Web-Tool überprüft und in den Browser-Fin­ger­print ein­flie­ßen lässt. Über die Buttons „Click here“ oder „View more details“ gelangen Sie zu der de­tail­lier­ten Ge­samt­über­sicht aller In­for­ma­tio­nen, die zur Be­stim­mung der Ein­zig­ar­tig­keit bei­getra­gen haben. Unter anderem finden Sie hier auch die im Ratgeber er­läu­ter­ten Werte – wie die ak­zep­tier­ten In­halts­ty­pen, mögliche Kom­pres­si­ons­me­tho­den, die Bild­schirm­auf­lö­sung oder die Cookie-Akzeptanz.

Es lässt sich nicht gänzlich ver­hin­dern, dass der digitale Fin­ger­ab­druck Ihres In­ter­net­brow­sers ermittelt wird – die beim passiven Fin­ger­prin­ting au­to­ma­tisch über­tra­ge­nen Merkmale im HTTP-Header erhält der Betreiber des Web­ser­vers in jedem Fall. Sie können jedoch versuchen, den Wie­der­erken­nungs­wert Ihres Clients so gering wie möglich zu halten, damit der Fin­ger­ab­druck nicht ein­zig­ar­tig und somit für das Tracking nicht zu ge­brau­chen ist. Die ein­fachs­te Lösung ist dabei der Einsatz einer Browser-Er­wei­te­rung, die aktive Inhalte wie Ja­va­Script-, Flash oder Sil­ver­light-An­wen­dun­gen au­to­ma­tisch blockiert, wodurch diese lo­gi­scher­wei­se auch keine In­for­ma­tio­nen an den Server wei­ter­ge­ben können. Diese Plug-ins, zu denen bei­spiels­wei­se NoScript für Firefox oder Script­Block für Chrome zählen, sind nebenbei auch der optimale Schutz gegen das immer häufiger ein­ge­setz­te Canvas-Fin­ger­prin­ting. Diese Unterart des Browser-Fin­ger­prin­tings versucht, den Client gezielt durch den Einsatz von Canvas-Elementen zu tracken. Dabei wird der Umstand genutzt, dass das Rendering von Text in diesen Elementen je nach Be­triebs­sys­tem, Browser, Gra­fik­kar­te, Treiber und Fonts stark variiert. Wenn Sie solche Plug-ins ak­ti­vie­ren, müssen Sie al­ler­dings damit rechnen, dass bestimmte Web­ser­vices oder zumindest einzelne Inhalte nicht mehr funk­tio­nie­ren. Zwar erlauben die Er­wei­te­run­gen, Inhalte oder Websites gezielt auf Fil­ter­lis­ten zu setzen, um die Skript-Blo­ckie­rung aus­zu­set­zen – dies ist jedoch wenig hilfreich, wenn man sich als Nutzer unsicher ist, ob der Anbieter ver­trau­ens­wür­dig ist oder nicht. Zudem ist an dieser Stelle darauf hin­zu­wei­sen, dass auch die Nutzung eines solchen Blockers ein Merkmal darstellt, das direkt für die Spe­zi­fi­zie­rung des digitalen Fin­ger­ab­drucks verwendet werden kann. Abseits der Skript-Blocker-Lösung bleibt Ihnen im Grunde genommen nur übrig, auf In­di­vi­dua­li­sie­run­gen von System und Browser zu ver­zich­ten. Ent­schei­den Sie sich für einen häufig genutzten Browser (in Deutsch­land z. B. Firefox) und greifen Sie möglichst auf die Stan­dard­ein­stel­lun­gen zurück. Gleiches gilt natürlich auch für das ver­wen­de­te Be­triebs­sys­tem. Ver­zich­ten Sie darüber hinaus auf zu­sätz­li­che Er­wei­te­run­gen für Ihren Client, haben Sie gute Chancen, dass Sie keinen ein­zig­ar­ti­gen Fin­ger­ab­druck erzeugen und gut gegen Track­ing­ver­fah­ren gewappnet sind. Als Smart­phone-Nutzer sind Sie un­ter­des­sen, ins­be­son­de­re mit älteren Modellen, noch wei­test­ge­hend sicher – dank der Tatsache, dass bei Smart­phones aktuell nur wenige In­di­vi­dua­li­sie­rungs­mög­lich­kei­ten für Browser und System bestehen.