In der 10. Klasse treibt man SQL und Datensicherheit, und beides lässt sich schön mit Firefox demonstrieren. Die Schülerinnen und Schüler können ihre eigene Browser-Vergangenheit und, wohl spärlicher, ihre Lesezeichen mit SQL-Abfragen durchsuchen.

Einführung

Firefox speichert seine Informationen in einem Profilordner. Das ist praktisch, wenn man von einem Rechner zu einem anderen umzieht: dann muss man nur den Profilordner mitnehmen und kann dann in einem neuen Firefox mit dem gleichen Profil arbeiten, egal ob Linux oder Windows oder MacOS. (Der Profilordner ist übrigens standardmäßig an einem Ort, von dem ich keine Backups mache, also habe ich einen anderen Ort dafür eingestellt.)

Unter anderem speichert Firefox Informationen in den Dateien places.sqlite und cookies.sqlite. Die erste Datei enthält alles über besuchte Webseiten und Lesezeichen, die zweite alle über die gespeicherten Cookies. Die Dateinamen-Endung deutet bei beiden darauf hin, dass es sich um SQLite-Dateien handelt, also ein Datenbankformat. Wie schön, dass in der 10. Klasse sowohl SQL-Datenbanken als auch Datensicherheit und Tracking Thema sind! Da bietet es sich doch an, einmal mit diesen Dateien zu spielen.

Richtig Neues wird man nicht erfahren. Alle Informationen kriegt man einfacher, indem man einfach im Browser die Lesezeichenverwaltung benutzt beziehungsweise auf das Burger-Menü klickt, dann Einstellungen/Privatsphäre und Sicherheit, und sich dann zu den Cookies durchfragt. Aber es geht ja auch darum, was da technisch im Hintergrund abläuft.

Ein erstes Beispiel und ein Exkurs

Man kann diese Datenbank-Dateien auch außerhalb von Firefox öffnen. Mit Access oder Base geht das leider nur nach Installation zusätzlicher Verbindungssoftware, aber es gibt webbasierte Software und vor allem portable Programme wie SQLite Browser. Darin kann man dann SQL-Abfragen zu den in der Datei gespeicherten Daten stellen, etwa:

SELECT moz_bookmarks.title, moz_keywords.keyword
FROM moz_bookmarks, moz_keywords
WHERE moz_bookmarks.fk = moz_keywords.place_id

Diese Abfrage bedeutet:
Nenne mir die Titel aller Lesezeichen (die in der Tabelle moz_bookmarks gepeichert sind) und aller Keywords (die in der Tabelle moz_keywords gepeichert sind), sofern die Lesezeichen mit den Keywords etwas zu tun haben. Die Ergebnistabelle sieht so aus:

title	keyword
Wikipedia Deutsch	wde
WIkipedia Englisch	wen
Duckuckgo	d
Google Verbatim	gg
Google	g
Youtube	yt
Wiktionary deutsch	wikde
Wiktionary Englisch	wiken
woxikon	syn
Amazon DE	a
Duden	du
Herr Rau Suchfenster	hr
Suchen mit &udm=14 | the disenshittification Konami code | GOOGLE GOOD	ggg
Suchen mit MetaGer – Mehr als eine Suchmaschine	m
Urban Dictionary	ud

Keywords sind eine Eigenschaft von Firefox-Lesezeichen, eine Art selbst vergebene Abkürzungen. Dem Lesezeichen mit dem Titel „Wikipedia Deutsch“, dessen Adresse natürlich auch gespeichert ist, aber hier nicht abgefragt wurde, entspricht das selbst vergebene Keyword „wde“. Das führt dazu, dass ich in der Such- und Adresszeile des Browsers eingeben kann „wde Julie Andrews“, und dann lande ich gleich auf der Wikipediaseite zu Julie Andrews. (Den Tipp mit den Keywords habe ich von Kathrin Passig aus dem Techniktagebuch.)

