I really like ModPagespeed, a module for Apache and nginx that rewrites HTML and resources on the fly to reduce page loading time, layout shifts, etc. Sadly, its development has been discontinued (there’s a branch by one of the main developers, but it doesn’t seem to be alive, either). Even though it may not support every modern HTML or CSS feature, it still works quite well and can be very useful.

One annoying issue I came across is that inlining an image element has an unwanted side-effect. For example, take this image:

<img src="image.png" width="100" height="100">

When ModPagespeed inlines it, this element becomes:

<img src="data:image/png;base64,[...]">

ModPagespeed deletes the width and height attributes if their values match the image’s actual dimensions. The reasoning behind this is that the image’s dimensions are readily available in the data URI. While that’s true, the browser still has to decode the image before knowing the dimensions. It must convert Base64 to binary and then decode the actual image, and modern browsers do this asynchronously. So if the width and height attributes are not specified (or, in this case, have been deleted), the browser doesn’t immediately know the image’s dimensions and cannot allocate space for it in the layout. Consequently, the layout may shift once the decoding is done and the image dimensions are available. In fact, PageSpeed Insights complains about the missing dimensions.

As mentioned in the issue on GitHub, the culprit is the call to the DeleteMatchingImageDimsAfterInline function, which does exactly what its name suggests. Since ModPagespeed is no longer maintained, I decided to fix this myself, thinking that it should be quite easy to remove that call. Unfortunately, building ModPagespeed from source seems to be a complex task, which I didn’t even try (Edit: I did it, see this post!), so my next best option was to apply the fix directly to the binary file. I disassembled the .so file using Binary Ninja. Finding the correct address was difficult using the binary I had on my system, because all symbols (function names) had been stripped. To my luck, ModPagespeed provides unstripped binaries as well in its release archive. In particular, the fix I’m describing here applies to version 1.13.35.1 for Apache. While I haven’t checked the few newer binaries or the binaries for nginx, I’m quite sure that the fix will work there, too.

The C++ code

// Never strip width= or height= attributes from non-img elements.
if (element->keyword() != HtmlName::kImg) {
    return;
}

// (The code that follows ultimately removes the width and height attributes.)

at the beginning of the DeleteMatchingImageDimsAfterInline function, which has been inlined by the compiler, translates to the following x86 instructions:

498b4610           mov     rax, qword [r14+0x10]
8378086c           cmp     dword [rax+0x8], 0x6c
0f84ff030000       je      0x5143e0

The cmp instruction checks whether the element is an <img>, and if so, jumps (je) to the part of the code that ultimately deletes the width and height attributes. So if we can prevent this jump, the attributes will stay.

All that’s needed is to „delete“ the je instruction. But we can’t just delete the 6 bytes that make up the instruction, as this would offset all following code, and other jumps would end up jumping to the wrong address. The easy way to effectively delete the instruction is to overwrite it with nop instructions. On x86, nop is just a single byte, 0x90. So we replace the bytes 49 8b 46 10 83 78 08 6c 0f 84 ff 03 00 00 with the bytes 49 8b 46 10 83 78 90 90 90 90 90 90.

I made sure that ModPagespeed’s .so file only contains a single occurrence of this byte pattern. This is how I performed the actual replacement:

MODULE_PATH=(insert the path to your ModPagespeed .so file here)

# Make a backup copy of the original .so file.
cp -p "$MODULE_PATH" "$MODULE_PATH".original

# Patch the module.
xxd -p -c 1 "$MODULE_PATH" | tr -d '\n' | sed 's/498b46108378086c0f84ff030000/498b46108378086c909090909090/g' | fold -w 1 | xxd -r -p -c 1 - "$MODULE_PATH".patched
chown --reference="$MODULE_PATH" "$MODULE_PATH".patched
chmod --reference="$MODULE_PATH" "$MODULE_PATH".patched

# Print the changed bytes.
diff --changed-group-format='%<' --unchanged-group-format='' <(xxd -p -c 1 "$MODULE_PATH") <(xxd -p -c 1 "$MODULE_PATH".patched)

