Nicht selbst bauen …

• Das Prinzip Don't Roll Your Own ... gilt nicht nur für Kryptografie, sondern auch für Web-UIs: Funktionen, die der Browser bereits zuverlässig bereitstellt, sollten nicht unnötig ersetzt werden
• Das Ersetzen von grundlegenden Verhaltensweisen wie eigenem Scrollen, Link-Behandlung, Textauswahl oder Kopieren und Einfügen zerstört vertraute Reaktionen auf Eingaben und zwingt Nutzer dazu, sich wieder bewusst mit der Bedienung zu befassen
• Wenn JavaScript wie bei Datei- oder Issue-Links auf GitHub die Link-Navigation abfängt, kann es manchmal schneller sein, den Link in einem neuen Tab zu öffnen, als darauf zu warten, dass der aktuelle Tab ihn verarbeitet
• Normale Passwortfelder und <input type="date"> arbeiten mit Autovervollständigung, Passwortmanagern, Accessibility-Tools und mobilen Tastaturen zusammen; ersetzt man sie durch gefälschte UIs, können Funktionen kaputtgehen
• Layouts und Formular-Controls, die sich alle paar Monate ändern, zwingen Nutzer dazu, Zeit auf erneutes Lernen statt auf ihre eigentliche Arbeit zu verwenden; daher ist es besser, das stabile Standardverhalten des Browsers beizubehalten

---

Anwendung des Prinzips „Nicht selbst bauen“ auf Web-UIs

• Kryptografie nicht selbst implementieren ist das Prinzip, sich in produktiver Software zum Schutz sensibler Daten nicht auf ungeprüfte private Implementierungen zu verlassen
• Es bedeutet nicht, dass niemand jemals Kryptografie-Code schreiben darf, sondern eher, dass man nach Möglichkeit geprüfte und verifizierte Pakete und Tools verwenden sollte
• Vor etwa 20 Jahren gab es tatsächlich eigene RC4-Implementierungen mit Problemen wie ungeeigneten Initialisierungsvektoren, vorhersagbaren Keystreams und dem Offenlegen von Teilen des Klartexts
• Heute verwenden große E-Commerce-Websites oder Banken für Web-Services in der Regel keine eigene Kryptografie, und in regulierten Bereichen wie Zahlungsverkehr, Medizin oder dem Umgang mit personenbezogenen Daten können Verstöße gegen starke Kryptografie-Anforderungen zu hohen Geldstrafen führen
• Webdesign ist nicht dasselbe wie Kryptografie, aber wenn man Funktionen neu implementiert, die der Browser bereits gut beherrscht und auf die Nutzer sich täglich verlassen, kann sich die User Experience verschlechtern

Probleme beim Ersetzen von Browser-Standardfunktionen

• Wenn man das Scrollen der Seite selbst implementiert, kann das vertraute Verhalten bei Maus-, Touchpad- und Tastatureingaben kaputtgehen
• Überschreibt man das Standard-Scrollverhalten, bewegt sich die Seite womöglich zu langsam oder zu schnell, und Scrollen per Tastatur funktioniert eventuell gar nicht mehr
• Wenn sich ein Verhalten, das Nutzer bisher unbewusst verwendet haben, in ein fremdes Verhalten verwandelt, müssen sie sich wieder mit der Bedienung der Seite selbst befassen
• Zu den typischen Funktionen, die man nicht selbst implementieren sollte, gehören Link-Navigation, Textauswahl, Kontextmenü, Kopieren und Einfügen, Passwortfelder und der Date Picker
• Wenn man auf ernsthaften Arbeits-Websites UI-Funktionen einführt, sollte man konservativ entscheiden, ob man auffällige Features ergänzt oder sie lieber dem Standardverhalten des Browsers überlässt

Link-Navigation und das Beispiel GitHub