Unter „Google Verbatim“ mit dem Keyword „gg“ findet sich übrigens die wortgetreue Googlesuche. Die tatsächliche Adresse kann ich mir nicht merken, man muss sich dorthin klicken, und das Lesezeichen finde ich nicht immer, aber wenn ich „gg Grmblhx“ eintippe, wird automatisch dieses Lesezeichen benutzt, das mir tatsächlich nur die Fundorte mit exakt der Zeichenkette „Grmblhx“ darin ausgibt, genau so, wie man glaubt, dass das früher auch immer funktioniert hat. Zum Ausprobieren: „gg grmblhx“ im Gegensatz zu „g grmblhx„. – Wenn ich „a christmas carol“ suche, wird allerdings automatisch bei Amazon gesucht, da muss ich über die Wahl meines Keyword-Kürzels noch einmal nachdenken. (Und: ggg führt zu einer Google-Suche *ohne* KI-Verschlimmbesserungen. Das kann man nämlich auswählen, jedenfalls noch.)

Zurück zu den Datenbank-Dateien

Die Datei places.sqlite

Die Datei places.sqlite enthält etliche Datenbanktabellen. Hier sind drei wichtige, wobei ich auch hier nur einige wichtige Attribute anführe:

Die Tabelle moz_places ist zentral, sie enthält alle gespeicherten Adressen. Dabei ist es vorerst irrelevant, ob es sich um Adressen handelt, die zusätzlich als Lesezeichen gespeichert sind oder alle in letzter Zeit besuchten Adressen. Zu jeder Adresse wird der URL gespeichert, der Titel der Seite (der oft NULL ist) und eine Beschreibung (sofern vorhanden), der Zeitpunkt des letzten Besuchs, die Anzahl der Besuche seit dem letzten Zurücksetzen und die „frecency“, Portmanteau und irgendwie verrechnete Kombination aus frequency und recent. Ich weiß es nicht, aber vielleicht dient die frecency dazu zu entscheiden, welche von mehreren passenden URLs zur Autovervollständigung in der Adresszeile vorgeschlagen wird, wenn man anfängt, eine Adresse zu schreiben?

Die tatsächlichen Lesezeichen sind in der Tabelle moz_bookmarks gespeichert, die aber selber gar keine URL-Adressen verwaltet. Aber ein Tabelleneintrag dort hat mit einem Fremdschlüssel im Attribut fk (für: foreign key) eine Referenz auf eine in moz_places gespeicherte Adresse. Außerdem gibt es eine Referenz auf ein Keyword, siehe oben, die allerdings meist NULL sein dürfte. – Das Attribut title bezeichnet dabei entweder den Namen des Lesezeichens, oder den Namen des Verzeichnisses (wenn es sich beim Eintrag um ein solches handelt), oder den Namen des Schlagwort (wenn es sich beim Eintrag um ein solches handelt).

Die zuletzt besuchten 10 URLs:

SELECT moz_places.title, moz_places.url
FROM moz_places
WHERE moz_places.last_visit_date NOT NULL
ORDER BY moz_places.last_visit_date DESC
LIMIT 10

Die am häufigsten besuchten 10 URLs:

SELECT moz_places.title, moz_places.url, moz_places.visit_count
FROM moz_places
ORDER BY moz_places.visit_count DESC
LIMIT 10

Die relevantesten 10 URLs:

SELECT moz_places.title, moz_places.url, moz_places.frecency
FROM moz_places
ORDER BY moz_places.frecency DESC
LIMIT 10

Alle Lesezeichen samt URL dazu, bei denen im Namen des Lesezeichens „Douglas Adams“ erscheint:

SELECT moz_bookmarks.title, moz_places.url
FROM moz_places, moz_bookmarks
WHERE moz_places.id = moz_bookmarks.fk
AND moz_bookmarks.title LIKE "%Douglas Adams%"

Intern arbeitet Firefox so ähnlich. Wenn ich bei der Lesezeichen-Verwaltung nach „elephant“ suche, sehe ich das:

Intern steckt eine Abfrage wie diese dahinter, die mir das gleiche Ergebnis liefert:

Zugegeben: Meine Abfrage durchsucht nur die Namen der Lesezeichen nach „elephant“, wärend die Firefox-Abfrage zusätzlich die Namen von Schlagwörtern und die URLs durchsucht. Das geschieht auch mit SQL, aber diese Abfrage gestaltet sich etwas schwieriger. Denn:

Die Sache mit den Schlagwörtern

Jaaaaaa… schwieriger zu vermitteln, würde ich in der Schule weglassen. Das Attribut parent gibt in moz_bookmarks zum einen an, wo das Lesezeichen gespeichert ist: im Lesezeichenmenü oder in der Toolbar oder in Weitere Lesezeichen. Und der Attributwert von fk entscheidet darüber, ob das Lesezeichen am Ende gar kein Lesezeichen ist, sondern ein Schlagwort oder ein Verzeichnis für Lesezeichen.