Now make sure that the last output shows exactly 6 bytes, they should be:

0f
84
ff
03
00
00

If that's the case, we can stop Apache (or nginx), replace the module and start the web server again:

apache2ctl stop
sleep 10
mv "$MODULE_PATH".patched "$MODULE_PATH"
apache2ctl start

When testing, remember that ModPagespeed can take some time until resources are optimized. If everything works, you should now see inlined images like this:

<img src="data:image/png;base64,[...]" width="100" height="100">

Enjoy!

In the future, I might invest some more time into trying to build ModPagespeed from source - there's at least one more thing I'd like to fix ...

Edit: I did that, see this post.

Kürzlich musste ich feststellen, dass das Aktualisieren von WordPress auf einem Server, der nur über einen Proxy nach draußen kommunizieren kann, ziemlich problematisch sein kann. Eigentlich liest man überall, dass es ausreicht, in der Datei wp-config.php die beiden Optionen WP_PROXY_HOST und WP_PROXY_PORT korrekt zu setzen. In meinem Fall war das nicht genug. WordPress konnte dann zwar Informationen über verfügbare Aktualisierungen und Plug-ins abrufen, diese jedoch nicht herunterladen („Download fehlgeschlagen“). Nach schier endlosem Herumprobieren und Suchen fand ich schließlich den entscheidenden Hinweis: Man muss das Paket php-curl installieren. Danach klappte alles prima.

Ein wichtiger Hinweis im Voraus: Allein durch die hier dargestellten Methoden hat man nicht automatisch alle Vorgaben der DSGVO erfüllt – dazu gehört deutlich mehr! Ich möchte hier nur ein paar Tipps geben, wie gewisse Teilprobleme ohne viel Aufwand gelöst werden können.

Da in knapp einem Monat die neue Datenschutz-Grundverordnung (DSGVO) bzw. General Data Protection Regulation (GDPR) zur Anwendung kommt, muss sich so manch ein Webmaster Gedanken darüber machen (idealerweise bereits gemacht haben), wie er seinen PHP-Anwendungen (WordPress, CMS, Forum, Wiki, …) beibringt, nicht mehr die IP-Adressen der Besucher zu speichern. Die DSGVO definiert IP-Adressen nämlich explizit als personenbezogen. Sofern man sich nicht glaubhaft auf ein berechtigtes Interesse berufen kann, sollte man diese Adressen somit lieber nicht unnötigerweise speichern. Je weniger man speichert, desto weniger Angst muss man vor eventuellen Bußgeldern haben und desto weniger Schaden kann bei einem Datendiebstahl entstehen.

Nun kann man entweder für jede seiner Anwendungen ein Plug-in suchen oder selber schreiben, oder man versucht es gleich mit einem radikaleren Ansatz. Zumindest für PHP-Anwendungen gibt es eine sehr einfache und „idiotensichere“ Lösung, und zwar die php.ini-Variable auto_prepend_file. Wenn man hier eine PHP-Datei einträgt, dann wird diese am Anfang jedes ausgeführten PHP-Skripts geladen, so als ob sie mit require() eingebunden worden wäre. Und genau das können wir nutzen, um die Variable $_SERVER["REMOTE_ADDR"], in der PHP die IP-Adresse des Besuchers ablegt, zu verändern, bevor die PHP-Anwendung sie zu Gesicht bekommt. Also schreiben wir in unsere php.ini oder eine spezielle Datei im conf.d-Verzeichnis:

auto_prepend_file = /pfad/zur/anonymize_ip.php

Die Datei anonymize_ip.php enthält den Code, der die IP-Adresse anonymisiert, indem das letzte Oktett auf 0 gesetzt wird (mein Server unterstützt noch kein IPv6, also behandle ich erst einmal nur IPv4-Adressen – wer IPv6 unterstützt, der sollte den Code anpassen und einen deutlich größeren Teil der Adresse auf 0 setzen):