• Webbrowser beherrschen das Folgen von Links bereits gut, und Link-Navigation ist eine Kernfunktion des Browsers
• Wenn es sich so anfühlt, als müsse man normales Linkverhalten stören, sollte man erneut prüfen, ob das angestrebte Ziel wirklich wichtig genug ist, um gewöhnliche Link-Navigation zu zerstören
• Auf GitHub übernimmt beim Klick auf Datei-Links oder Issue-Links eine große, in JavaScript implementierte Funktion die Klick-Verarbeitung
• In Firefox oder Chrome kann man das überprüfen, indem man mit F12 die Entwicklertools öffnet, im Tab Debugger oder Sources unter Event Listener Breakpoints bei Mouse die Option click auswählt und dann einen GitHub-Link anklickt
• Auf GitHub kann es schneller sein, einen Link in einem neuen Tab zu öffnen, als darauf zu warten, dass die JavaScript-Navigation im aktuellen Tab ihn verarbeitet

Passworteingabe und Date Picker

• Das Passwort-Eingabefeld des Browsers kann das Speichern von Passwörtern, das automatische Ausfüllen und das Erzeugen starker Passwörter für neue Accounts bereitstellen
• Ein normales Passwortfeld warnt, wenn ein Passwort über eine unsichere HTTP-Verbindung gesendet wird, und arbeitet außerdem mit Passwortmanagern, Autovervollständigung, mobilen Tastaturen und Accessibility-Tools zusammen
• Ersetzt man es durch ein gefälschtes Passwortfeld, können diese Funktionen kaputtgehen; maskiert man ein normales Textfeld selbst, können Browser, Betriebssystem und Hilfswerkzeuge das Passwort wie normalen sichtbaren Text behandeln
• <input type="date"> unterstützt die Auswahl eines Datumsbereichs nicht direkt, aber mit zwei Eingabefeldern für Start- und Enddatum lässt sich der Standard-Date-Picker des Browsers beibehalten
• Benutzerdefinierte Date Picker unterscheiden sich je nach Implementierung: Man muss eventuell erst in eine Jahresansicht wechseln, dutzende Male auf die Schaltfläche für frühere Jahre klicken, um ein Geburtsjahr zu wählen, oder darf ein Datum nicht direkt eintippen
• Wenn in Browsern mit schwacher Unterstützung für den Standard-Date-Picker ein Kalender-Widget nötig ist, sollte es <input type="date"> nicht ersetzen, sondern als zusätzliches Widget dasselbe Feld bedienen

Die Kosten häufiger UI-Änderungen

• Wer Formular-Controls leichtfertig ändert, löst bestehende Probleme und führt dabei fast immer neue ein
• Wenn Layout und Oberfläche einer Website alle paar Monate geändert werden, mögen sich manche Nutzer anpassen, ältere Nutzer empfinden jedoch jedes Mal eine ähnliche Belastung wie beim Erlernen eines neuen Werkzeugs
• Wenn viele Websites ihre Oberfläche ständig ändern, müssen Nutzer viel Zeit darauf verwenden, Vertrautes neu zu lernen, ohne dass ihnen daraus ein funktionaler Vorteil entsteht
• So wie es unerquicklich wäre, wenn eine Linux-Distribution alle paar Monate alle Kernbefehle und Kommandozeilenoptionen neu gestalten würde oder die Anordnung der Tasten einer Waschmaschine jeden Morgen anders wäre, ist auch ein ständiges UI-Umräumen eine unangenehme Erfahrung
• Eine Web-UI ist ein Werkzeug, das Nutzer verwenden, um ihre Arbeit zu erledigen; deshalb ist es besser, vertraute und stabile Verhaltensweisen, die der Browser bereits bereitstellt, nicht unnötig zu ersetzen

[kirinonakar]

Ich glaube, es gibt kaum ein Land, das so viele eigene Verschlüsselungs- und Sicherheitsprogramme hat wie unseres.

[GN⁺]

Lobste.rs-Kommentare

