Category: Technik & Software

Facebook kauft WhatsApp für $19 Mrd., und jetzt suchen viele User nach Alternativen. Wie sinnvoll das ist, sei mal dahin gestellt – Facebook nutzen eh die meisten, und die zu WhatsApp hochgeladenen Adressbücher verschwinden ja auch nicht plötzlich, weil man einen anderen Messenger installiert. Jedenfalls aber gibt es gerade viel Unsicherheit und Halbwissen zum Thema sicheres Instant Messaging.

WhatsApp ist funktional, aber ihr Umgang mit Sicherheit ist keine große Erfolgsgeschichte. Als Alternativen werden z.B. Threema, Telegram, SureSpot, TextSecure und Jabber/XMPP gehandelt. Die kurze Version:

• Threema ist Closed Source und kann somit nicht vertrauenswürdig sein, außerdem wird der initiale Kaufpreis die Verbreitung einschränken (WhatsApp war da geschickter, mit kostenlosem Download und erstem Jahr der Nutzung);
• Telegram hat hehre Ziele, aber die verwendete Verschlüsselung ist nicht State of the Art. Mehr dazu auf Hacker News, kurz: Nicht mit Sicherheit rechnen;
• Surespot sind Open Source und die verwendeten kryptografischen Verfahren haben keine offensichtlichen Schwachstellen, außerdem haben sie eine Bedrohungsanalyse veröffentlicht. Surespot verwendet allerdings einen zentralen Server und begrenzt die Anzahl der Nachrichten auf 1000. Außerdem schlagen sie ein paar fragwürdige Dinge vor, wie z.B. den privaten Schlüssel auf Google Drive zu speichern.
• Heml.is existiert noch nicht, und ihre Kommunikation zum Thema Verschlüsselung macht mir nur mäßig Hoffnung, aber man sollte Hemlis im Auge behalten;
• TextSecure ist offen, standardisiert und sicher, aber momentan nur auf Android zu benutzen und setzt außerdem (noch) auf SMS auf. Die nächste Version ist in Arbeit und wird voraussichtlich alle Probleme der aktuellen Version lösen. Momentan ist es aber eher ein Nice to Have als eine echte Alternative für Instant Messaging mit anderen.
• Jabber/XMPP mit OTR wäre theoretisch eine hervorragende Lösung, weil sie nicht nur offen, standardisiert und föderiert ist, sondern weil OTR gleich einen ganzen Schwung an Vorteilen gegenüber klassischer Kryptographie mitbringt. So sind Nachrichten nicht nur von einem Angreifer nicht mitzulesen, sondern OTR garantiert, dass alte Nachrichten selbst bei Bekanntwerden der aktuellen Schlüssel nicht auslesbar sind. Außerdem kann man nach Ende einer OTR-Konversation glaubwürdig abstreiten, die Nachrichten darin geschrieben zu haben – wichtig z.B. für Aktivisten. Leider setzt OTR voraus, dass beide Parteien gleichzeitig online sind, sonst verliert man viel Sicherheit. Gruppenchats sind im Protokoll noch nicht vorgesehen, sind aber in Arbeit. Schließlich sind die meisten Jabber-Clients, gerade im mobilen Umfeld, leider schlicht nicht besonders gut.

Was nutzen?

Es gibt keine eindeutige, abschließende Antwort. Man muss sich überlegen, welche Tradeoffs okay sind für das eigene Kommunikationsverhalten. Es wurden schon Aufstände über Telefon, SMS und sogar Twitter koordiniert, aber als Aktivist würde ich mich dennoch für OTR entscheiden. Für die normale Kommunikation privilegierter Menschen in der „First World“ dürften Threema und SureSpot okay sein. Sogar Telegram ist nicht so gravierend unsicher, dass man strikt davon abraten sollte, außerdem können (und wollen) Telegram ihre Verfahren ja noch anpassen. Insgesamt rechne ich Telegram sogar ganz gute Chancen aus, da es von vKontakte unterstützt wird und WhatsApp sehr ähnlich sieht. Die beste Lösung wäre wohl TextSecure v2; das dafür entwickelte Verschlüsselungsverfahren könnte auch asynchrones OTR vereinfachen.

