Mit PhantomJS Platzhalter für datenschutzkonforme „Gefällt mir“- und „+1“-Buttons erstellen

Wer Gefällt mir– oder +1-Buttons direkt in seine Website einbindet, verstößt dabei wohl gegen geltendes Datenschutzrecht. Denn selbst wenn man in seinen Datenschutzrichtlinien über die Buttons informiert, so werden sie ja automatisch sofort geladen, bevor der Besucher den Text überhaupt lesen konnte. Und da die Buttons direkt von Facebook & co. geladen werden, können diese damit wunderbar ein digitales „Bewegungsprofil“ ihrer Nutzer und Nichtnutzer erstellen.

Eine beliebte Alternative sind Lösungen wie die von Heise ins Leben gerufene Shariff-Bibliothek. Hier wird die Verbindung zum sozialen Netzwerk erst hergestellt, nachdem der Benutzer einmal geklickt hat. Leider bietet Shariff von sich aus keine Unterstützung für Gefällt mir– und +1-Buttons, sondern es erlaubt lediglich das Teilen. Die ebenfalls von Heise entwickelte Zwei-Klick-Lösung SocialSharePrivacy ist mittlerweile auch schon arg angestaubt und hat den Nachteil, dass die aktuelle Anzahl von „Likes“ nicht angezeigt werden kann.

Ich wollte daher eine eigene Alternative entwickeln. Mein Ansatz ist derselbe wie bei SocialSharePrivacy: Der Benutzer sieht zunächst eine „ausgegraute“ Version des Buttons, bei der es sich nur um ein Bild handelt, das vom eigenen Server ausgeliefert wird. Ein kleiner Hinweis informiert darüber, dass der Button mit dem ersten Klick aktiviert und mit dem zweiten Klick bedient wird. Bei erfolgtem Klick wird das Bild durch den tatsächlichen Button ersetzt, beispielsweise mit Hilfe eines iframe-Elements.

Die Platzhaltergrafiken für die Buttons sollten bereits die aktuelle Anzahl von „Likes“ enthalten, daher scheidet ein manuelles Anfertigen dieser Grafiken aus. Und genau hier hat sich PhantomJS wieder einmal als ein hervorragendes Tool bewiesen. Mit nur ein paar Zeilen JavaScript kann der echte Button von Facebook/Google in einem „virtuellen Browser“ geladen und als Screenshot abgespeichert werden. Ein bisschen Nachbearbeitung mit ImageMagick sorgt dann für einen ausgegrauten/unscharfen Look. Die Aktualisierung der Platzhaltergrafiken erfolgt mittels Cronjob automatisch einmal pro Stunde, bei Bedarf auch öfter oder seltener.

Upgrade auf Windows 10 und nicht mehr funktionierendes Wake on LAN

Obwohl ich mit dem Upgrade von Windows 8.1 auf Windows 10 eigentlich ein wenig warten wollte, bis die gröbsten Fehler behoben wurden, habe ich dem verlockenden Angebot doch nur ein paar Tage standgehalten.

Das Upgrade selbst lief zu meiner Überraschung fast problemlos. Ich musste lediglich einmal den Rechner komplett ausschalten, damit ich wieder Internetzugang bekam — ein Neustart reichte nicht aus …

Heute wollte ich dann zum ersten Mal nach dem Upgrade aus der Ferne meinen Rechner starten, um auf eine lokale Datei zuzugreifen. Zu diesem Zweck habe ich Wake on LAN eingerichtet, was äußerst praktisch ist. Es erlaubt mir, den Rechner über das Web-Interface meiner FRITZ!Box einzuschalten, um mich dann mit Remote Desktop darauf anzumelden.

Genau das funktionierte nun nach dem Upgrade plötzlich nicht mehr. Wenn man im Internet nach dem Problem sucht, findet man normalerweise drei Hinweise:

  1. Man soll das Windows-Feature Fast Startup (Schnellstart) deaktivieren, denn ansonsten wird der Rechner beim Herunterfahren nicht komplett ausgeschaltet, sondern nur in einen sehr sparsamen Energiesparmodus versetzt, aus dem er sich evtl. mittels Wake on LAN nicht aufwecken lässt.
  2. Man soll im Gerätemanager bei den Geräteeigenschaften des Netzwerkadapters sicherstellen, dass dieser den Rechner aufwecken kann.
  3. Man soll im BIOS überprüfen, ob Wake on LAN aktiviert ist.

Alles war bei mir der Fall — die Einstellungen wurden vom Upgrade-Prozess wohl übernommen, und die BIOS-Einstellungen werden (hoffentlich) davon nicht beeinflusst.