• Ich stimme zu, dass man Seitenscrolling nicht selbst implementieren sollte. Man wird es nie so gut hinbekommen wie nativ, und eine vertretbare Ausnahme wäre höchstens ein Fall wie bei Karten, wo Scrollen üblicherweise auf Zoomen abgebildet wird.

  Dass man selbst implementierte Link-Navigation zur Regel verbieten sollte, lehne ich aber entschieden ab. Für gewöhnliche Content-Seiten würde ich clientseitiges Routing (CSR) nicht empfehlen, aber bei manchen Apps kann man es im Gegenteil sogar ausdrücklich empfehlen, und Dienste wie GitHub liegen irgendwo dazwischen.

  Man sollte allerdings immer echte ``-Elemente verwenden, damit die nativen Browser-Funktionen funktionieren. Bei Apps wie einem Webmail-Client ist CSR sinnvoll, und auch GitHub war besser, als es das früher leichter eingesetzt hat, aber der neuere Frontend-Ansatz ist ziemlich schlechter geworden.

  Das Problem ist, dass CSR viel zu oft schlampig implementiert wird und nicht robust gegenüber schlechten Netzwerkbedingungen gemacht ist. Browser sind in solchen Situationen stark, und Optimierungen wie Ladeanzeigen auf Tabs oder bfcache können durch CSR ebenfalls behindert werden.

  Selbst implementierte Textauswahl wäre nur in sehr speziellen Fällen eine Ausnahme, etwa bei Annotations-Apps auf Mobilgeräten, in denen man den Finger wie einen Textmarker benutzt. Ich würde sogar noch hinzufügen, dass man ::selection besser ebenfalls nicht verwenden sollte. Dass die Auswahl allein dadurch unsichtbar werden kann, dass man ::selection{} ins Stylesheet aufnimmt, ist schlechtes Design.

  Dem Verbot selbst implementierter Kontextmenüs widerspreche ich. In Apps wie E-Mail-Clients, Dateimanagern oder Textverarbeitungen braucht man eigene Einträge, und weil der Browser keine Erweiterungsmöglichkeit bietet, ist ein vollständig eigenes Menü derzeit eine praktische Wahl. Zum Glück kann man in Firefox mit Shift+Rechtsklick das native Menü erzwingen.

  Beim Verbot selbst implementierter Copy/Paste-Funktionen könnte ich je nach Auslegung zustimmen oder widersprechen; das müsste klarer formuliert werden.

  Beispiele für selbst implementierte Passwortfelder habe ich außerhalb technischer Demos fast nie gesehen. Einen Anzeigen-/Verbergen-Button, der `` von password auf text umstellt, würde ich nicht dazu zählen.

  Auch dem Rat, keinen eigenen Date-Picker zu bauen, widerspreche ich. Ich würde native Controls bevorzugen, aber ihre Grenzen und Inkonsistenzen sind groß, und in den letzten zehn Jahren gab es kaum Interesse, sie zu verbessern. Man kann dem Picker keine zusätzlichen Informationen mitgeben, und das Auswählen weit zurückliegender Daten, etwa eines Geburtsdatums, ist auf manchen Plattformen grauenhaft. Beispiel: Safari's date-picker is the cause of 1/3 of our customer support issues

  Custom-Date-Picker haben viele Accessibility-Probleme, sind für gewöhnliche Nutzer aber oft trotzdem besser, und häufig braucht man Funktionen, die native Controls nicht bieten, sodass man sie gar nicht einsetzen kann. Für einfache Datumswahl bevorzuge ich nativ, weil in meinem Browser direkte Eingabe möglich ist, aber für viele Nutzer ist nativ schlicht nicht gut genug. Ein Datumsbereich aus zwei `` zusammenzubauen, dürfte für die meisten deutlich schlechter sein.

  • Formulierungen, die Menschen mit Accessibility-Bedarf oder Menschen, die davon profitieren, den „normalen Leuten“ gegenüberstellen, können einige Leser leicht ausschließen. Gerade weil es so wirkt, als würdest du dich wirklich um die Erfahrungen und Bedürfnisse von Menschen kümmern, die Accessibility-Hilfen nutzen, wollte ich das ansprechen.

  • Nachdem ich Safaris Date-Picker selbst benutzt habe, verstehe ich, wie eingeschränkt er ist. Ich habe mich allerdings immer gefragt, warum Websites native Date-Picker durch ein Kalender-Widget ersetzen.

    Könnte man ein Kalender-Widget nicht zusätzlich neben dem nativen Widget anbieten? Das UI könnte zwar verwirrend wirken, weil es wie zwei Eingabemethoden aussieht, aber mit einer passenden Beschriftung, die eines davon als erweiterten Date-Picker kennzeichnet, ließe sich das vielleicht lösen. Dann würde man weder die Leute verlieren, die den nativen Date-Picker gern nutzen, noch jene, denen der Browser-Date-Picker nicht reicht.

    Ich verstehe, dass Web-Apps wie Dokumenteditoren oder Diagrammwerkzeuge Kontextmenüs brauchen, aber wenn beim Rechtsklick das normale Browser-Menü verschwindet, ist das weiterhin unangenehm. Deshalb habe ich in Firefox meist dom.event.contextmenu.enabled = false gesetzt. Dann erscheint das Firefox-Menü oben und das Web-App-Menü dahinter, aber das native Menü funktioniert, also ist das ein brauchbarer Workaround. Wenn möglich, ist es besser, die Menüleiste der Web-App zu verwenden und das native Kontextmenü des Browsers unangetastet zu lassen. Der Tipp mit Shift+Rechtsklick ist ebenfalls eine gute Lösung.

  • Menschen, die zugängliche Controls brauchen, sind auch normale Menschen.

  • Beispiele für selbst implementierte Passwortfelder sieht man bei fast allen Banken in Peru.

    Beim Date-Picker würde ich gern nativ verwenden, aber auf Seiten der Implementierer scheint es kaum Interesse an Verbesserungen zu geben. In Firefox gibt es ein Issue zur Zeit-/Uhr-Auswahl-UI, und es geht nur langsam voran: https://bugzilla.mozilla.org/show_bug.cgi?id=datetime