Wenn ihr mal so richtig gut gelaunt seid und euch das irgendwie Sorgen macht, hier ein einfaches Mittel, diesen Zustand zu ändern:

Erstellt ein Word-Dokument mit ~80 Seiten. Lorem ipsum genügt.
Legt ein Inhaltsverzeichnis an.
Dann fügt Seitenzahlen in die Fußzeile hinzu.
Fügt Zeilennummern zu verschiedenen Abschnitten hinzu. Die Nummerierung soll für jeden Teil neu bei 1 anfangen.
Ändert die Ausrichtung beliebiger, einzelner Seiten zu Querformat.

Die Hölle, das sind Word-Sections.

(Weshalb nochmal wird Word für irgendwelche ernsthafte Arbeit genutzt? Weshalb verlangen Bildungsinstitutionen die Verwendung von Office? Verdammte Schande.)

Wir haben am Dienstag PRINZ relauncht. Nachdem sich der Post-Launch-Staub gelegt hat, kamen – nicht zuletzt auf dem Barcamp Hamburg 2013 die ersten Fragen zum Relaunch. Deutlich am öftesten wurde ich aber gefragt, weshalb das neue PRINZ denn nicht responsive sei.

Responsive Design macht oft Sinn und man sollte immer darüber nachdenken, wie man neue Seiten und Anwendungen umsetzt. Immerhin macht die mobile Nutzung einen signifikanten Anteil im Internet aus und nimmt weiter zu. Andererseits ist aber Responsive Design nicht das End-all-be-all. Es gibt durchaus Fälle, wo es schlicht nicht das richtige Vorgehen wäre. Wir sind der Meinung, PRINZ ist so ein Fall. Es gibt einen sehr großen Anteil von Desktop-Nutzern, und für diese wollten wir eine dem Desktop angemessene Experience schaffen: Viele große Bilder, hohe Informationsdichte, ohne überladen zu wirken, Animationen, Übergänge, in einem relativ simplen Layout. Von der HTML-Struktur hätten wir daraus ohne große Anstrengung eine „responsive“ Mobilversion bauen können. Da PRINZ aber sehr „magazinig“ ist, hätten wir dann trotzdem recht viel HTML und viele Bilder übertragen, und am Ende dennoch keine großartig andere Benutzererfahrung bekommen. Der mobile Anwendungsfall für PRINZ ist primär orts- und zeitgebunden: Wo steigen heute Abend gute Parties? Wo gehe ich jetzt essen? Eine abgespeckte Desktop-Experience wäre da keine Hilfe. Und umgekehrt würde ein Mobile-first-Ansatz für die Desktop-Nutzer nicht funktionieren. Und daher werden wir für die mobilen User eine separate Version bauen, die sich auf diese Anwendungsfälle fokussiert.

Was letzte Woche so erschien: Eine Seite, wo man vorgeblich anonym, jedenfalls aber einfach und kurzlebig Dateien austauschen kann: Volafile. Und eine Bildersuchmaschine, die alles anstößige rausfiltert und den ganzen langweiligen Kram durchfließen lässt. Übrig bleibt Filth, daher heißt das ganze Filther (nsfw if you work in that kind of place). Und foxitalic fand Comics with Problems.

Genug für heute. Nächste Woche hab ich dann auch weniger um die Ohren.

Zeichen! Wunder! Philips haben auf meinen Blogeintrag reagiert. Nein, das eigentliche Wunder ist natürlich nicht, dass sie reagieren – so viel halte ich dann doch von Philips – sondern, dass ich ihre Mails in meinem Spamordner gefunden habe. Die lagen da nämlich schon ein paar Tage drin. Nun ja, dafür hatte Philips ja auch auf meine Mail vom 13. März nicht reagiert. Anyway.

Das Audio-Video-Apps-Team schreibt:

[…]
With respects to the observations made on DockStudio App, we are interested in knowing a more detailed review, providing also Docking Station model, Smartphone model and OS installed.

