Dead Code = Evil Code

2 minutes read

Coder sind Messis. Ich habe bisher kaum ein größeres Projekt in den Fingern gehabt das keine Leichen im Keller hatte.

Das gängige Problem ist natürlich der “gewachsene” Code. Ein Projekt wird den Wasserfall runter entwickelt, geht live, geht in die Wartung. Dann kommt ein Feature dazu, ein anderes wird abgeschaltet. Am besten gibt es noch zig Schalter und Properties mit denen Teile des Quellcodes aktiviert oder deaktiviert werden könnten. Theoretisch.

Böse wird es dann wenn man auf Basis eines alten Projektes ein neues aufsetzen muss. Dann hat man diese bestehende Code Basis. So richtig weiß man nicht was da so alles passiert und dann kommt der Onkel aus der Projektleitung uns meint das man dieses und jenes Feature ja dann in Phase 3 oder 4 vielleicht brauchen wird, daher soll man es doch bitte im Code lassen.

Bullshit. Ehrlich das ist Bullshit. Vor 50 Jahren vielleicht als Quellcode noch auf Lochkarten gepresst wurde, da hat es Sinn ergeben alten Code aufzubewahren. Heute sollte es Teil eines jeden halbwegs soliden Refactorings sein das man unbenutzen Code rausschmeißt.

Warum?

  1. Toter Code gerät in Vergessenheit. Was man nicht wartet wird vergessen. Irgendwann ist der Schöpfer des lähmenden Brockens nicht mehr im Team, gar nicht mehr im Unternehmen und dann findet sich der neue Entwickler im Tal der WTF’s wieder.
  2. Ungenutzer Code wird allgemein schlechter getestet. Klar gibt Unit- und Integrationstests, aber wenn die Funktion nicht mehr im Testplan ist steigt die Wahrscheinlichkeit von Fehlern kontinuierlich an. Und spätestens wenn man ihn dann wieder einbinden will fängt man an im Nebel zu stochern weil irgend was nicht funktioniert.
  3. Ungenutzer Code liegt bei Refactorings im Weg. Wir eine Bibliothek angepasst oder etwas an der Codebasis verändert von welcher der tote Code abhängt entstehen unnötige Aufwände. Im schlimmsten Fall wird ein Refactoring gar als unmöglich eingestuft nur weil da ja noch eine Klasse von abhängt oder mit refactored werden müsste.
  4. Ungenutzer Code macht ein Projekt unübersichtlich und komplex. Dadurch wird es schwerer neue Funktionen zu integrieren, die Bibliothek an anderer Stelle zu verwenden und neue Entwickler in ein Projekt zu integrieren.

Alles in allem wiegen diese Probleme um so schwerer, je monolitischer und größer ein Projekt allgemein ist. Eine feine kleine Bibliothek wird von Natur aus dazu neigen weniger Leichen zu beinhalten als ein riesen eCommerce Framework. Nichtsdestotrotz möge ein jeder Entwickler und Projektleiter mal in sich gehen wenn er das nächste Mal ein Feature abschaltet ob der Code wirklich noch gebraucht wird.

Und ganz ehrlich, es tut niemandem weh einen Tag im Git zu machen und den Code rauszuwerfen. Denn wenn man wirklich in nem Jahr eine Funktion wieder braucht, dann schaut man nach was man da rausgeworfen hat und refaktoriert eben genau dann und spart der Weile eine Menge Arbeit und WTFs. Ob man dabei dann auf Basis des gelöschten neu implementiert oder direkt wieder verwendet ist dann auch egal.

Los Verschlüsseln - Let's Encrypt ?!

2 minutes read

Vor 15 Jahren wäre ich ja fast auf die Idee Idee gekommen ein Trust-Center zu eröffnen. Zu diesem Zeitpunkt erschien mir das Geschäftsmodell ziemlich clever. Man lässt sich fürstlich dafür bezahlen ein paar Befehle auf der Kommandozeile auszuführen damit Webseiten mit Verschlüsselung zu versorgen.

Zu dieser Zeit waren es aber auch maximal Banken und Zahlungsanbieter oder offensichtlich mit sensiblen Daten arbeitende Seiten welche überhaupt verschlüsselten. Tatsächlich wusste mancher SEO ja auch aus Erfahrung das Google kein SSL kann und überhaupt Datenverlust oder Massenüberwachung waren damals kaum ein Thema.