• Für Web-Formulare ist das ein guter Hinweis. Sich auf den Browser zu verlassen ist die einfachste, schnellste und fast immer konsistenteste Vorgehensweise.

  Beim Thema Kryptografie-Code ist es aber anders. Korrekte Kryptografie zu schreiben ist nicht einfach, aber auch nicht unmöglich. In manchen Situationen gibt es so wenige Optionen, dass selber bauen die beste Wahl sein kann.

  Das Problem mit den Sicherheits-Orthodoxen ist hier, dass sie oft so tun, als dürfe man neuen Krypto-Code nur schreiben, wenn man zu ihrer Ingroup gehört. Wenn man keinen Doktortitel in Kryptografie oder kein Praktikum bei DJB oder Dan Boneh vorweisen kann, dürfe man keinen Krypto-Code schreiben. „Zum Lernen“ sei es okay, aber man dürfe das Gelernte nicht praktisch anwenden. Teilweise scheinen sie sogar Schwierigkeiten zu haben, reale Kompetenz außerhalb ihrer eigenen Gruppe zu erkennen. Interessanterweise scheint die Überschneidung zwischen diesen Sicherheits-Orthodoxen und den tatsächlichen Kryptografen, die Papers schreiben, sehr klein zu sein.

  Inzwischen wird das sogar auf die Forderung ausgeweitet, man solle überhaupt nichts mehr in speicherunsicheren Sprachen schreiben. Selbst wenn 70 % der kritischen Schwachstellen daher kommen: Was war die eigentliche Ursache? Vermutlich rührten die meisten Probleme daher, dass man für jedes kleine Objekt, das nicht auf dem Stack lag, malloc() oder explizites new nutzte, oder von der Handhabung nullterminierter Strings. Mit Arenen und Slices gäbe es davon viel weniger. Natürlich muss man in manchen Hochrisiko-Szenarien bestimmte Bugklassen vollständig eliminieren; dann hat Memory Safety oberste Priorität.

  Heißt das als Nächstes, man solle gar nichts mehr schreiben, das untrusted Input verarbeitet? Heißt das, man soll das Rad nicht neu erfinden, obwohl alle vorhandenen Räder quadratisch sind? Wenn man dafür JavaScript-Bloat vermeidet und die vom Browser bereitgestellten Formulare nutzt, hätte ich mit einem eigenen Web-Framework wahrscheinlich kein großes Problem.

  • Ich halte die Erbsünde von C dafür, dass beim Übergeben von Arrays die Grenzinformation verloren geht und alles zu Zeigern kollabiert.

  • Ich habe „roll your own crypto“ immer nicht als absolutes Verbot verstanden, sondern als starke Warnung. Es stimmt zwar, dass man auch ohne Doktortitel sicher implementieren kann, aber es erfordert immer noch enorm viel Lernaufwand.

    Wenn man nur eine Spezifikation sorgfältig umsetzt, braucht man vielleicht deutlich weniger davon. Aber die meiste Software will eine schnelle Krypto-Implementierung, und dann steigt die Komplexität massiv. Die verlinkte Monocypher-Schwachstelle ist ein gutes Beispiel. Plötzlich muss man verstehen, wie Twisted-Birational-Äquivalenz, Edwards-Punkte und die Montgomery Ladder zusammenhängen.

    Qualifikationen wie ein Doktortitel helfen anderen dabei, darauf zu vertrauen, dass du weißt, was du tust. Audits sind ein anderer Weg. Monocypher scheint von zwei Doktoren bei Cure53 auditiert worden zu sein. Das Problem ist, dass die meisten Programmierer nicht darauf vorbereitet sind zu beurteilen, ob eine Krypto-Bibliothek sicher ist, und deshalb auf nichttechnische Signale wie Qualifikationen oder die Qualifikationen der Auditoren zurückgreifen. Es wäre schön, wenn es direktere Methoden gäbe, aber Qualifikationen funktionieren ziemlich gut.

  • Dass es möglich ist, eigene Kryptografie zu schreiben, ist selbstverständlich. Wenn es unmöglich wäre, gäbe es auch keine Krypto-Bibliotheken. Die eigentliche Frage ist nicht, ob es möglich ist, sondern ob wir deiner oder meiner handgeschriebenen Kryptografie in einer Produktionsumgebung vertrauen würden, in der Nutzerpasswörter gehasht und private Daten geschützt werden. Ich würde das nicht.

  • In einem früheren Job nutzte alter Code MD5 für Lizenzprüfungen, und weil wir in einer Umgebung validieren mussten, in der alter C++-Code nicht ausführbar war, musste ich MD5 neu implementieren. Ich habe vorhandene Bibliotheken gesucht, aber keine unterstützte geänderte IVs.

  • Ich würde mich nie trauen, selbst Kryptografie zu schreiben, aber dass die Sicherheitsbranche inzwischen sogar davon abrät, die eigene Authentifizierung zu bauen, wirkt etwas überzogen.