<?php

if (isset($_SERVER["REMOTE_ADDR"]))
{
    $ip = $_SERVER["REMOTE_ADDR"];
    $_SERVER["ORIGINAL_REMOTE_ADDR"] = $ip;
    $octets = explode(".", $ip);
    if (count($octets) == 4)
    {
        $octets[3] = "0";
        $_SERVER["REMOTE_ADDR"] = implode(".", $octets);
    }
}

?>

Auf diese Weise muss man die PHP-Anwendung nicht anpassen. Sie bekommt von vornherein nur eine gekürzte IP-Adresse zu Gesicht, die dann nicht mehr personenbezogen ist. Man muss also nicht mühsam alle Stellen suchen, an denen die Anwendung die IP-Adresse benutzt. Den Trick mit dem Kürzen der IP-Adresse benutzt übrigens auch Google Analytics, um die Datenschützer zufriedenzustellen. Probleme mit den PHP-Anwendungen sind dabei eigentlich nicht zu erwarten, denn die gekürzten IP-Adressen sind immer noch gültig, und es ist sowieso nicht unüblich, dass mehrere Besucher unter derselben IP-Adresse unterwegs sind (Universitäten, Firmen, …). Und falls man in gewissen Fällen doch mal die komplette IP-Adresse benötigt, dann kann man immer noch über $_SERVER["ORIGINAL_REMOTE_ADDR"] auf sie zugreifen.

Doch was ist mit den Server-Logdateien? In der Standardkonfiguration loggen Webserver wie Apache jede Anfrage in einer Logdatei. Das sieht dann beispielsweise so aus:

89.245.114.71 - - [27/Apr/2018:16:49:53 +0200] "GET /impressum-datenschutz/ HTTP/1.1" 200 10408 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36"

Auch hier wird die IP-Adresse gespeichert (im Beispiel meine eigene, also darf ich das), und das ist möglicherweise problematisch. Hier gibt es mehrere Lösungen:

• Die meisten Webserver (wenigstens Apache und nginx) erlauben die Änderung des Logformats. Möchte man keine IP-Adressen loggen, dann ist das kein Problem – man lässt das entsprechende Feld einfach weg.
• Möchte man nicht komplett auf IP-Adressen verzichten, sondern sie in gekürzter Form (so wie oben beschrieben) loggen, dann geht das auch – zumindest mit Apache. Man kann nämlich Piped Logs benutzen. Anstatt in eine Datei zu loggen, wird ein separater Prozess gestartet, der die Logzeilen über seine Standardeingabe erhält. Nun muss man nur ein kleines Tool schreiben, das Zeile für Zeile liest, die IP-Adressen kürzt und das Ergebnis in eine Logdatei schreibt.
• Bei den Server-Logdateien stehen die Chancen gut, dass man sich auf ein berechtigtes Interesse berufen kann, um die IP-Adressen zumindest für eine begrenzte Zeit in ungekürzter Form zu speichern, denn sie bieten mehr oder weniger die einzige Möglichkeit, Angriffe nachvollziehen und gegen sie vorgehen zu können. Man könnte sich also ein kleines Programm schreiben, das über einen Cronjob jeden Tag über die Logdateien läuft und bei allen Einträgen, die älter sind als z. B. eine Woche, die IP-Adressen kürzt. In Verbindung mit Logrotation ist das besonders einfach.

Ich hoffe, dieser Artikel konnte bei dem einen oder anderen die DSGVO-Kopfschmerzen zumindest ein bisschen lindern.

Ich wollte mir schon seit langer Zeit ein Tool schreiben, mit dem ich meine Apache-Logs mehr oder weniger in Echtzeit analysieren kann (z. B. um Angriffe zu erkennen). Mein erster Ansatz wäre zunächst gewesen, alle paar Minuten ein Skript laufen zu lassen, das alles, was seit dem letzten Lauf in die Log-Dateien geschrieben wurde, verarbeitet. Aber so richtig schön wäre das nicht gewesen, ginge das doch unnötigerweise über das Dateisystem. Das Rotieren der Log-Dateien hätte ebenfalls speziell behandelt werden müssen.