Das Konzept dieser Trust-Center war (und ist) aber einfach geil. Ich konnte meine Seite zwar auch verschlüsseln, aber wenn ich nichts bezahlen wollte dann gab es jedes mal eine fette Warnung vom Browser das mein Zertifikat nicht vertrauenswürdig sei. Wenn ich mich nicht täusche gilt das gleiche auch immer noch für CAcert, ein Projekt das Authentizität und Verschlüsselung mittels eines Netzwerks von engagierten Assurern kostenlos zur Verfügung stellen wollte.

Zwischendurch gab es noch StartSSL von welchen man neben bezahlten Zertifikaten auch kostenlose bekommen konnte. Letztere waren nur 1 Jahr gültig und die Authentizität wurde nur über E-Mails sichergestellt. Inzwischen verschiedentliche Probleme und Besitzerwechsel welche dazu führten das alle großen Browser diese Zertifikate inzwischen ablehnen.

Mit verschiedenen Exploits in Verschlüsselungsmechanismen, Datenpannen und unerwarteter Überwachung ging nun auch ein Wandel einher. Plötzlich ist es schick jede Seite zu verschlüsseln. Kosten darf das natürlich weiterhin nix und in diese Bresche ist nun Let’s Encrypt gesprungen. Bei dieser Initiative reicht es einen Client per Git auszuchecken, seine E-Mail und Domain anzugeben und zusätzlich noch seine Webserver Konfiguration anzupassen. Allein damit kann man sich in jedem Browser gültige Zertifikate unterzeichnen lassen.

Ich finde das geil und ich benutze es auch weil ich meinen Besuchern eine bequeme Möglichkeit bieten möchte verschlüsselt auf mein Blog zuzugreifen. Aber und das scheint bei Let’s Encrypt nie so richtig rüber zu kommen: Durch ein kleines Grünes Schloss sind Daten nur auf dem Weg vom Browser zum Server geschützt! Was dort damit passiert, wer den Server betreibt und was der damit macht, darüber sagt das Schloss bei Let’s Encrypt so gar nichts aus.

Warum? Wenn ich physischen Zugriff auf einen Server habe, dann kann ich dort E-Mails empfangen, Webseiten hosten und Let’s Encrypt Zertifikate installieren. Meiner Meinung nach ist Let’s Encrypt eine coole Idee, aber die versprochene Sicherheit sehe ich durchaus mit gemischten Gefühlen. Was den Part der Authentizitätsprüfung angeht war CAcert deutlich fortgeschrittener, leider haben die es aber nicht in unter die von den Browsern vertrauenswürdigen Trust-Center geschafft.

Am Ende lässt sich wohl mit der “Volksverschlüsselung” kein Geld verdienen. Echte Authentizität gibt es aber weiter nicht auf dem Grabbeltisch.

Schnüsch

1 minutes read

Zur Abwechslung auch mal Foodbloggen, soll ja in sein ;) Die Schnüsch ist ein Gemüseeintopf aus dem Raum Schleswig. Zutaten sind klassisch Hülsenfrüchte, Kartoffeln, Kohlrabi, Karotten welche in Milch gekocht werden.

Zutaten

  • 500g Kartoffeln
  • 250g Möhren
  • 250g Grüne Bohnen
  • 250g Erbsen
  • 250g Kohlrabi
  • 1 Liter Milch
  • 125g Sahne / Schmand
  • 1 Bund Petersilie

Als zusätzliches tierisches Protein eignen sich kleine Hack- oder Fleischbällchen. Alle Zutaten am besten frisch besorgen oder wenn nicht Verfügbar durch gefrostete Version ersetzen.

Zubereitung

  • Gemüse ordnungsgemäß putzen und in kleine Würfel / Stücke / Streifen schneiden
  • Möhren und Kohlrabi 3-5 Minuten in Butter andünsten
  • Restliches Gemüse zugeben und knapp mit Wasser bedecken, salzen, aufkochen und ca 10-15 Minuten gar köcheln lassen
  • Den Topf von der Hitze nehmen und den Gemüsefond abgießen
  • Eine Mehlschwitze anrühren und mit Milch, Sahne und etwa der Hälfte vom Gemüsefond und der Petersilie aufkochen und dann wieder zum Gemüse geben
  • Das Ganze nochmals etwa 5 - 10 Minuten bei geringer Hitzer köcheln lassen
  • Am Ende ggf. noch mit Salz, Muskat und weißem Pfeffer abschmecken

Android Browser Berechtigungen

5 minutes read

Die Datenschutzhelden stellten gestern die Frage “Muss es immer eine App sein?” und geben darauf die Antwort das oftmals auch der Zugriff via Browser besser sicherer sei was den Datenschutz betrifft. Primäres Argument gegen die individuelle App ist dabei die vielzahl von Berechtigungen die manche App fordert.