• Es wäre schön, wenn Browser ein brauchbares Mehrfachauswahlfeld bereitstellen würden, ohne dass man es selbst implementieren muss.

  • Es gibt eins, aber es ist schrecklich.

• Zwei `` für Start- und Enddatum sind für Datumsbereiche umständlich und auch nicht intuitiv. Man zerlegt etwas, das konzeptionell eins ist, visuell in zwei getrennte Ansichten, die nicht zusammenzugehören scheinen.

  Dass es keinen Datumsbereich gibt, ist nur eines von vielen Problemen von ``. Man kann zum Beispiel keine bestimmten Daten ausschließen, weshalb es für fast jeden Reservierungsdienst von vornherein ungeeignet ist.

  Ich bezweifle, dass die Mehrheit bereit wäre, die kleine Zusatzlast von zwei Eingaben in Kauf zu nehmen, nur damit Daten überall gleich aussehen. Durchschnittliche Nutzer mögen Felder nicht, und schlimmer als ein Feld sind zwei Felder. Auch das Argument der Vertrautheit überzeugt mich wenig. Meiner Erfahrung nach sind native Datumseingaben im Web selten.

  • Ich habe mehrere Websites gesehen, die zwei Custom-Kalender-Widgets nebeneinander für Start- und Enddatum eines Datumsbereichs einsetzen, und beide funktionieren nicht richtig. Das macht es nur noch schlimmer.

  • Beim Teil über Datumsbereiche habe ich auch nicht zugestimmt. Ich nutze Datumsbereiche oft als Beispiel für ein konzeptionell einzelnes Control, das in der Praxis aber zeigt, wie komplex Dinge werden können. Das Motto „immer native Controls verwenden“ kann die User Experience verschlechtern, wenn man ein besseres, problembezogeneres Control anbieten könnte.

    Eine nützliche Funktion bei Datums-/Datumsbereichs-Controls, die sich nativ nicht umsetzen lässt, ist die Preisanzeige. Wenn man Flüge oder Hotels sucht, ist es sehr hilfreich, direkt im Date-Picker zu sehen, an welchen Tagen es günstiger oder teurer ist. Mit einem nativen Control müsste man sehr viel mehr klicken oder eine separate Tabelle anschauen, während ein Custom-Control solche Metadaten pro Datum anzeigen kann.

    Das klassische Beispiel ist die Eingabe des Geburtsdatums. Date-Picker zeigen standardmäßig meist den aktuellen Monat an, der mit dem gewünschten Datum fast nie etwas zu tun hat, was sie dafür denkbar schlecht macht. Hier kann ein Custom-Control sinnvoll sein, aber oft ist eine Kombination aus Textfeldern noch besser. Das ist nicht einmal ein vollständig eigenes Control, sondern eher eine Kombination nativer Controls, aber der Punkt ist, dass es keinen universellen Date-Picker gibt, der alle Fälle gut abdeckt.