• parent = 2 heißt, das Element ist im Lesezeichenmenü gespeichert
• parent = 3 heißt, das Element ist in der Toolbar gespeichert
• parent = 4 heißt, das Element ist ein Schlagwort
• parent = 5 heißt, das Element ist unter „Other Bookmarks“ gespeichert.
• parent > 5 heißt, das Element gehört zum Schlagwort oder Verzeichnis mit der entsprechenden id (in derselben Tabelle)
• Element kann sein: Ein echtes mit einer Adresse assoziiertes Lesezeichen (dann ist der Wert von fk eine Zahl, nämlich ein Fremdschlüssel für moz_places.id), oder ein Verzeichnis oder Schlagwort, das nur dazu da ist, Elemente zu verwalten (dann hat den Wert NULL).

Diese Konstruktion führt auch dazu, dass wenn ich ein Lesezeichen in 1 Verzeichnis einordne und mit 2 Schlagwörtern versehe, dass dann das Lesezeichen in drei Datensätzen in moz_bookmarks auftaucht: Einmal mit Titel und als an einem konkreten Ort gespeichert (parent = 49, wobei 49 die id des Verzeichnisses ist) und einmal mit parent = 2104 (das eine Schlagwort) und einmal mit parent = 2613 (das andere Schlagwort). Bei den letzten Einträgen ist das Attribut title NULL, womit immerhin Redundanz halbwegs vermieden wird. Richtig sauber wäre nämlich eine eigene Beziehungstabelle für die n:m-Beziehung zwischen Lesezeichen und Schlagwort, aber vielleicht aus Performanzgründen macht man das hier ohne.

Die Datei cookies.sqlite

Die Datei cookies.sqlite enthält eine Tabelle, moz_cookies, hier wieder ein gekürztes Klassendiagramm:

Ein Cookie ist eine kurze Textdatei in einem bestimmten Format. Wenn man eine Webseite besucht, kann diese dem Browser anbieten, einen solchen Cookie mitzuschicken. Den Cookie speichert der Browser dann und schickt wiederum beim nächsten Besuch der Webseite diesen Cookie, also diese kleine Textdatei, mit. Der Server kriegt den Cookie und kann anhand dessen und der beim Server gespeicherten Daten darüber zum Beispiel erkennen, dass der Benutzer schon einmal da war, oder dass man ihn als eingeloggt betrachten sollte (dann muss der Benutzer keine Zugangsdaten mehr eingeben) und seinen Benutzernamen.

Firefox speichert diese Cookies nicht als separate Textdateien, die umständlicher zu verwalten und zu durchsuchen wären, sondern in der oben genannten Datenbanktabelle. Die Datensätze dazu sehen so aus (Ausschnitt):

Wenn Facebook einen Cookie setzt, kann Instagram den auslesen, und umgekehrt, weil die beiden Seiten kooperieren; sie gehören ja zum gleichen Konzern. Und wer weiß, welche Firma noch alles. So kann ein Profil erstellt werden, man kann mitzählen, wer wann wie oft welche Seiten besucht. Passt zum Lehrplan in Informatik 10, wo es um das Zusammenführen von Informationen geht, und was man damit machen kann.

(Neben Cookies, die man noch halbwegs kontrollieren kann, gibt es natürlich noch weitere Möglichkeiten zum Tracking. Auch ein spannendes Thema.)

Passwörter?

Die Passwörter sind in logins.json gespeichert, allerdings in verschlüsselter Form. Der Schlüssel ist in key4.db gespeichert, auch einer SQLite-Datei, aber in keinem unmittelbar verwendbaren Format. Mit ziusätzlicher Software kann man das wohl zusammenführen.

Tatsächliche Speicherung der Daten

In der 12. Jahrgangsstufe geht es gerade um Bäume, genauer: geordnete Binärbäume. Auch Datenbanken speichern ihre Daten intern in Bäumen, insbesondere nutzt SQLite dazu B-Bäume und (wie ich mir angelesen habe) B+-Bäume. Da könnte man also auch anknüpfen, aber das wäre wieder eigenes Thema.

(Gerne auf technische und Tippfehler hinweisen, da sind bestimmt einige drin.)