Nach einigem verzweifelten Herumprobieren sah ich dann im Gerätemanager, dass der Treiber für den Intel-Netzwerkadapter ein Standardtreiber von Microsoft war. Zuvor hatte ich den Intel-Treiber installiert, aber dieser wurde wohl beim Upgrade auf Windows 10 ersetzt.

Nachdem ich nun wieder den Intel-Treiber für Windows 10 installiert und den Rechner einmal neugestartet habe, funktioniert Wake on LAN wieder einwandfrei! Dass es sich um ein Treiberproblem handelte, erscheint mir seltsam, denn wenn der Computer ausgeschaltet ist, spielen Treiber keine Rolle. Aber möglicherweise versetzt der Intel-Treiber den Netzwerkadapter in einen speziellen Modus, in dem er auf Wake on LAN-Pakete wartet, bevor der Rechner heruntergefahren wird.

Wenn mod_deflate scheinbar nur mit HTTPS funktioniert

Gerade bin ich einem sehr knackigen Rätsel auf die Spur gekommen. Wenn ich eine meiner Seiten im Browser lade und mir die HTTP-Requests anzeigen lasse, dann stelle ich fest, dass HTML-Inhalte scheinbar ohne Kompression ausgeliefert werden, obwohl mod_deflate im Apache-Webserver korrekt aktiviert ist. Noch seltsamer ist aber, dass das Problem nicht auftritt, wenn ich die Seite mit HTTPS (SSL) aufrufe. Aus der Sicht externer Tools wiederum, die Seiten auf Kompression testen, wird alles ordnungsgemäß komprimiert — sowohl mit HTTP als auch mit HTTPS. Nur meine Browser sind anderer Meinung.

Des Rätsels Lösung: Kaspersky Endpoint Security for Windows ist schuld! Die Komponente Web Anti-Virus agiert als eine Art Proxy zwischen dem Browser und dem Webserver und dekomprimiert die HTML-Inhalte, um sie nach schädlichem Zeugs zu durchsuchen. Das erklärt auch, warum Inhalte über HTTPS komprimiert beim Browser ankommen: Die Kaspersky-Software hat hier wegen der Verschlüsselung keine Möglichkeit, die Daten abzufangen!

Wenn also jemandem etwas Ähnliches passiert, dann erst einmal prüfen, ob nicht irgendeine Sicherheitssoftware dazwischenfunkt.

Lösung: Pipe-Symbol über VNC tippen

Heute wurde ich mit dem Problem konfrontiert, das Pipe-Symbol („|“) über eine VNC-Verbindung zu meinem Server zu tippen. Wenn ich Alt Gr + < drücke, passiert einfach gar nichts. Andere Zeichen funktionieren hingegen wunderbar. Eine ganz einfache Notlösung (die ich seltsamerweise nirgendwo gefunden habe) ist Folgende:

Bei gedrückter Alt-Taste einfach die Ziffernfolge 124 auf dem Ziffernblock (NumPad) tippen, denn 124 ist der ASCII-Wert des Pipe-Zeichens.

… und schon erscheint das ersehnte Symbol. Bei mir jedenfalls. 😉

Den Backslash („\“) erhält man übrigens mit Alt + 92 und die Tilde („~“) mit Alt + 126.

Wenn wget versagt: PhantomJS

Aus einem gewissen Grund brauche ich regelmäßig die aktuellen IP-Ranges von Amazon EC2 (ein Produkt für Cloud Computing). Zum Glück gibt es im entsprechenden Amazon-Forum einen Thread, in dem immer die aktuellen IP-Ranges aufgelistet sind. Bis vor einiger Zeit konnte ich diesen Thread problemlos wie folgt herunterladen, um ihn dann mit einem regulären Ausdruck nach IP-Ranges zu durchsuchen:

wget -O amazon_ec2.txt https://forums.aws.amazon.com/ann.jspa?annID=1701

Nun geht das nicht mehr — man erhält nur eine Fehlermeldung, dass der Browser JavaScript unterstützen muss. Das Forum arbeitet jetzt scheinbar Client-seitig mit JavaScript, und wget kann kein JavaScript ausführen.

Doch zum Glück gibt es PhantomJS! Dabei handelt es sich um ein Tool, das sozusagen einen Browser simuliert und mit JavaScript gesteuert werden kann. Mit folgendem Skript kann ich die Seite laden und ihren HTML-Quellcode ausgeben, womit das Problem gelöst ist:

