Von der App zur Webversion direkt in die Grütze

Die Webversion von Flipboard hat es nicht nur geschafft, mit einer beworbenen Animationsgeschwindigkeit von durchgängig mindestens 60 fps Aufsehen zu erregen, sie sorgt auch sonst für Diskussionsstoff, wegen ihrer kompletten Unzugänglichkeit. Die Macher von Flipboard haben den DOM in <canvas> nachgebaut, weil er zu langsam ist. Klingt für mich nicht nach einer Idee, die man feiern sollte.

Ich kenne das selbst nur zu gut, Accessibility einzubauen, kann je nach Struktur des eigenen Codes sehr schwierig sein. Die gewählte Struktur ist, naja, sehr schwierig. Und vielleicht liefert Flipboard eines Tages ein Update, bei dem dann der Accessibility mehr Wert beigemessen wird, gänzlich unmöglich ist es ja nicht. Allerdings:

60 frames per second is not “would be nice”. It’s “must have”. And the DOM doesn’t have it. It’s not surprising that Flipboard’s workaround — the <canvas> element — was invented by Apple, as the basis for Dashboard widgets and potentially as the backdrop for the iPhone. But it’s damning that something Apple decided was too slow to serve as the basis for native iPhone apps is the best-performing backdrop for the mobile web.

John Gruber meint also, jetzt 60fps-Animationen an den Start zu bringen, sei wichtiger als Accessibility umzusetzen. Die kann man ja beizeiten nachliefern. Ja, ja, der DOM ist lang und weilig, kennen wir alle. Bisher gabss aber immer wichtigere Dinge, die entwickelt werden mussten. Aber nun kommt es darauf an, dass wir endlich endlich endlich flüssig scrollen können? Und bis das umgesetzt ist, lassen wir mal jene, die auf Zugänglichkeit angewiesen sind, im Regen stehen. Und Schuld ist auch noch das W3C!

Blinded by ideology, oblivious to the practical concerns of 60-FPS-or-bust-minded developers and designers, the W3C has allowed standard DOM development to fall into seemingly permanent second-class status.

Ich weiß gar nicht genau, welche dahinter steckende Denke mir mehr auf den Sack geht: ist das schon Technologiedarwinismus? Natürlich kann man wollen, dass der DOM ähnliche Leistungen vollbringt, wie auf Einzelplattform optimierte Grafikengines, aber der Kern des Web ist das nicht. Und wird es nie sein. Deswegen ist es aber keinesfalls zweitklassig. Vielmehr ist ja seine Stärke die Plattformunabhängigkeit und seine Breite. Und wer glaubt, nur weil jetzt ein paar Appentwickler im Apple Store nicht mehr genug Kohle machen, müsse man das web in eine andere Richtung entwickeln, also weniger offen, weniger zugänglich, aber mit 60fps, der beleidigt einen großen Teil seiner Nutzer und viele ernsthafte Webentwickler gleich mit. Es ist ein Fehler, Apps in HTML eins zu eins nachbauen zu wollen (weiss ich aus Erfahrung) diesen Fehler jetzt zur Ideologie zu erheben, halte ich bestenfalls für gefährlich.

Es muss einen (hust… finanziellen… hust) Grund geben, warum Apps wie Flipboard aus ihrer ach so primärtechnologischen Welt der Apps in das so lahme mobile Web wollen. Mit Menschenfreundlichkeit hat es offenbar nichts zu tun. Ich kann nur hoffen, dass, falls sich das als Trend erweisen sollte, wir stark genug sind, ein offenes und gleichberechtigtes Netz zu bewahren und nicht anfangen, langwierig Erkämpftes (was sich selbst noch deutlich ausbauen lässt) auf dem Altar der Animationsgeschwindigkeit zu opfern.

289 Passwörter

Hey, seit der letzten großen Passwortkatastrophe habe ich mich accountmäßig wirklich entschlackt. Doch, ehrlich. Ich melde mich bei jedem Dienst mit einer anderen Emailadresse an, catch-all macht’s möglich, und verwalte Logins und hochkomplexe, einmalige Passwörter in 1-Password. Trotzdem, ich lagere dort sage und schreibe 289 einzelne Logins. Und ja, ich habe eine Meise.

Ich fänd das wirklich sehr hilfreich, wenn sich mal jemand etwas neues an Stelle von Passwörtern ausdenken würde, also irgendetwas was besser skaliert? Das wäre fein. So kann das ja nicht wirklich sicher sein, ich kenne euch Pappenheimer doch, ihr geht nicht so ordentlich mit euren Logins um! Und zu der ganzen Unsicherheit mit dem widersprüchlichen soll kompliziert aber leicht zu merken sein, kommt ja auch immer noch das Gefuddel mit dem Passwortmanagern und alles dazu. Und wenn man dann mal ein Login sparen will, kommt man nach Monaten zur Anmeldung zurück und feststellen, dass man nicht mehr weiß, ob man nun Google, Facebook oder Twitter zu einloggen verwendet hatte. So klappt es also auch nicht. Und wirklich trauen will ich diesen Kraken auch nicht.

Was man also bräuchte, wäre etwas ganz anderes als Passwörter. Ich mag ja bspw. wenn ich mich irgendwo mit SSH anmelden muss, meinen Key auf den Server zu packen. So in der Art wär mir das lieb. Und dann immer schön zentral alles bei mir, aber immer so einzigartig, dass nicht das ganze Leben im Arsch ist, wenn mal etwas lecker. Und schön NSA ignorant bitte. Das kann doch jetzt mal jemand machen.

keybase.io – Cryptoparty im Netz

keybase