Dann sah ich, dass mit der CustomLog-Direktive von Apache nicht nur normale Dateien als Log-Ziel angegeben werden können, sondern es auch möglich ist, die Log-Ausgaben über eine Pipe in einen anderen Prozess zu leiten („Piped Logs“). Dazu gibt man den Pfad zur ausführbaren Datei eines Programms an, das von Apache gestartet wird und dann die Log-Ausgaben über seine Standardeingabe erhält, zum Beispiel so:

CustomLog "||/pfad/zum/programm" "<%h|%D>"

Der zweite Teil der Direktive definiert das Log-Format. Im Beispiel werden nur die IP-Adresse des Aufrufers und die zur Verarbeitung benötigte Zeit geloggt. Das ist noch ein Vorteil gegenüber der Analyse von Log-Dateien: Man kann genau auswählen, welche Daten man zur Echtzeitverarbeitung benötigt. Warum ich die Zeichen < und > am Anfang und am Ende benutze, erläutere ich weiter unten.

Nun könnte man die Log-Ausgaben direkt in diesem einen Programm verarbeiten. Jedoch wird für jeden Apache-Elternprozess eine separate Instanz dieses Programms gestartet, also laufen normalerweise viele davon parallel. Das würde es schwierig machen, die Daten zusammenzuführen.

Um eine zentrale Verarbeitung zu ermöglichen, erstelle ich ein FIFO (mkfifo) und starte ein separates Auswertungsprogramm, das stets im Hintergrund läuft. Das Programm, das von Apache gestartet wird, wird nur zum Sammeln der Daten benutzt und heißt daher von nun an „Sammelprogramm“. Alle Instanzen des Sammelprogramms schreiben ins FIFO, und das Auswertungsprogramm liest daraus und analysiert die Daten.

Ein paar Hinweise, falls das jemand nachbauen möchte:

• Da viele Instanzen des Sammelprogramms parallel laufen werden, sollte man es möglichst speichersparend implementieren. Ich habe dafür C++ genommen statt wie üblich Python.
• Wenn das Auswertungsprogramm nicht läuft (z. B. weil es abgestürzt ist), werden die Sammelprogramme irgendwann hängen bleiben. Das ist nicht gut, weil dann auch der jeweilige Apache-Prozess beim Loggen hängen bleibt. Zum Glück kann man die Situation erkennen, indem man das FIFO nicht-blockierend öffnet (in C/C++ mit dem Flag O_NONBLOCK). Das Öffnen schlägt dann einfach fehl statt zu blockieren.
• Das Auswertungsprogramm sollte das FIFO zuerst zum Lesen öffnen und danach zusätzlich auch zum Schreiben. Somit verhindert man, dass es irgendwann keinen Prozess mehr gibt, der das FIFO zum Schreiben geöffnet hat (dann passieren seltsame Dinge).
• Wenn mehrere Prozesse parallel in ein FIFO schreiben (so wie es hier der Fall ist), ist es nur unter gewissen Umständen garantiert, dass die Daten jeweils am Stück geschrieben werden. Theoretisch kann es passieren, dass das Auswertungsprogramm zuerst einen Teil der von Prozess A geschriebenen Daten liest und dann einen Teil der von Prozess B geschriebenen Daten („interleaved“). Um solche Fälle zu erkennen, verwende ich die Zeichen < und > am Anfang und am Ende jeder ins FIFO geschriebenen Zeile. Somit kann man erkennen, ob man eine unvollständige Zeile gelesen hat. Solange man nur Daten am Stück schreibt, die höchstens PIPE_BUF Bytes groß sind (Linux: 4096), sollte dies jedoch nie passieren.

Ich bin bisher sehr zufrieden mit dieser Vorgehensweise und kann sie nur weiterempfehlen.