var page = require("webpage").create();
page.open("https://forums.aws.amazon.com/ann.jspa?annID=1701",
 function (status) {
  var f = function () {
   var html = page.evaluate(function () { return document.documentElement.innerHTML });
   console.log(html);
   phantom.exit();
  };
  setTimeout(f, 10000);
 }
);

Die Verzögerung von 10 Sekunden sorgt dafür, dass alle Umleitungen (mit hoher Wahrscheinlichkeit) abgeschlossen sind, bevor der HTML-Quellcode ausgegeben wird. Es geht wahrscheinlich auch eleganter, aber es erfüllt seinen Zweck.

Bislang habe ich für solche Zwecke übrigens Awesomium benutzt, was auch ganz nett ist, aber hier gibt es schon seit Ewigkeiten keine 64-Bit-Version mehr für Linux (eigentlich ein Unding). Vielleicht werde ich meine schon existierenden Anwendungen, die auf Awesomium basieren, auf PhantomJS portieren.

Expedition ins schwarze Loch

… so hieß eine Dokumentation, die ich gerade auf N24 gesehen habe. Es handelte sich dabei um eine Folge von Sci Fi Science: Physics of the Impossible. Was einem da geboten wurde, war absolut haarsträubender Unfug, der aber so präsentiert wurde, als ob es sich dabei um wissenschaftliche Fakten handeln würde.

Laut Michio Kaku, dem Moderator der Sendung, sollte es möglich sein mit einem Raumschiff in ein schwarzes Loch zu fliegen. Es gibt da nur ein Problem, das er Spaghettisierung nennt: Das Raumschiff wird zu einem Punkt zerdrückt bzw. unendlich in die Länge gezogen. Aber das ist ja nicht so schlimm, dann nähern wir uns dem schwarzen Loch einfach von oben(!), wo sein Gravitationsring nicht so stark ist. Dort ist es ganz ruhig, wie im Auge eines Wirbelsturms, so dass wir bis zur Öffnung des „Wurmlochs“ vordringen können. Aber so ein Wurmloch ist sehr instabil, wir müssen es offen halten. Dazu brauchen wir die seltenste Substanz des Universums: negative Materie. Die gibt es in Form von negativen Asteroiden am Rand des Universums. Wir schicken also ein paar Drohnen zum Rand des Universums, um sie einzusammeln. Habe ich schon erwähnt, dass negative Materie Antigravitation erzeugt? Damit können wir das Wurmloch stabil halten und hinein fliegen. Natürlich ergibt sich all das aus den Gleichungen von Albert Einstein! Die Leute, die der Moderator fragte (es handelte sich sinnvollerweise um betrunkene Besucher einer Diskothek), hielten die Vorgehensweise jedenfalls für eine gute Idee und würden sich sofort mit Michio Kaku ins Raumschiff setzen.

N24 ist mit dieser Sendung in ein schwarzes Loch der Fernsehqualität eingetaucht. Ich habe mir die ganze Zeit überlegt, was Harald Lesch wohl dazu sagen würde. Wahrscheinlich würde er tot umfallen.

NVIDIA-Treiber müllen Systempartition voll

Wer unter Windows regelmäßig seine NVIDIA-Grafikkartentreiber aktualisiert oder gar ständig die neuesten Betaversionen installiert, dem könnte bereits aufgefallen sein, dass nach jeder solchen Aktion etwas weniger freier Speicher auf der Systempartition übrig bleibt. Gerade bei einer SSD ist das ärgerlich, da diese für gewöhnlich nicht so groß ausfallen wie normale Festplatten.

Der Grund für den Platzschwund liegt darin, dass der Installer immer noch eine Kopie der gesamten Treiberkomponenten aufbewahrt, und zwar für jede Version, die man jemals installiert hat!

Um diesem hirnrissigen Spuk ein Ende zu bereiten, kann man ganz einfach alle Unterverzeichnisse aus folgendem Verzeichnis löschen:

C:\Program Files\NVIDIA Corporation\Installer2

Natürlich sollte man auch nicht vergessen, den temporären Ordner zu löschen, in den der Installer extrahiert wird. Standardmäßig ist das C:\NVIDIA. Auch hier fällt gerne nochmal ein halbes Gigabyte an Müll an.

Nachtrag (4. April 2016): NVIDIA empfiehlt, vor der Installation einer neuen Treiberversion zunächst den vorhandenen Treiber zu deinstallieren. Alternativ kann man während der Installation die Option „Perform Clean Install“ auswählen, die das automatisch erledigt. So hält sich der Ballast in Zukunft hoffentlich in Grenzen.