• Das ist ein paar Jahre her, daher müsste ich es noch einmal prüfen, aber es gab leider einen Grund, warum wir statt des html5-Date-Pickers etwas Eigenes bauen mussten. Die ``-UI in manchen Browsern war wirklich grauenhaft.

  Selbst implementierte Kontextmenüs sind selten, aber wenn man sie braucht, sind sie sehr nützlich. Wenn man zum Beispiel einen Diagrammeditor in einer Webseite baut, möchte ich gern ein eigenes Kontextmenü haben, mit dem man durch Klick auf einen Knoten des Diagramms sinnvolle Aktionen ausführen kann. Es ist nicht gut, alle Interaktionen in eine reine Linksklick-UI zu pressen, etwa indem man zwischen einer Aktionspalette und Knoten hin- und herklickt.

  Dem Rest der Liste stimme ich stark zu.

• Ich weiß nicht, wie ich das Beispiel mit Kryptografie und das Problem mit Scrollverhalten zusammen lesen soll. Das wirkt auf mich wie zwei sehr verschiedene Bereiche.

  Der allgemeinen Aussage, dass Websites zu viel tun, stimme ich zu. Dieses Verhalten hängt aber von den Zielen der Nutzer und der Website ab.

  Könnte eine Einstellung wie prefers-user-scroll analog zu prefers-reduced-motion nicht eine Lösung irgendwo dazwischen sein?

  • Es gibt keinen legitimen Anwendungsfall für Scrolljacking, um einen vertikalen Scrollbereich zu implementieren. Solcher Code hätte nie geschrieben werden dürfen.

    Das gilt allerdings nur für vertikale Scrollbereiche. Wenn Scrollen auf Nicht-Scroll-Verhalten umgemappt wird, gibt es Anwendungsfälle, und auch wenn das weiterhin sehr problematisch ist, kann man etwa in vertikalen Schriftsystemen über die Abbildung von vertikal auf horizontal diskutieren. Vielleicht gibt es noch ein oder zwei weitere legitime Fälle, aber die tatsächliche Implementierung ist meist trotzdem schlecht.

• Dem Punkt kein selbst implementiertes Seitenscrolling stimme ich entschieden zu. Auf der KotlinConf habe ich einen interessanten Vortrag über die Schwierigkeiten der Scroll-Implementierung in Compose Multiplatform for Web gehört.

  Eines der Probleme war, dass Webbrowser weniger Scroll-Events senden als native Apps, wodurch ihr Algorithmus zur Berechnung der Scrollrichtung versagte. Er zeichnet eine Parabel durch alle Punkte und verwendet die Steigung am letzten Punkt, aber wenn es zu wenige Punkte gibt, kann die Scrollrichtung am Ende falsch herauskommen.

  Wenn man von anderen Plattformen portiert oder solche Interaktionen neu implementiert, startet man leicht mit falschen Annahmen oder vergisst das „seltsame“ Verhalten, das der Browser standardmäßig mitbringt.

  • Ich frage mich, wofür solche Scroll-Events in der Original-App verwendet wurden, dass man sie im Web-Kontext überhaupt nachbilden musste. Ich bin generell etwas skeptisch gegenüber der Nutzung von Scrollen als Antriebsinput für irgendetwas.