Thanks you very much for your feedback.

Und Philips Webcare schreiben:

Es tut mir leid, dass Ihre AD7000W-Speaker nicht in der Art und Weise funktionieren, wie es Ihren Vorstellungen entspricht. Wir möchten Ihnen anbieten, Sie zu kontaktieren, um den Sachverhalt persönlich mit Ihnen zu besprechen. Unter welcher Telefonnummer und zu welcher Tageszeit erreichen wir Sie am besten?

Klingt doch gut. Dem AV-Apps-Team hab ich eine kurze Zusammenfassung geschickt, aber ehrlich gesagt, die Fidelio-Apps sind so schlecht, dass ich sie noch nichtmal wieder installieren will, um Screenshots zu machen. Die sollten mit dem Flammenwerfer gereinigt werden und dann von Grund auf neu gebaut. Vielleicht von jemandem, der sich mit Android-Entwicklung und -UX auskennt.

Webcare schickte ich meine Telefonnummer, und heute meldete sich dann ein ausnehmend freundlicher Mitarbeiter, der auch noch technisch versiert war und kein doofes Script abgespult hat. Respekt, immerhin hatte ich ihr Produkt als „Scheiße“ bezeichnet. Wir spielten kurz Firmware-Versionen, Router-Setup und Wifi-Konfigurationen durch und tatsächlich funktionierten die Fidelios für ein paar Minuten prima. Leider nur der Vorführeffekt. Momentan funktionieren immerhin 2 von 3 Geräten, was ein Fortschritt ist. (Update: Mehr Debugging: Sobald mehr als ein Gerät angesteuert wird, fallen alle aus und nur eins recovert. Das passiert auch, wenn zwei Rechner auf zwei verschiedene Geräte streamen.)

Philips will sich wieder melden. Die Specs der Geräte einfach offen zu legen, geht vermutlich nicht, weil das ein OEM-Design ist (was auch die Firmware voller Füllhörner erklären könnte). Schade eigentlich. Man wird es doch noch selbst reverse engineeren müssen.

Kundenservice im Web jedenfalls: Geht. Gleichzeitig sammeln sich aber bei Amazon & Co. weiter die negativen Bewertungen des Produkts an, da es schlicht in den meisten Umgebungen nicht so funktioniert, wie es soll.

Stay tuned.

Liebe Philips,

vor knapp zwei Jahren kauften wir drei „Philips Fidelio AD7000W SoundAvia AirPlay Speaker“ zu je 149€, um unsere Wohnung drahtlos zu beschallen. Nachdem wir heute Abend schon wieder über eine Stunde mit den Geräten gekämpft haben, während unsere Hausgäste eintrudelten, muss ich euch schließlich und endlich etwas sagen:

Euer Produkt ist unbrauchbare Scheiße.

Die Wifi-Verbindung bricht dauernd ab, vor allem, wenn man mehrere Lautsprecher gleichzeitig verwenden will. Trotz eines der besten Router auf dem Markt – unser WLAN kann locker vier Häuser weiter empfangen werden – schaffen es die SoundAvia nicht, einen Musik-Stream mit niedriger Bitrate zu halten. Das Firmware-Update (Version 2012-04-15) von Philips musste umständlich über den Support angefordert werden und ist offenbar immer noch nicht veröffentlicht. Mittlerweile sind die Firmware-Updates nicht mal mehr zu finden.

Immerhin behob das Update das Problem, dass die Lautsprecher sich nach wenigen Stunden einfach aus dem WLAN verabschiedeten und nicht mehr ansprechbar waren: Dann musste man zu den drahtlosen Lautsprechern hingehen, sie aus- und wieder anschalten, und 30-60 Sekunden warten, dann ging es wieder eine Weile.