Ich sehe das tatsächlich differenziert, denn auch die bekannten Browser sind nicht gerade sparsam was die Berechtigungen angeht. Wozu ein Browser den Telefonstatus lesen muss oder Zugriff auf Kamera und Mikrofon benötigt erschließt sich mir nicht ganz.

Nebenbei bringt die Verwendung von Webseiten statt Apps unter Umständen auch ganz andere Risiken mit sich. Ausgehend von verschiedensten JavaScripts, Cookies und Angriffen auf die Infrastruktur der Betreiber ergibt sich hier eine breite Angriffsfläche. Und diese Angriffe habe ich deutlich weniger unter Kontrolle als die Berechtigungen einer App. Hier kann ich selbst immer entscheiden ob ich sie installiere oder nicht.

Um einen Überblick zu bekommen, habe mir also mal die Mühe gemacht und die mir bekannten großen Browser in Hinblick auf die Android Systemberechtigungen zu vergleichen:

Berechtigungen der Browser im Überblick

Berechtigung Firefox Opera Chrome Dolphin Dolphin Zero
Geräte- & App-Verlauf ja ja ja ja nein
Identität ja nein ja ja nein
Kontakte ja nein ja ja nein
Standort ja ja ja ja ja
Telefon nein ja nein nein nein
Fotos/Medien/Dateien ja ja ja ja ja
Speicher ja ja ja ja ja
Kamera ja ja ja nein nein
Mikrofon ja ja ja ja nein
WLAN-Verbindungsinformationen ja ja ja ja nein
Geräte-ID & Anruferinformationen nein ja nein nein nein
Dateien ohne Benachrichtigung herunterladen ja nein ja nein nein
Verknüpfungen auf dem Startbildschirm lesen nein ja ja ja nein
Verknüpfungen für den Startbildschirm schreiben nein ja ja nein nein
Daten aus dem Internet abrufen ja ja ja ja nein
Netzwerkverbindungen abrufen ja ja ja ja ja
mit Bluetooth-Geräten koppeln nein ja nein nein nein
WLAN-Verbindungen herstellen und trennen ja nein nein nein nein
WLAN-Multicast-Empfang zulassen nein ja nein nein nein
Zugriff auf alle Netzwerke ja ja ja ja ja
Audio-Einstellungen ändern nein ja ja nein nein
Nahfeldkommunikation steuern ja ja ja ja nein
Beim Start ausführen ja ja ja ja nein
Über anderen Apps einblenden ja ja nein nein nein
Vibrationsalarm steuern ja ja ja ja nein
Ruhezustand deaktivieren ja ja ja ja nein
Verknüpfungen installieren ja ja ja ja nein
Verknüpfungen deinstallieren ja nein nein ja nein
Konten erstellen und Passwörter festlegen ja nein nein nein nein
Synchronisierungseinstellungen lesen ja nein ja nein nein
Konten von Geräten verwenden ja nein ja ja nein
Systemeinstellungen ändern ja nein nein ja nein
Synchronisierung aktivieren oder deaktivieren ja nein ja nein nein
Synchronisierungsstatistiken lesen nein nein ja nein nein
Lesezeichen setzen Webprotokoll aufzeichnen nein nein ja ja nein
Google-Servicekonfiguration lesen nein nein ja nein nein
Speicherplatz der App ermitteln nein nein nein ja nein
Hintergrund festlegen nein nein nein ja nein

Dolphin Zero war mir tatsächlich unbekannt geht mir aber mit dem Verzicht auf eine lokale Browserhistorie einen Schritt zu weit. Mit fehlt hier Datentechnisch ein Mittelfeld das einfach nur Webseiten ordentlich anzeigen kann dabei aber Fuzzy Features wie Kamera, Synchronisierung oder Vibrationsalarmsteuerung außen vor lässt.

Youtube Video Previews

1 minutes read

Die quasi einzige Art um, wie kürzlich schon geschrieben, Youtube Video datenschutzfreundlich zu verlinken ist es ein Preview Bild zu machen und mit einem Link zu hinterlegen.

Damit man nicht wie blöde Screenshots machen und zuschneiden muss, kann man ganz einfach das normale Preview Bild von Youtube holen indem man eine URL mit folgendem Format aufruft: http://img.youtube.com/vi/<youtube video id>/0.jpg. Für <youtube video id> verwendet man den Hash aus dem Youtube Video Link.

Das Bild muss man natürlich lokal auf dem eigenen Blog ablegen, sonst provoziert man wieder einen externen Request.