• Der Rat „verlass dich auf die Plattform“ ist richtig, aber mit der Plattform Schritt zu halten ist schwierig. Dinge wie enterkeyhint oder inputmode kennt man ungefähr, vergisst aber leicht, was sie konkret bewirken.

  Unser Team hat diese Woche [0] veröffentlicht, um dabei zu helfen. Es stellt Best Practices für Implementierungen in Form von Skills bereit. Die Dokumentation lässt sich auch für Menschen ziemlich gut lesen. Beispiel: [1]

  [0] https://github.com/GoogleChrome/modern-web-guidance [1] https://github.com/GoogleChrome/modern-web-guidance/…

• Der Ton des Artikels ist verfehlt. Es wäre viel produktiver, den Leuten zu erklären, wann und warum sie das Rad nicht neu erfinden müssen.

  Der Text erklärt die Gründe gut, wird aber durch die dogmatische Formulierung „nicht selbst machen“ schlechter.

  Auch das Motto „roll your own crypto“ nicht zu tun, fühlt sich letztlich wie ein Glaubenssatz an. Wer sind denn diese Experten, die das dürfen, und wer hat sie dazu ernannt? Haben sie überhaupt selbst in den Code geschaut, bevor sie so etwas sagen? Zeigen Schwachstellen wie Heartbleed nicht gerade, dass es in Wirklichkeit banale Fehler waren?

  • Das sind Menschen, die ihr Leben der Kryptografie gewidmet haben. Sie wurden nicht ernannt, sondern haben sich ihre Qualifikation erworben, indem sie nützliche Forschung veröffentlicht und sich der Überprüfung durch Leute gestellt haben, die das Fachgebiet kennen.

    Algorithmen werden veröffentlicht, geprüft, öffentlich angegriffen, verbessert und standardisiert. Das geschieht nicht hinter verschlossenen Türen. Die Papers sind öffentlich, der Code ist öffentlich. Man kann ihn jederzeit ansehen. Nur weil du ihn nicht angesehen hast, heißt das nicht, dass es niemand getan hat. Leute sehen ihn sich an und versuchen, ihn zu brechen. Wir benutzen ihn, weil er Angriffen standgehalten hat.

    Wenn dein Schluss aus Heartbleed lautet, OpenSSL selbst neu zu implementieren, garantiere ich dir, dass dein OpenSSL für jedes Heartbleed im echten OpenSSL fünfzig Heartbleeds hätte. Der Unterschied ist, dass das echte OpenSSL von Leuten überprüft, getestet, auditiert, angegriffen und verbessert wird, die wissen, was sie tun. Deins bliebe einfach privat falsch.

  • Der Punkt ist nicht, dass es einen unfehlbaren Experten gäbe, der furchtlos AES aufruft. Der Punkt ist, dass man durch die Nutzung eines populären Wrappers, der sicher funktioniert, Bugs zentral finden und beheben kann.

    Selbst wenn ein neuer Seitenkanalangriff entdeckt wird, kann man an einer Stelle reagieren. Bei einer Eigenimplementierung bekommt man solche Verbesserungen nicht, es sei denn, man verfolgt neue Angriffe in Vollzeit.

• Das ist eher eine Beschwerde über Leute, die Web-Tools schlecht einsetzen. Interessanter wäre es gewesen, auch legitime Fälle für Eigenimplementierungen zu behandeln. Dann könnte der Leser etwas Nützliches lernen, statt nur ein kindisches Modell von „niemals selbst machen“ mitzunehmen.

  Können bedeutet, sowohl das Wissen und die Fähigkeiten zu haben, etwas selbst zu bauen, als auch die Weisheit, zu wissen, wann man es nicht tun sollte.

  Das Ärgernis kann ich trotzdem nachvollziehen. Ich habe viele ähnliche Beschwerden. Das Problem ist, dass es nicht viele Bemühungen gab, Web-Interaktionen so gründlich und umfassend zu dokumentieren, dass Webentwickler leicht darauf zurückgreifen können. Es gibt ein ernstes Problem damit, dass programmiernahes Wissen nicht gut dokumentiert und nicht an die nächste Generation weitergegeben wird, weshalb dieselben Probleme immer wieder neu entdeckt werden. Meist setzt sich in der Branche irgendwann ein Standardpaket an Verhalten und Interaktionen durch, aber niemand schreibt es auf.