Was das Firmware-Update allerdings nicht behoben hat, ist das Problem, dass man auf den AirPlay-Lautsprechern keine Musik abspielen kann. Wohlgemerkt das einzige Feature der AirPlay-Lautsprecher – Musik via Wifi abzuspielen. Wohlgemerkt, eines der Geräte steht 5cm vom Router entfernt, das andere immerhin 1,5m in direkter Sichtverbindung ohne Störungen in der Fresnel-Zone. Sobald das zweite Gerät zur Audio-Ausgabe hinzugefügt wird, bricht der Stream ab. Nach 30 Sekunden verabschiedet sich dann ein Gerät und die Musik läuft nur auf dem anderen weiter. Manchmal brechen auch beide ab und man muss alles neustarten, damit es wieder für ein paar Sekunden bis Minuten funktioniert.

Das, Philips, ist scheiße. Und ganz schön peinlich. (Von den Apps für die Fidelio-Serie will ich gar nicht anfangen. Die Reviews sagen alles.)

(Nerderei: Die Firmware enthält Referenzen auf MP3StreamProcess.cpp, WmaStreamProcess.cpp und ShoutcastStreamProcessor, obwohl AirPlay eigentlich nur den Apple Lossless Codec unterstützt. Außerdem gibt es rudimentäre Unterstützung für externe Speichergeräte (MassStorageDeviceClient.cpp). Der mDNSResponder von Apple wird eingebettet, das Gerät spricht irgendwo SOAP, uPnP, hat eine Referenz auf https://api.dev.napster.com:443 (!), Rhapsody, Pandora [hi, „rostislav.simonik“] und Sirius, könnte ein Radio ansteuern und zwischen Lautsprechern und Kopfhörern unterscheiden. Außerdem ist eine Verknüpfung von Last.fm rudimentär vorhanden, und auch MTP-Geräte könnten angesteuert werden. Schließlich hat es Weckfunktionen und spricht Xmodem(!). Hinter der Funktionalität steckt (zumindest in Teilen) „JukeBlox 2“. Aber man findet auch den String „Trial expired, please visit http://www.twonky.com/“ und die „BridgeCo AG“ in der Firmware. Alles sehr Comedy Gold. Außerdem betten sie die GNU GPL in die Firmware ein. Hey, Philips: Macht doch die Specs öffentlich, dann hacken wir uns das Ding selbst auf brauchbar.)

Ich schreibe eine Bewertung für die Philips Fidelio SoundAvia AirPlay-Lautsprecher:

Die Wifi-Verbindung bricht dauernd ab, vor allem, wenn man mehrere Lautsprecher gleichzeitig verwenden will. Trotz des besten Routers auf dem Markt – unser WLAN kann vier Häuser weiter empfangen werden – schaffen es die SoundAvia nicht, einen Niedrig-Bitrate-Stream zu halten. Ein Firmware-Update von Philips musste umständlich angefordert werden, und ist offenbar immer noch nicht veröffentlicht. Mittlerweile sind die Firmware-Updates nicht mal mehr zu finden.

Philips schreibt mir zurück:

Vielen Dank, dass Sie sich die Zeit genommen haben, um uns Ihre Erfahrungen mit Ihrem Philips Produkt mitzuteilen. Leider entspricht Ihre Rezension nicht unseren Richtlinien.

Insbesondere bezogen sich Ihre Erfahrungen auf unseren Kundendienst und nicht auf ein bestimmtes Produkt.

Ein Schelm, wer …

This has recently come up in my work for a large e-commerce company. We were using nginx as a frontend caching load balancer and wanted to route some requests to different backends depending on a header that had a dash in its name. We also wanted to log another request header. Unfortunately, nginx’s variable parser does not map headers with dashes (and some other characters) to anything usable, so you cannot use something like “$http_x-origin” in a directive.

Quirky behavior to the rescue! You can remap variables with complex names by using the map module as follows:

map $is_args $http_x_origin {
  default $http_x-origin;
}

The trick is that map does not fully parse its arguments. The syntax is: map A X { default Y; }, with:

• A any variable, preferably one that does not trigger much internal processing (since nginx configs are declarative, using a variable evaluates it). I use $is_args because it’s cheap to calculate.
• X is the name for the new variable you’ll be creating, i.e. the map target.
• Y is the name of the variable you want to access. At this point, it can contain dashes, because map does its own parsing.

The variable will then be available as X.

I bought an ASUS RT-N66U “Black Knight” a few months back to improve wifi coverage in our new apartment (big rooms, thick walls, lots of interference from neighboring wifi networks), and I have been quite happy with its performance so far. There is just one thing that drove me up the walls: When the WAN link would go down for whatever reason, the RT-N66U detects this and then redirects all requests to itself to show an error page (http://router-ip/error_page.htm?flag=X) instead. This feature can not be disabled using the user interface, and it is severely annoying. You lose the original URL, any POSTDATA, … it sucks. There is a workaround where you manually set the DNS server, but that, too, is very annoying if you use many different networks.

Fed up, I finally took to the source code, which ASUS make available thanks to the GPL. And I finally found the culprit: ASUS have a program called wanduck, which handles all sorts of WAN-related things, including the redirect (wanduck.c:366-410). Most interesting is line 399, which checks for a nvram flag, and then pretends the connection is always up. Not the most elegant solution, but it works. Here’s how you set it up:

First, log in to your RT-N66U’s web interface. Then go to the Administration menu and open the System tab. Enable the telnet server by setting “Enable Telnet” to “Yes”. Click Apply, wait for the changes to complete, then telnet to your router’s IP address and log in with the same username and password you use for the web interface. Once you’re at the command prompt (which should look like admin@RT-N66U:/tmp/home/root#), simply run: nvram set web_redirect=0. You’re done! The change should take hold immediately.

Notes: I am linking to the source code of a modified version of the ASUS firmware, but the code exists in the stock source, too, it simply isn’t on Github. I recommend you disable the telnet interface again if you don’t need it, because your password and all data is sent in the clear. I also recommend you look at the asuswrt-merlin firmware I linked to, which fixes some bugs and (re-)enables some features ASUS disabled in the stock firmware.

Im Großen und Ganzen mag ich mein MacBook Pro. Es ist leistungsfähig und sieht gut aus, ich habe eine SSD und viel RAM drin, und man kann gut damit arbeiten. Leider nervt es seit einiger Zeit beim Zuklappen. Das Verhalten von OS X beim Zuklappen des Laptops ist per pmset zu konfigurieren, u.a. der hibernatemode (und viel mehr: man pmset).

In hibernatemode 3, der Standardeinstellung, schreibt OS X beim Zuklappen des Rechners den Speicherinhalt auf die Festplatte. So lange man noch genug Akkuladung hat, bleibt der RAM aber dennoch unter Strom, und beim Aufklappen sollte der Rechner also sofort aufwachen und arbeitsbereit sein. Falls der Akku irgendwann fast leer ist, legt der Laptop sich in den Tiefschlaf. In diesem Modus verbraucht er zwar keinen Strom mehr, aber beim Aufwachen bootet er quasi neu und liest das Speicherabbild von der Platte.

Bei meinem Mid-2010 MacBook Pro funktioniert das allerdings seit Lion nicht mehr richtig – wenn ich den Rechner zuklappe, schreibt er korrekt den RAM auf die Platte. Beim Aufklappen, egal wie kurz oder wie lang nach dem Sleep mode, gibt es aber eine Pause von mehreren Sekunden, während der der Rechner zwar läuft und ein Bild/den Login-Screen anzeigt, aber nicht nutzbar ist. Den Mauszeiger kann man zwar bewegen, aber Klicks tun nichts und Tastatureingaben werden nicht erkannt.

Bei hibernatemode 0 ist alles in Ordnung – der Rechner legt sich sofort schlafen und wacht ohne Verzögerung auf – außer, der Akku läuft leer. Dann ist der Speicherinhalt futsch.

Im Apple-Forum (1, 2), auf StackOverflow sowie in Blogs findet man diverse Tipps, die sich aber alle nur auf die aktuellen MacBook Air oder MacBook Pro Retina beziehen. Nichts davon hat bei mir genützt.

Wenn irgendjemand weiß, wie ich dieses Problem lösen kann, ich wäre ihr sehr verbunden.