Ich bin jüngst zur early alpha von keybase eingeladen worden und nach ein paar Tagen herumprobieren kann ich sagen: die Idee hat wirklich potential. Keybase ist sozusagen eine sehr große PGP-Cryptoparty und soll ermöglichen, mit Leuten, die man noch nicht persönlich getroffen hat (und vielleicht nie treffen wird) ein web of trust aufzubauen und so letztlich verschlüsselte Kommunikation zu ermöglichen. Zusätzlich gibt es noch einige Hilfsmittel, um bspw. über die Kommandozeile oder sogar über Twitter, verschlüsselt zu kommunizieren.

Get a public key, safely, starting just with someone’s social media username(s). From there, unbounded potential!

Meine Accounts sind mein Ausweis

Einer der Kernpunkte verschlüsselter Kommunikation mit PGP ist ja, dass man Leute findet, die man ihrem PGP-Schlüssel zuordnen kann und ihnen so vertraut. Bisher musste man sich dafür persönlich treffen und die Schlüssel austauschen und beglaubigen. Keybase will eben diese Beglaubigung herstellen, ohne dass man sich treffen muss. Dazu identifizieren sich die Nutzer gegenüber von Keybase auf möglichst vielfältige Weise. Ich habe zum Beispiel einen speziellen Tweet abgesetzt um mich mit meinem Twitteraccount auszuweisen. Und weil das noch nicht reicht (den Tweet könnte ja auch jemand veranlassen, der einen Twitteraccount gekapert hat), habe ich noch ein spezielles Gist erstellt, um meinen Github-Account identifizierbar zu machen. Und um es noch genau zu machen, habe ich den DNS-Text von nicobruenjes.de so angepasst, dass keybase jetzt weiss: ich bin der Besitzer der Domain. Das geht noch mit einer ganzen Reihe weiterer Accounts und Eigenschaften, bis hin zur Bitcoin-Adresse. Mit je mehr man sich ggü. Keybase ausweist, um so sicherer wird die Sache natürlich. Anhand dieser verbrieften Eigenschaften können mich nun andere Keybase-Nutzer finden und erkennen (ich zeige hier die Kommandozeile, weil das einfacher hierher zu kopieren ist, geht alles auch per Website):

› keybase id nicobruenjes
✔ public key fingerprint: 9DCF BD30 2843 0CBE 78E5 F1A8 B51E 2E22 55CF BFF6
✔ "nicobruenjes" on twitter: https://twitter.com/nicobruenjes/status/565440317495996417
✔ "codecandies" on github: https://gist.github.com/e2cb03903755b8d9ed72
✔ admin of the DNS zone for nicobruenjes.de

Man findet andere natürlich auch anhand der identifizierten Accounts:

› keybase id twitter://nicobruenjes
› keybase id web://nicobruenjes.de
› keybase id github://codecandies

Wer nun der Ansicht ist, das ich der Nico Brünjes bin, mit dem er gerne kommunizieren möchte, dann kann er mich tracken, so wie frienden oder followen, nur eben geekiger.

› keybase track nicobruenjes
✔ public key fingerprint: 9DCF BD30 2843 0CBE 78E5 F1A8 B51E 2E22 55CF BFF6
✔ "nicobruenjes" on twitter: https://twitter.com/nicobruenjes/status/565440317495996417
✔ "codecandies" on github: https://gist.github.com/e2cb03903755b8d9ed72
✔ admin of the DNS zone for nicobruenjes.de
› Is this the nicobruenjes you wanted? [y/N] y
› Permanently track this user, and write proof to server? [Y/n] Y

Copy & Paste Verschlüsselung für Twitter

Nun kann man schon Daten verschlüsseln:

› keybase encrypt nicobruenjes -m 'Verschlüssel das mal'
-----BEGIN PGP MESSAGE-----
Comment: GPGTools - https://gpgtools.org

hQIMA9IkQTsc+mSQARAAoeIqoS7D+C3aWuymUomVJWU
e1FiqMNWJDyTzT4I5cRkiwKWLCLmPlYIO1oLhNl670l
tfp+Qof7CJDGIUx02vRydT5coUwt8MtEhJUPDGi3cAG
-some-extra-lines-omitted-here :-)
0LUvVNuYCvjR4Rt7fkfeVcSuakEpUfufGnFqow==
=4DrQ
-----END PGP MESSAGE----

Und entschlüsseln: keybase decrypt antwort.asc. So kann man, per copy und paste, bspw. über Twitter oder Slack oder anderen Diensten mit denen man planen Text versenden oder Dateien teilen kann verschlüsselt kommunizieren. Meist will man ja aber verschlüsselte Mails senden. Deswegen landen alle Leute die man (per Kommandozeile) trackt auch direkt in der GPG-Keychain, man kann ihnen also auch direkt verschlüsselte oder gesignte Mails schicken.

That’s it. It’s really pretty simple. We’re not reinventing any cryptography here – the goal is a simple way to look up and trust keys, based on known public identities.

Die Website ist übrigens weitestgehend ein Client für keybase, dort kann man alle Funktionen im Web abrufen. Das zeigt aber auch den Knackpunkt von Keybase: es ist ein open source Programm, das man wiederum beliebig in andere Programme einbauen kann. Oder Dienste nutzen das API. Da ist wirklich noch viel drin.

Einladungen zu vergeben

Wie schon erwähnt: keybase.io ist noch in einem sehr frühem Stadium, alle Features die da sind, scheinen aber meinen Tests nach tadellos zu funktionieren. Wer mittestesten will, ich habe noch einige Einladungen hier herumliegen… kommentiert hier einfach.