Az

Schriftart wählen

Schriftgröße wählen

Zeilenabstand wählen

Schnellzugriff Verlauf Funktionen
21
© Uwe Ohse
21
* ** *** **** Vollbild
©...

Farbanalyse

Hilfe

Diese Seite überflutet Dich, wenn alles klappt, mit einer Vielzahl von Darstellungen der Farben des Bildes.

Durch Ziehen der grauen Kästchen kann man die untereinander sortieren (die Sortierung wird auch beim nächsten Laden der Seite beachtet).

Histogramme
Das klassische Histogramm gibt es in mehreren verschiedenen Versionen: RGB, HSL, und die sechs Kanäle jeweils einzeln.
Dekonstruktionen
Das sind Darstellungen, bei denen ein Kanal einzeln gezeigt wird (R/G/B, H/S/L und Y/Cb/Cr). Blaue Pixel zeigen Null- und rote Pixel Maximalwerte (255).
Dazu kommen noch drei Darstellungen, die die Pixel mit dem Wert ihres minimalem / mittlerem und maximalem RGB-Kanals zeigen.
Wellenformen
Wellenformen repräsentieren auf einer Achse eine Achse des Bildes, und auf der anderen Achsel die Verteilung der Pixel auf der anderen Achse an.
Alle Beschreibungen dafür sind wahnsinnig kompliziert und überflüssig, nachdem man die erste Wellenformdarstellung eines Bildes mit größeren Farbflächen gesehen hat.
Vektor-Scope
Vektor-Scope zeigen die Farbe des Bildes im Verhältnis zu Sättigung und/oder Helligkeit an.

Ein Wort der Warnung: Keine dieser Darstellungen sagt irgendetwas über die Qualität eines Bildes aus. Sie sagen gerade mal etwas über Farbverteilungen.
Es gibt weder ein "richtiges" Histogramm noch ein Falsches (High Key / Low Key), und das gilt auch für alle anderen Darstellungen.
Es gibt nicht mal "richtige" Farben.

RGB-Histogramm

Dies ist das klassische Histogramm über die Rot-, Grün- und Blaukanäle. Alle Kanäle werden unabhängig voneinander normiert (die Maxima sind alle gleich hoch), und die Darstellung ist linear.

RGB-Histogramm

Ein Histogramm, das mit Rot den Farbtonkanal (H aus HSL), mit Grün die Sättigung (S), und mit Blau die Helligkeit (L) zeigt.
Alle Kanäle sind unabhängig normiert (die Maxima sind immer gleich hoch), und die Darstellung ist linear.

Rotkanal

Zeigt den Rotkanal des Bildes als Graustufenbild (der Rotkanal wird dabei in die beiden anderen Kanäle kopiert). Blaue Pixel haben einen Rotwert von 0, blaue Pixel einen von 255 (beide zeigen also Extremwerte an, die bei größeren Flächen Unter- oder Überbelichtungen sein könnten).

Rotkanal

Zeigt den Grünkanal des Bildes als Graustufenbild (der Grünkanal wird dabei in die beiden anderen Kanäle kopiert). Blaue Pixel haben einen Grünwert von 0, blaue Pixel einen von 255 (beide zeigen also Extremwerte an, die bei größeren Flächen Unter- oder Überbelichtungen sein könnten).

Blaukanal

Zeigt den Blaukanal des Bildes als Graustufenbild (der Blaukanal wird dabei in die beiden anderen Kanäle kopiert). Blaue Pixel haben einen Blauwert von 0, blaue Pixel einen von 255 (beide zeigen also Extremwerte an, die bei größeren Flächen Unter- oder Überbelichtungen sein könnten).

Hue-Kanal (Farbwinkel auf dem Farbkreis)

Zeigt den Farbwinkel des Bildes als Graustufenbild (der Winkel wird dabei auf einen Maximalwert von 255 umgerechnet und in die drei Farbkanäle geschrieben).
Dafür werden die Pixel von RGB nach HSL konvertiert.

Sättigung

Zeigt die Sättigung des Bildes als Graustufenbild (die Sättigung wird dabei in die beiden anderen Kanäle kopiert). Blaue Pixel haben eine Sättigung von 0, blaue Pixel eine von 255 (beide zeigen also Extremwerte an, die bei größeren Flächen Unter- oder Überbelichtungen sein könnten).
Dafür werden die Pixel von RGB nach HSL konvertiert.

Relative Helligung (L)

Zeigt die Helligkeit des Bildes als Graustufenbild (die Helligkeit wird dabei in die beiden anderen Kanäle kopiert).
Blaue Pixel haben eine Helligkeit von 0, blaue Pixel eine von 255 (beide zeigen also Extremwerte an, die bei größeren Flächen Unter- oder Überbelichtungen sein könnten).

Dafür werden die Pixel von RGB nach HSL konvertiert.

Y-Kanal (YCbCr)

Zeigt die Grundhelligkeit der Pixel als Graustufenbild.
Dafür werden die Pixel von RGB nach YCbCr konvertiert.
Diese Information mag hilfreich sein, weil JPEG intern YCbCr verwendet.

Cb-Kanal (YCbCr)

Zeigt die Blau-Gelb-Farbkomponente der Pixel als Graustufenbild. Blau wird als Dunkler, und Gelb als heller Pixel gezeigt.
Dafür werden die Pixel von RGB nach YCbCr konvertiert.
Diese Information mag hilfreich sein, weil JPEG intern YCbCr verwendet.

Cb-Kanal (YCbCr)

Zeigt die Rot-Grün-Farbkomponente der Pixel als Graustufenbild. Rot wird als Dunkler, und Grün als heller Pixel gezeigt.
Dafür werden die Pixel von RGB nach YCbCr konvertiert.
Diese Information mag hilfreich sein, weil JPEG intern YCbCr verwendet.

Minimalkanal

Hier bleiben die Farbkanäle erhalten, die die kleinsten RGB-Werte haben.

Mittelkanal

Hier bleibt der Farbkanal erhalten, deren Wert zwischen denen den beiden Anderen liegt (RGB).

Maximalkanal

Hier bleiben die Farbkanäle erhalten, die die größten RGB-Werte haben.

Wellenform: RGB

Die X-Achse repräsentiert die X-Achse des Bildes.
Die Y-Achse zeigt die Intensitäten der drei RGB-Kanäle. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diese Intensität haben.

Dieses Wellenformdiagramm stellen die RGB-Farbkanäle im räumlichen Kontext dar.

Wellenform: R

Die X-Achse repräsentiert die X-Achse des Bildes.
Die Y-Achse zeigt die Intensität des Rot-Kanals. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diese Intensität haben.

Dieses Wellenformdiagramm stellt den Rot-Kanal im räumlichen Kontext dar.

Wellenform: G

Die X-Achse repräsentiert die X-Achse des Bildes.
Die Y-Achse zeigt die Intensität des Grün-Kanals. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diese Intensität haben.

Dieses Wellenformdiagramm stellt den Grün-Kanal im räumlichen Kontext dar.

Wellenform: B

Die X-Achse repräsentiert die X-Achse des Bildes.
Die Y-Achse zeigt die Intensität des Blau-Kanals. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diese Intensität haben.

Dieses Wellenformdiagramm stellt den Blau-Kanal im räumlichen Kontext dar.

Wellenform: HSL

Die X-Achse repräsentiert die X-Achse des Bildes.
Die Y-Achse zeigt die Intensitäten der drei HSL-Kanäle. Der H-Kanal (Farbwinkel, Hue) des Bildes wird auf dem Rotkanal abgebildet, die Sättigung auf dem Grün- und die Helligkeit auf dem Blaukanal.

Dieses Wellenformdiagramm stellt Farbwinkel, Sättigung und Helligkeit im räumlichen Kontext dar.

Wellenform: H

Die X-Achse repräsentiert die X-Achse des Bildes.
Die Y-Achse repräsentiert den H-Kanal (Farbwinkel, Hue, im HSV-Farbraum) des Bildes. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diesen Farbwinkel haben.

Dieses Wellenformdiagramm stellt den Farbwinkel im räumlichen Kontext dar.

Wellenform: G

Die X-Achse repräsentiert die X-Achse des Bildes.
Die Y-Achse repräsentiert die Sättigung (im HSV-Farbraum) des Bildes. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diesen Farbwinkel haben.

Dieses Wellenformdiagramm stellt die Sättigung im räumlichen Kontext dar.

Wellenform: B

Die X-Achse repräsentiert die X-Achse des Bildes.
Die Y-Achse repräsentiert die Sättigung (im HSV-Farbraum) des Bildes. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diesen Farbwinkel haben.

Dieses Wellenformdiagramm stellt die Helligkeit im räumlichen Kontext dar.

Vertikale Wellenform: RGB

Die Y-Achse repräsentiert die X-Achse des Bildes.
Die X-Achse zeigt die Intensitäten der drei RGB-Kanäle. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diese Intensität haben.

Dieses Wellenformdiagramm stellt die RGB-Kanäle im räumlichen Kontext dar.

Vertikale Wellenform: R

Die Y-Achse repräsentiert die X-Achse des Bildes.
Die X-Achse zeigt die Intensität des Rot-Kanals. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diese Intensität haben.

Dieses Wellenformdiagramm stellt den Rot-Kanal im räumlichen Kontext dar.

Vertikale Wellenform: G

Die Y-Achse repräsentiert die X-Achse des Bildes.
Die X-Achse zeigt die Intensität des Grün-Kanals. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diese Intensität haben.

Dieses Wellenformdiagramm stellt den Grün-Kanal im räumlichen Kontext dar.

Vertikale Wellenform: B

Die Y-Achse repräsentiert die X-Achse des Bildes.
Die X-Achse zeigt die Intensität des Blau-Kanals. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diese Intensität haben.

Dieses Wellenformdiagramm stellt den Blau-Kanal im räumlichen Kontext dar.

Vertikale Wellenform: HSL

Die Y-Achse repräsentiert die X-Achse des Bildes.
Die X-Achse zeigt die Intensitäten der drei HSL-Kanäle. Der H-Kanal (Farbwinkel, Hue) des Bildes wird auf dem Rotkanal abgebildet, die Sättigung auf dem Grün- und die Helligkeit auf dem Blaukanal.

Dieses Wellenformdiagramm stellt Farbwinkel, Sättigung und Helligkeit im räumlichen Kontext dar.

Vertikale Wellenform: Hue/Farbwinkel

Die Y-Achse repräsentiert die X-Achse des Bildes.
Die X-Achse repräsentiert den H-Kanal (Farbwinkel, Hue, im HSV-Farbraum) des Bildes. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diesen Farbwinkel haben.

Dieses Wellenformdiagramm stellt den Farbwinkel im räumlichen Kontext dar.

Vertikale Wellenform: Sättigung

Die Y-Achse repräsentiert die X-Achse des Bildes.
Die X-Achse repräsentiert die Sättigung (im HSV-Farbraum) des Bildes. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diesen Farbwinkel haben.

Dieses Wellenformdiagramm stellt die Sättigung im räumlichen Kontext dar.

Vertikale Wellenform: L

Die Y-Achse repräsentiert die X-Achse des Bildes.
Die X-Achse repräsentiert die Sättigung (im HSV-Farbraum) des Bildes. Die Helligkeit jedes Pixels zeigt die Anzahl der Pixel an, die diesen Farbwinkel haben.

Dieses Wellenformdiagramm stellt die Helligkeit im räumlichen Kontext dar.

Vektor-Scope: Geo

Diese Darstellung zeigt die Chromazität.

Die Distanz vom Zentrum der Graphik repräsentiert den "Abstand" der Sättigung und Helligkeit vom hellsten Weißton. Die Helligkeit gibt die Anzahl der Pixel wieder. Der Abstand wird hier als Wurzel der Summe der Quadrate von Sättigung und Helligkeit berechnet.

Vektor-Scope: Luminanz

Diese Darstellung zeigt die Chromazität.

Die Distanz vom Zentrum der Graphik repräsentiert die Helligkeit der Bildpixel, und die Helligkeit der Graphik die Anzahl der Bildpixel mit der Helligkeit und dem Farbton.

Vektor-Scope: Sättigung

Diese Darstellung zeigt die Chromazität.

Die Distanz vom Zentrum der Graphik repräsentiert die Sättigung der Bildpixel, und die Helligkeit der Graphik die Anzahl der Bildpixel mit der Sättigung und dem Farbton.
  • Hintergrundfarbe ändern
  • Kontextmenü-Emulation abschalten
https://naturfotografen-forum.de/data/o/291/1456781/thumb.jpghttps://naturfotografen-forum.de/data/o/291/1456781/image.jpg
Eingestellt:
Aufgenommen: 2017-11-06
UO ©
Dieser Buntspecht zerlöchert die Dämmung eines Hauses.

Dieser Text ist länglich, und befasst sich nicht mit Spechten!

Menschliche Artefakte in diesem Forum

Wir haben hier schon lange eine etwas unlogische Situation: Während wir bei den Landschaften Bilder mit Gebäuden oder manchmal auch Booten oder Schiffen darauf oft ablehnen, akzeptieren wir Bilder, auf denen ein Greifvogel auf einem Pfahl sitzt, auch wenn der Pfahl oft eine größere Fläche einnimmt als das Gebäude es getan hätte.

Ich denke, wir verstehen alle, warum das so ist - nämlich dass sich der Vogel dahin gesetzt hat, und den Ansitz damit "geadelt" hat.
Wir akzeptieren da die Entscheidung des Vogels, der sich über die "Natürlichkeit" (16) seines Ansitzes keine großen Gedanken gemacht hat. Wir akzeptieren nicht die Entscheidung eines Fotografen, der sich möglicherweise viele Gedanken über den Bildausschnitt gemacht hat.

Richtig nett ist das nicht, und ich kann verstehen, dass manche Benutzer ziemlich sauer reagieren, wenn man ihre Bilder in die Rubrik für Unerwünschtes verschiebt.

Davon abgesehen ist es auch nicht richtig logisch, und man braucht eine gewisse Logik, wenn man Regeln formulieren will, zum Beispiel Regeln darüber, was wir hier akzeptieren.

Nun haben wir von administrativer Seite die Frage, welche Bilder wir hier akzeptieren, in letzter Zeit etwas lockerer gesehen. Wohin das führt, kann man gut in Mensch und Natur sehen, wo doch Einiges zusammengekommen ist, dass nicht so recht in die Rubrik passen will. Wie es mit der Rubrik weiter geht? Ich weiß es noch nicht, das wird noch diskutiert.

Ich könnte mir vorstellen (wertet das bitte nicht stärker), dass wir in M&N in Zukunft nur noch Bilder mit entweder klar erkenntlichem Bezug zum Spannungsfeld Mensch/Natur akzeptieren, oder solche, bei denen das aus der Beschreibung _klar_ hervorgeht.

Zwei versteckte Kaninchen
So versteckt wie diese zwei Kaninchen sollte der Bezug zum Thema bei Bildern in Mensch und Natur nicht sein.
Ja, da sind zwei Kaninchen.

Aber was machen wir mit dem Rest? Für den haben wir bisher so eine Art Müllrubrik ("Administrativ unerwünscht"), deren Inhalte man kaum noch finden kann (schon gar nicht, wenn man kein Admin ist). Da finden sich Bilder mit als zuviel empfundenen menschlichen Artefakten neben Ziegen, die den Sonnenaufgang betrachten, oder Fohlen, die toben. Auch Hunde und Katzen… ach ja, und dann und wann richtigen Schrott. So manche Bilder darin sind übrigens richtig gut, nur thematisch unpassend.

AU, wie die Rubrik in Kurzform heißt, ist ein hartes Urteil: Ein Admin oder Moderator hat das Bild gesehen, und für unwürdig erachtet. Nun könnte der Autor dagegen andiskutieren, und das passiert auch manchmal. Aber nicht oft… was manchmal daran liegt, dass das Urteil einfach akzeptiert wird, aber sicher ebenso oft daran, dass man alleine gegen eine oder mehrere "Autoritäten" diskutieren müsste, was, ganz vorsichtig gesagt, nicht richtig attraktiv ist. AU unterbindet jede Möglichkeit, dass sich andere ein Bild über das Bild machen. Und das ist nicht gut (um nicht eine deutlich härtere Sprache a la "großer Mist" zu verwenden), immerhin ist das hier nicht ein Präsentations-, sondern ein Diskussionsforum, auch wenn wir das manchmal aus den Augen verlieren.

Kater Kobold
So bitte nicht.



Es wird Zeit, das zu ändern. Rund um die Natur ist eine neue Rubrik für Bilder, die nicht so richtig hier hinein passen, aber noch einen Bezug zur Natur haben. Ich weiß nicht, wie wir das langfristig handhaben werden, aber für den Moment wird es so sein:

  • Bilder, die einem Moderator oder Administrator unpassend erscheinen, aber eben diesen Naturbezug noch haben, werden in RUDN (ich wünschte, mir würde ein Name einfallen, der Sinn ergibt und sich zu RUDEL abkürzen lässt) verschoben werden.
  • Bilder aus der Rubrik werden auf der Startseite vielleicht nur eingeschränkt sichtbar sein. Ich stelle mir das so vor, dass Benutzer sie voll sehen können, Gäste aber nicht (die Variante, Gästen nur die aktuellsten zu zeigen, beißt sich leider mit dem Endlos-Scroll), aber da ist noch nicht wirklich entschieden.
  • Auch ein direkter Upload ist möglich.



Was wir auch in dieser Rubrik nicht sehen wollen, sind Bilder, deren Naturbezug nur marginal ist.

Also das Meerschweinchen im Käfig, im schlimmsten Fall noch von oben fotografiert. Oder Hauskatze auf Katzenbaum, Hund beim Beinchenheben, Pferd auf Weide. Das ist bestimmt alles völlig natürlich, aber es ist auch alles Allerweltskram aus sehr durch den Menschen geprägtem Umfeld. Der Bezug zur Natur muss etwas stärker sein.

Ich empfehle, auch die Rubrikbeschreibung zu lesen.

Ins Wasser gefallener Baum
Ein ins Wasser gefallener Baum, den ich aufgrund der Sichtverhältnisse niemals ganz hätte ablichten können. Ein paar Monate später wird die Ecke voller Jungfisch gewesen sein.
Dass das vorkommt, ist ganz natürlich. Aber an diesem Baggersee passiert es zu oft, die Ufer sind einfach instabil.

Meine Fotografie in 2017

Die Bilder, die ich hier zeige, stammen alle aus 2017. Aber das war fast meine ganze Ausbeute (von "Taunus im Nebel" gibt es noch viel mehr, aber mehr Nebelbilder verträgt dieser Text nicht).

Ja, das war wenig.

Gänse? Die habe ich am Anfang des Jahres in Ruhe gelassen, ich weiß nicht mehr warum. Kröten und Frühblüher? Fielen der verletzten Hand zum Opfer. Wie übrigens auch so einige freie Zeit, die ich zum Programmieren hätte nutzen können.

Tauchen/Schwimmen? Erst die verletzte Hand, dann so richtig miese Sicht, dann später wieder eine Verletzung, und dann war ich noch beruflich weit weg von hier, in einer Gegend ohne offensichtlich auch nur halb attraktive Gewässer. So kann das nichts werden.

Immerhin, ich hab' ein paar Karpfen gesehen. Und einen Mini-Schwamm. Die Bilder waren Speicherplatzverschwendung.

Eine paar Mal Schildkröten beim Sonnen auf dem Ast. Und einmal eine unter Wasser - in der trüben Brühe, in schneller Bewegung Bild: Trauriges Gesicht

Aber ein paar Landschaftsaufnahmen waren dabei. Und Katzen. Sogar ein Kaninchen.

Ich wollte jetzt im Dezember Gänse fotografieren. Wann immer so etwas wie eine Spur Blau am Himmel war, konnte ich gerade nicht. Wobei das Licht vermutlich sowieso schon wieder weg gewesen wäre, bis ich nur zur Haustüre herausgekommen wäre. Was für ein Mistwetter…

Das wird besser werden. Die Fotografie, und auch das Wetter. Letzteres natürlich erst in einer gefühlten Ewigkeit.

Verlassene Köcherfliegenlarve
Gehäuse einer Köcherfliegenlarve. Sie hat es verlassen, um über Wasser für den Fortbestand der Art zu sorgen.

Ein paar Gedanken zur Forumssoftware

Ich arbeite seit nun seit 2006 an dieser Forumssoftware (die paar Jahre 4images vorher zählen dafür nicht).

Damit habe ich für mich ein paar Rekorde gebrochen:

  • das Projekt ist größer als alle Anderen, an denen ich außerhalb des
    Berufes gearbeitet habe, und auch größer als die meisten, mit denen
    ich beruflich zu tun hatte (da dürfte nur Eines größer gewesen sein),
  • ich habe noch nie ein Softwareprodukt so lange gewartet,
  • und ich habe mich noch nie in einer Spätphase eines Projektes so sehr
    darüber geärgert. Das liegt auch am Produkt von Zeit und Projektgröße, denn
    Vieles würde ich heute so nicht mehr machen, entweder weil ich gelernt
    habe oder weil es heute bessere Wege gibt.

    Aber es liegt nicht nur an Zeit x Codezeilen. Ich komme darauf noch mal zurück.

Fundamentale Änderungen an Programmiersprachen


Auf die Gefahr hin, dass mich verschiedene Vertreter meiner Branche (Programmierung im Allgemeinen, Web im Besonderen) für einen Häretiker halten, muss ich doch mal ein paar Sachen los werden.

Zuerst mal sind die meisten Techniken, die in der Branche Jahr für Jahr begeistert gefeiert werden, weit weniger wert als die Werbung dafür glauben machen will.

Und das trifft in besonderem Maße auf Techniken zu, die bereits vorhandene, aber irgendwo mangelhafte, Programmiersprachen aufhübschen sollen, in dem Sprachfeatures nachgerüstet werden, den den Charakter einer Programmiersprache ändern (dies geht also nicht gegen Verbesserungen an sich).

Als die Gebrüder Wright auf den Gedanken kamen, einen Motorflieger zu bauen, haben sie doch nicht Flügel an ein Auto gehängt, nur weil Autos Motor, Räder und Sitze haben. Nein, die waren smarter.

Ich möchte dafür zwei Beispiele anführen.

Taunus-Pano
Taunus, Panorama. Wirkt nicht? Ja, manche Bilder müssen groß sein.

Beispiel 1: Promises

Promises in Javascript haben ihre Berechtigung, denn sie räumen die elenden, unglaublich unübersichtlichen und nahezu unlesbaren Callback-Wüsten auf.


Ein Einschub: Mit der Erfahrung eines Menschen, der ziemlich
lange ziemlich intensiv Javascript gemacht hat, behaupte ich,
dass die _meisten_ Callbackwüsten Folgen eines schlechten
Softwaredesigns sind.

Was nicht asynchron sein kann, braucht auch keine Callbackhölle.

So weit, so gut.

Nur ist realer existierender älterer Javascript-Code meistens, vielleicht bei größeren Projekten sogar immer, so angelegt, dass er den Nutzen von promises beschränkt oder ganz aufhebt.

So zuletzt gesehen in realem Code, der versucht hat, ein paar Daten aus dem Netz zu laden, und wenn das nicht geklappt hat, versucht hat, mit alten Daten weiterzumachen, wenn sie denn da waren (da wurde eine Karte aufgebaut, und im Notfall sollten dann weniger detaillierte Daten, die schon da waren, hoch interpoliert werden).

Das Ganze fiel auf die Nase, weil irgendwo in dem schönen neuen Code dann eine alte Funktion aufgerufen wurde, die eine Ausnahme warf, (so eine Art Fehlermeldung, die man unbedingt abfangen muss).

Leider hat wohl niemand auf dem Schirm gehabt, dass es alten Code gibt… und prompt fiel die Fehlerbehandlung übel auf die Nase und hinterließ eine halb gezeichnete Karte.

Die Fehler an der Stelle _richtig_ abzufangen war dann kompliziert und keineswegs mehr schön.

Reh
Zum Weglaufen... Vor dem Fotografen natürlich.

Beispiel 2: Exceptions in PHP

Eines meiner Lieblingsthemen - normalerweise begleitet von wilden Verwünschungen.

Am Beispiel von intdiv, einer relativ neuen Funktion zur Division zweier Ganzzahlen (3/2 liefert 1, nicht 1.5). Die Funktion ist also wirklich trivial, was die im Folgenden geschilderten Eigenwilligkeiten nur noch unverständlicher macht.

Zitat von laut Dokumentation::

Return Values

The integer quotient of the division of dividend by divisor.

Errors/Exceptions

If divisor is 0, a DivisionByZeroError exception
is thrown. If the dividend is PHP_INT_MIN and the
divisor is -1, then an ArithmeticError exception
is thrown.

Soll heißen, intdiv(N,0) ist ebenso verboten wie intdiv(PHP_INT_MIN,-1), und in beiden Fällen wird eine Ausnahme gemeldet. Für alle anderen Fälle wird der Quotient zurückgegeben.

Das heißt, der Aufruf soll ungefähr so aussehen:


try {
print intdiv($a,$b);
} catch (Exception $e) {
... hier Fehlerbehandlung.
}

Ich soll zum Punkt kommen? Na gut. Aber nicht zu schnell, erst einmal etwas "Spaß" am Rande:

 
Eingabe:
$a=PHP_INT_MIN-1;
print "intdiv $a/7 is: ".var_export(intdiv($a,7),1)."\n";
Ausgabe:
intdiv -9.2233720368548E+18/7 is: -1317624576693539401

Ganzzahldivisionen von Fließkommazahlen sind also erlaubt. Kein Schönheitspreis für die PHP-Entwickler (dass INT_MIN-1 plötzlich zum Fließkommawert wird, bekommt auch keinen).

Und dass das Ergebnis vielleicht nicht ganz das ist, was man erwarten würde, wenn man INT_MIN durch 7 teilt, liegt einfach daran, dass PHP_INT_MIN tatsächlich INT64_MIN ist.

Modifizieren wir das ein bissel…

 
Eingabe:
$a=PHP_INT_MAX+1;
print "intdiv $a/7 is: ".var_export(intdiv($a,7),1)."\n";
Ausgabe:
PHP Warning: intdiv() expects parameter 1 to be integer, float given in - on line 1
intdiv 9.2233720368548E+18/7 is: NULL

Mit einer schönen, großen, _positiven_ Fließkommazahl geht es aber nicht. Ah ja. Soviel zum Thema Konsistenz.

Aber Inkonsistenz ist nicht, worauf ich hinaus will. Nach 13 Jahren PHP wäre Konsistenz eine Überraschung.

Nein, ich will auf die NULL in der letzten Ausgabezeile hinweisen. Laut Dokumentation kann die gar nicht kommen.

Jetzt könnte man sagen, die Dokumentation ist schlecht, und ja, die PHP-Dokumentation ist oft genug schlecht. Auch hier. Aber nicht das ist hier das Problem, sondern dass die PHP-Interna derartig unübersichtlich sind, dass die Entwickler schon nicht mehr sehen können, was _triviale_ Funktionen so tun. Der Entwickler, der den Code geschrieben hat, wusste gar nicht, was in dem Drumherum um seine paar Zeilen Code passiert.

Was jetzt dazu führt, dass man, um die Funktion benutzen zu können, das tun muss:


try {
$tmp = intdiv($a,$b);
if (NULL === $tmp) {
... hier Fehlerbehandlung.
}
} catch (Exception $e) {
... hier noch eine Fehlerbehandlung.
}

Herzlichen Glückwunsch - wir haben hier das "Beste", was man sich vorstellen kann, doppelte Fehlerbehandlung für eine triviale Funktion.

Kaninchen
Kaninchen. Eine ganze Gruppe war an dem Tag wie im Paarungsrausch.

Die grundlegende Ursache des Problems ist, dass die PHP-Interna noch genug Stellen haben, und auch haben müssen, an denen sie keine Ausnahmen liefern, sondern andere Fehlersignale, und dass neuerer Code des PHP-Interpreters an allen Ecken und Enden darauf achten muss, wie der die Fehlersignale, die ältere Funktionen liefert, übersetzt.

Warum passiert das nicht?

  • weil Fehlerbehandlung grundsätzlich unsexy ist. Das wird nebenher
    gemacht, weil es sein muss. Nicht mehr. Das ist ein grundlegendes
    Problem in der EDV. Und eines, das durch den Gebraucht von Exceptions eher schlimmer wird, weil die dazu verleiten, Fehlerbehandlung auf eine höhere Ebene abzuschieben, was in vielen Fällen gleichbedeutend mit dem Ignorieren der Fehler ist, wenn man auch ein reineres Gewissen hat.
  • und weil man, im Fall von PHP, viel über die Interna wissen müsste,
    um solche Fehler zu vermeiden - und überhaupt auf die Idee zu kommen,
    dass sie auftreten könnten, und man die Funktion dagegen schützen muß.

Diese Sorte von Fehlern wird PHP noch über Jahre liefern, und das
wird ein großes Vergnügen für alle Betroffenen.


Scherbe

Das möchte man im Wasser nicht sehen, schon gar nicht noch näher kennen lernen, aber darauf nehmen zu viele keine Rücksicht.

PHP an sich


Das Forum ist ja in PHP geschrieben. Nun ist meine Meinung zu PHP immer schon durchwachsen gewesen (in diesem Sinn: Ja, es ist schlecht [ersatzweise ein Anderes mit sch beginnendes Wort], aber das Projekt war halt in PHP geschrieben, und außerdem sind andere Sprachen entweder selbst nur anders schlecht oder haben furchtbare Bibliotheken.

Wenn man mit circa einer Million kleiner und großer Inkonsistenzen leben kann, kann man mit PHP arbeiten - und einige Teile des PHP-Ökosystems, speziell einige der Standard-"Erweiterungen" (wenn es mitgeliefert wird - warum nennt man es dann 'Erweiterung'?), waren und sind richtig gut und zuverlässig, was so manches ausgeglichen hat.

Und ohne richtig guten Grund sollte man Code nicht neu schreiben - oder verschiedene Sprachen mischen. Überflüssigerweise Code anzufassen, der funktioniert, ist eine Garantie für neue Fehler, und verschiedene Sprachen zu mischen, na ja, stellt euch eine Zeitung vor, in der jeder Absatz in einer anderen Sprache geschrieben wurde.

Dann kam vor ziemlich genau Jahren PHP Version 7. Damit ist nun vieles besser geworden. Oder?

Sicher, einiges ist besser geworden. Die Performance wird gerne angeführt, und das war hier im Forum auch deutlich spürbar. Etliche Inkonsistenzen in der Syntax sind weg, und das ist ein Segen, nutzt aber älterem Code erst mal gar nichts. Und das Forum _ist_ älterer Code.

Aber das PHP-Ökosystem gammelt vor sich hin.

Kassiopeia von unten
Kassiopeia, gammelt nicht.

PEAR gammelt vor sich hin

Auf _dem_ System, auf dem Erweiterungen gesammelt werden (Pear), ist nichts von dem, was ich brauche, oder was mich interessiert hat, für PHP 7 verfügbar.


Ein Einschub: Ich kenne Composer. Und das ist auch ganz toll,
wenn die Pakete für Composer gemacht sind, und man sie findet.
Aber packagegist.org ist eine Müllhalde. Für jeden Suchbegriff 10
bis 30 Pakete, die meisten davon nahezu bis ganz undokumentiert
und teilweise vermutlich ungetestet.

Auch das ist Gammel. Jede Sammelstelle für Code braucht eine
Qualitätssicherung, sonst entsteht nur eine weitere Müllhalde
(github und SourceForge sollten das eigentlich hinreichend
bewiesen haben. Wobei bei github die Perlen wenigstens auffindbar sind).

Ich habe zwar alles, was ich brauchte, für PHP 7 gefunden, aber ohne Ausnahme nur deshalb, weil schon jemand anders danach gesucht hatte, und google die passenden Antworten geliefert hat. Verstreut im Netz, mal hier, mal da, und vermutlich ist nicht eines der Pakete von einem der Originalentwickler auf PHP 7 portiert worden.

Das ist gar nicht gut, insbesondere weil es auch Pakete betrifft, auf die von den PHP-Webseiten verwiesen wird, die also schon irgendwie offiziellen Charakter haben.

Ich habe mir das jetzt zwei Jahre angesehen, und ich sehe keine Besserung in irgendeiner Hinsicht. Und das stört mich gewaltig.

Wobei ich den beiden Entwicklern, die sich um Pear kümmern (ja, es sind nur zwei - wenn nicht gar, wie der eine behauptet, nur 1,5) keinen Vorwurf machen möchte. Versagen tun da Andere.

Twister im Gras
Twister, gammelt auch nicht.

Die Dokumentation rottet vor sich hin, Teil 1

Nehmen wir mal die Ankündigung für PHP 7.2, die ganz oben auf php.net zu finden ist:


PHP 7.2.0 comes with numerous improvements and new features such as
[...]
New sodium extension

Offensichtlich ist der ganzen Menschheit klar, das Sodium nicht Salz ist, sondern eine Kryptografie-Bibliothek (sonst würde es da ja stehen). Die Annahme würde ich so nicht gemacht haben, aber sei's drum.

Gucken wir uns doch mal die Dokumentation zu dieser Bibliothek an, und zwar die zur Funktion crypto_auth_keygen (so heißt sie in libsodium, der Grundlage der PHP-Sodium-Erweiterung) oder sodium_crypto_auth_keygen (so heißt sie in PHP):
pre]
sodium_crypto_auth_keygen

(PHP 7 >= 7.2.0)

sodium_crypto_auth_keygen — Description

Description
ReturnType sodium_crypto_auth_keygen ( void )

Warning
This function is currently not documented; only its argument list is available.

Aha. Jetzt weiß immerhin mehr als vorher - nämlich dass das nicht zur Benutzung gedacht ist.

So sind übrigens alle Funktionen dieser Erweiterung "dokumentiert".

_Erfahrungsgemäß_ wird das binnen eines Jahres dokumentiert sein. So halbwegs jedenfalls. Also so, dass man sich den Rest aus der
libsodium-Dokumentation zusammenreimen kann.

Falls man denn bereit wäre, sich die Dokumentation für kryptografische Funktionen zusammenzureimen, meine ich. Wozu niemand bereit sein sollte.

Die Dokumentation rottet vor sich hin, Teil 2

In der Dokumentation sehr vieler Funktionen findet man in den Benutzerkommentaren Hinweise auf Probleme oder Überraschungen. Sie werden praktisch nie in die Dokumentation eingepflegt.

So basieren crc32("abc") und hash("crc32b", "abc") auf dem AUTODIN II Polynom (Ethernet), während hash("crc32") das ZModem-Polynom verwendet.

Der Umgang mit gemeldeten Fehlern

Was den Umgang der PHP-Entwickler mit gemeldeten Fehlern betrifft, möchte ich eigentlich darüber lieber nichts sagen, weil es mir im Moment echt schwer fällt, auf sehr deutliche und nicht jugendfreie Ausdrücke zu verzichten.

Ich lasse mal das aktuellste Beispiel weg, weil ich mich darüber noch so gar nicht beruhigt habe, und nehme mal ein etwas Älteres, https://bugs.php.net/bug.php?id=70419 .

In Kurzform:

  1. Ich melde am 3.9.2015: zwei Funktionen haben unbrauchbare
    Rückgabewerte, die verhindern, dass man im Fehlerfall erfahren kann,
    wie sich die aufgerufenen Programme beendet haben. (Ich halte das
    für sehr problematisch).
    Das war noch vor dem PHP7-Release, und hätte, wenn man denn gewollt
    hätte, darin geflickt werden können.
  2. Das Ganze gammelte bis zum 25.8.2016 herum. Dann:
  3. "Es ist jetzt zu spät für 7.0. Also müsste diskutiert werden ob
    das in 7.2 rein kann oder auf 8.0 warten muss. Ein 'PR' *könnte*
    helfen, die Diskussion zu starten."

    Hey, ich dachte, das, was ich die geschrieben hatte, wäre ein PR.
    Ach so, _könnte_. Ja, klar.


Nun ist das kein Einzelfall:

Der PHP-Bugtracker ist voll von Problemen, an die niemand ran geht.

Ich habe so eine Ahnung, woran das liegt: Für jede noch so kleine Änderung am Verhalten muß man eine Diskussion in php-internals durchhalten und meistens auch noch einen RFC dort verfassen - und nebenher den Code schreiben.

Für Bugfixes macht das keiner. Schon gar nicht, wenn man sich verarscht vor kommt.

Liebe Entwickler von Open Source Projekten, und das bezieht sich jetzt wirklich nicht nur auf die PHP-Leute: verarscht mich nicht. Wenn ich mir schon die Mühe gemacht habe, einen Fehler von euch zu finden und die Ursache zu bestimmen, und euch auch noch Bescheid sage, dann erwartete ich wenigstens Respekt für diese Arbeit. Aber nicht "wir haben es jetzt ein Jahr liegen lassen, schreib' noch mal".

Retrospektive, Teil 1


Zitat von Ich schrieb im letzten Jahr::
Ein weiteres Ziel? Vielleicht den BBCode-Krempel zu entsorgen. Wenn ich mich im nächsten Adventskalendertürchen nicht wieder damit herum schlagen müsste, wäre schon viel gewonnen.

Ich hatte, und habe, mich noch nicht dazu durch gerungen, auf etwas Anderes zu wechseln. Ich neige dazu, Markdown für eine gute Alternative zu halten, aber ich habe auch ein paar hunderttausend Texte in der Datenbank, die BBCode enthalten.

Der Zustand der verwendeten BBCode-Library ist jedenfalls nicht besser geworden. Da hat sich einfach nichts getan, und das Risiko ist ziemlich groß, dass sie nicht aktualisiert wird, wenn sich die PHP-Internas das nächste Mal ändern. Mit anderen Worten: Die kann mit jedem größeren Update unter den Tisch fallen, und da müsste eine Alternative her, die eben die vielen alten Texte verarbeiten kann.

Leider sind die üblichen, in PHP geschriebenen Interpreter allesamt in einem der kritischen Fälle extrem langsam - oder haben einen geradezu lächerlichen Speicherbedarf. Alle Getesteten sind ausnahmslos unbrauchbar.

Es sieht so aus, als brauchte ich diese Bibliothek noch eine ganze Weile, und eine Option wäre, sie selbst zu flicken, sobald es denn nötig ist, und es kein Anderer tut. Leider hieße das, sich in die PHP-Internas einzuarbeiten, und das _will_ ich nicht.

Ganz und gar und überhaupt nicht. So wie PHP nach draußen wirkt, also ohne jede logische Struktur, so wirken auch die Interna auf mich, auf den ersten und zweiten Blick jedenfalls. Damit ich mich damit weiter beschäftige, muss ich bezahlt werden.

An der Stelle haben sich meine Überlegungen eine ganze Weile im Kreis gedreht. Monate, um genau zu sein: 7 Monate von Mai bis Dezember.

PHP und das Forum

Mein Unmut über PHP ist über die Jahre gewachsen. Dennoch _kann_ man damit arbeiten. Man braucht, insgesamt, für viele Sachen mehr Zeit als mit anderen Sprachen, aber das rechtfertigt nicht, dass ganze Projekt neu zu schreiben (wir reden hier von gefühlten Ewigkeiten meiner Zeit, und einer
gefühlt unendlich großen Zahl von Möglichkeiten, neue und alte Fehler einzubauen).

Die Entscheidung, trotzdem alledem mit PHP weiter zu machen, habe ich zum ersten Mal bewusst in 2005 getroffen. Damals waren um die 20000 Zeilen Code und HTML im Repository, heute sind es locker 130000 (plus noch Einiges, was hoffentlich nirgendwo mehr im Einsatz ist, was ich aber aus Rücksicht auf andere Nutzer nicht einfach rauswerfen kann).

Das wäre natürlich ein Grund, mit PHP weiter zu machen.

Auf der anderen Seite ist das Projekt nun ziemlich alt, und schleppt einigen Ballast mit sich herum, den man neu schreiben _müsste_.


  • Da ist die Template-Engine. Ja, die ist immer noch verdammt schnell,
    aber man sieht ihr das Alter zu sehr an, und sie ist auch zu eigen,
    als dass Andere damit arbeiten könnten. Sie auszuwechseln ist möglich,
    aber dann schreibe ich nicht nur die Templates neu (das wäre ein gutes
    Werk), sondern auch viel vom aufrufenden Code (auch ein gutes Werk,
    wenn man dabei aufräumt).
  • Dann wäre da die BBCode-Bibliothek, die man austauschen müsste.
  • Dann müsste ich das Rechtesystem von ein paar Altlasten befreien (kann
    dem Code nicht schaden, und wäre auch ein gutes Werk).
  • Dann müsste ich den Cache-Layer um die Objektverwaltung mal neu machen
    (da könnte man viel Zeit einsparen, wenn man ein paar hundert Kilobyte
    shared memory opfert), und eventuell auch den Cache für die größeren
    Sachen vereinheitlichen (also Seitenbestandteile, Datenbankabfragen,
    ...). Das wäre auch ein gutes Werk.
  • Dann müsste ich mal den Startup-Code reduzieren. Wie auch immer, aber
    irgendwie muss ich von 6 Millisekunden, die der im Idealfall frisst,
    runter kommen. 6 Millisekunden klingt nach wenig? Für eine normale
    Seite fällt es auch nicht ins Gewicht. Für Ajax-Kram dagegen schon. Und
    ich nicht mehr, wie ich den Startup-Code reduzieren kann. Da läuft
    nichts mehr, was ich nicht brauche, und es wird bereits gecacht, was
    irgendwie gecacht werden kann.
  • Dann müsste ich… da gibt es noch vieles. Viele Aufräumarbeiten, um
    Konsistenz in den Code zu kriegen (alter Code benutzt neue Möglichkeiten
    nicht… das ist zwar logisch, macht aber den Durchblick nicht leichter).

In der Summe ist das ganz schön viel Zeug, was neu geschrieben werden
müßte.

Wenn man an der Stelle steht, lohnt es sich doch, mal nachzudenken, ob man nicht etwas größer denken sollte.

Das habe ich die letzten paar Monate gemacht. Und experimentiert. Und festgestellt, dass mich die Javascript-basierten Frameworks anekeln, weil ich Javascript und seine Abarten verabscheue. Ich werde nicht um JS herum kommen, aber ich muss die Zeit, die ich damit verbringe, nicht auch noch maximieren.

Übrigens ist meine Meinung über die meisten Frameworks negativ. Die meisten wollen eine perfekte Lösung für ein Problem sein, aber keines von Ihnen ist es. Wenn mir ein Framework Hindernisse in den Weg legt, weil meine Idee, wie man die Dinge tut, nicht zum Framework passt… sagen wir, ich habe nicht umsonst Schraubendreher in verschiedenen Größen, mal Schlitz, mal Kreuz - und nebenbei noch Zangen und Hämmer und…

Rust? Ganz nett, ja, aber mit Sprachen mit komplexen Syntaxen bin ich noch nie lange glücklich gewesen. Ease of use, und so.

Dann stolperte ich über Go. So a la "Stimmt, das gab es ja auch noch. Hm.". Und hab' angefangen, die ersten Funktionen dahin
auszulagern. Ich schätze, als nächstes kommt der Datenbanklayer. Und dann der Objektcache. Und dann BBCode. Und dann das Rechtesystem.
Und dann…

Vielleicht schreibe ich zwischendurch noch irgendwann das Linux-ZModem darin neu. Nach 20 Jahren Stillstand sollte man das mal in Erwägung ziehen.

Retrospektive, Teil 2

Ich hatte mir für dieses Jahr etwas fest vorgenommen, nämlich das:

Zitat:
Ein guter Anfang wäre vermutlich, das ganze Ajax-Gehampel mal neu zu machen. Es wäre viel gewonnen, wenn Fehlermeldungen zuverlässig da ankommen, wo ich sie haben möchte, und nicht irgendwo unter gehen, wo ich nicht mal eine Chance hatte, einen Blick darauf zu werfen - oder Du.

Das ist zu einem gewissen Teil erledigt. Schwer zu sagen, ob 50 oder 90% - gefühlt sind es eher 50%, aber es waren die schwierigeren Teile…

Ich hatte mir davon Einiges erhofft, und fast nichts davon ist eingetreten. Die minimale Performanceverbesserung - ja. Aber was nutzt es, wenn an einer unkritischen Stelle eine von zwei Millisekunden entfällt? Es wäre etwas Anderes, könnte ich diese Millisekunde im Startup-Code des Forums einsparen, aber im Browser?

Das Ajax-Geraffel ist jetzt besser lesbar. Das ist eine Verbesserung. Aber
weil die Fehlerbehandlung deutlich komplizierter wurde, als ich das
anfangs geahnt hatte, ist der Code immer noch nicht richtig gut.

Flexibler ist es auch geworden, aber da habe ich feststellen müssen, dass ich überschätzt habe, wie viel Flexibilität ich brauche. Der Fall, für den ich optimiert habe, tritt in der Praxis so gut wie gar nicht auf. Das hätte ich doch vorher wissen können… oder?

Leider hätte ich mir das tatsächlich denken sollen. Habe ich aber nicht, und so habe habe ich jetzt wieder ein Stückchen überkomplizierten Code geschrieben. Hm.

Auf der anderen Seite war es wirklich eine gute Idee… theoretisch. Die Praxis ist so feindselig gegenüber guten Ideen…

Auch die andere gute Idee, die ich an dieser Stelle hatte, scheiterte ähnlich:

Sie war, ein paar Netzwerkanfragen einzusparen, in dem man Anfragen an andere Anfragen dran hängt. Das ist insbesondere deshalb sinnvoll, weil die eigentliche Bearbeitung der Antworten nur ein paar Millisekunden kostet, aber die Netzwerklatenz so im Bereich von 100 Millisekunden liegt - und dafür dann ein oder mehrere Anfragen vorzuziehen, von denen ich sicher weiß, dass sie erfolgen werden.

Theoretisch ist das das eine gute Idee. Und der erhoffte Effekt ist auch _messbar_ eingetreten. Fühlbar ist das allerdings nicht (und das war das Ziel). Im Gegenteil, fühlbar hat sich die Sache verschlechtert. Vorher war es so, dass sich eine Information alle 15 (ein Beispiel) Sekunden aktualisiert hat. Nach der Änderung hat sie sich nach 15 oder auch 10 Sekunden aktualisiert, und das fühlte sich verstörend unregelmäßig an.

Im Nachhinein ist das sonnenklar. Das hätte es auch im Vorfeld sein können, wenn ich das Problem mal von der anderen Seite aus betrachtet hätte.

Twister auf Ast
Unter Beobachtung

Eine kurze Betrachtung zu Fragen der Privatsphäre…

Datenschutz im Falle transnational verbreiteter Daten:



  1. Sobald Daten an ein anderes Land weitergegeben werden, ganz egal ob Peru oder die Vereinigten Arabischen Emirate, kann man nur noch _glauben_, dass die dort so behandelt werden, wie es die Datenschutzgesetzes des Ursprungslandes der Daten erlauben.

    Man kann es nicht _kontrollieren_.
  2. Und für den Fall, dass die Daten plötzlich ihren Weg in Hände finden, in denen sie nichts zu suchen haben, kann man nicht einmal klagen, denn zum einen enthalten diese internationalen Abkommen meist Klauseln, die Klagen in Bagatellfällen ausschließen (und die Definition von 'Bagatelle' ist hier durchaus nicht kompatibel mit dem Schaden für einzelne Menschen), zum Anderen ist der Gerichtsstand nicht da, wo er hingehört (ein reguläres Gericht des Ursprungslandes, _nicht_ aber eines des Ziellandes - und schon gar kein internationales Schiedsgericht), und zum Dritten kann man Daten nur selten ansehen, wer sie verkauft hat.
  3. Aus Daten gewinnt man Informationen, Informationen sind Macht, und Informationen sind Geld wert.
  4. Die Möglichkeit der Kontrolle und die Möglichkeit der Klage sind _alles_, was zwischen den Daten und ihrer illegalen Ausnutzung steht.

Mit anderen Worten: Daten, die erst mal die Grenzen der eigenen Gesetze verlassen haben, sind derzeit Freiwild.

Taunus im Nebel
Taunus im Nebel

Die Browser:


Aber Datenschutz und Privatsphäre werden nicht nur vom Staat oder der EU gefährdet.

Sie werden auch durch Programme gefährdet, die wir Tag für Tag laufen lassen. Sagen wir mal Firefox (https://drewdevault.com/2017/12/16/Firefox-is-on-a-slippery-slope.html). Mozilla hat das nach einen Shitstorm schnell wieder abgestellt, aber so etwas (Zwangsinstallation von fremdem Code unbekannter Herkunft) _macht_ man gar nicht erst.

Wie kommt man auf eine solche Idee? Waren da Dollar-Zeichen in den Augen, oder waren da Gehirne wegen spontaner Lobotomie nicht mehr zurechnungsfähig?

Und warum entsteht Nutzern dieses Programmes (und Anderer Programme) Schaden, ohne dass das irgendwelche Konsequenzen hat? Was läuft da falsch, dass leichtfertige Verantwortungslosigkeit ausgesessen werden kann? Ist es, weil der Schaden nicht quantifizierbar ist? Warum nimmt man dann Null an, nicht Unendlich? Ist es, weil nicht zweifelsfrei belegbar ist, wer schuldig ist? Warum in aller Welt lassen wir Microsoft, Ubuntu, Firefox, Google und Co damit durchkommen, dass man auf diesen Systemen überhaupt nicht nachvollziehen kann, was wann warum geschehen ist?

Und dann ist da noch… ja, genau, Google Chrome. Google, das größte Werbeunternehmen der Welt ist. Genug gesagt?

Vielleicht nicht. Ein Browser hat jede Menge Daten - über das Verhalten des Benutzers. Und Google liebt Daten. Alleine das wäre, in einer vernünftigen Welt, ein Grund, diesen Monsterkonzern zu zerschlagen (aber dies ist keine).

Ich will hier jetzt nicht übermäßig meckern, aber wieso trauen wir diesen Programmen?

Warum erschießen wir nicht mal ein paar Verantwortliche, damit die Nächsten ins Grübeln kommen? (für den Fall, dass das nicht klar sein
sollte: Das war eine Überspitzung. Und ich habe keine Schusswaffen. Weil die Jahreszeit für unpassende Geschenke ist: Ich will auch keine. Die Dinger gehören nicht in meine Hände. Und Deine. Und… verstanden?).

Taunus im Nebel
Taunus immer noch im Nebel

Die Webseiten:


Datenschutz und Privatsphäre werden auch von Firmen und Personen gefährdet, die Webseiten betreiben und Daten verkaufen oder ohne Einwilligung gebrauchen oder einfach unbewusst weiter reichen.

Und ich will hier nur _eine_ Seuche ansprechen - die meiner Meinung nach Schlimmste, die Einbindung von Inhalten und Bibliotheken auf Servern Dritter.


Einschub: Warum finde ich das schlimmer als Tracking in Werbung?
Weil man damit auch auf vielen Seiten trackbar wird, auf den
keine Werbung ist. Wenn ich Werbung sehe, weiß ich, dass
irgendjemand jetzt meine Bewegungsdaten hat. Das ist ein
Automatismus.

Wenn ich keine Werbung sehe, gehe ich instinktiv davon aus, dass ich nicht getrackt werde.


Und weil Werbung mit Werbeblockern mehr oder weniger schadlos
geblockt werden kann, während irgendwelche Funktionen fehlen,
wenn eine Bibliothek nicht geladen werden kann - und ich nicht
mal sehen kann, welche das sind.

Millionen Seiten im Web veranlassen die Browser der Besucher, sich Javascript-Bibliotheken, Videos, Bilder, Karten und Schriften aus dem Netz zu ziehen. "Aus dem Netz" heißt praktisch immer "von Google". (Twitter- und Facebook-Buttons sind auch nicht besser).

Vielleicht sollte ich das umformulieren? "veranlassen die Browser, Bewegungsdaten der Benutzer an den weltgrößten Werbekonzern zu senden." Denn das ist es, was passiert.

Am Beispiel von Google Maps: Bei jeder Darstellung einer Karte sendet der Browser die Kennung der Seite an Google (die meldet sich auf diese Art über den Browser des Benutzers an). Zusammen mit der unvermeidlichen IP-Adresse und der Uhrzeit kann man daraus, insbesondere wenn man noch andere Dienste anbietet, ein wunderbares Bewegungsprofil machen. Ein sogenannter Fingerabdruck des Browsers (https://www.heise.de/newsticke [verkürzt] -auch-ohne-Cookie-3597078.html , https://amiunique.org/faq) ist auch hilfreich, klar.

Und wenn jemand glaubt, dass Google das nicht täte, dann irrt er (dito für die anderen Datenkraken).

Der Kartendienst ist längst nicht der einzige Datensammeldienst, den Google aus purer Gutherzigkeit (?) betreibt.

Da wären beispielsweise ajax.googleapis.com (darüber werden Javascript-Bibliotheken ausgeliefert) oder der Schriftartendienst fonts.google.com.

Das Ziel dieser so kostenlosen Dienste ist es, möglichst viele Bewegungsdaten zu bekommen. Und aus denen möglichst gute Profile zu gewinnen - um zielgerichtet Werbung zu liefern.


Einschub: Außer Datenschutzbedenken gibt es noch
genug Andere gegen diese Praxis.

Da ist beispielsweise die Frage der Sicherheit. Ist es eine
kluge Idee, ausführbaren Code von fremden Servern zu laden?
Wäre es das eine gute Idee, wenn der Server nicht bei Google
stünde, sondern beim vietnamesischen Geheimdienst? Oder
vielleicht bei der Mafia? Oder einem Unternehmen, dass Gewinn
durch Minimierung des Sicherheitsbudgets maximiert?



Warum ist Google da vertrauenswürdiger? Vielleicht weil diese
Dienste bis jetzt nicht aufgehackt worden sind? Das sind meine
auch nicht (und meine sind auch schon 20 Jahre alt), aber was
heißt das schon? Das heißt nur, dass der peinliche Moment
noch kommt.

Oder vielleicht ist auch nur, weil bisher kein Hack bekannt geworden ist?

Dann wäre da noch die Frage der Geschwindigkeit.

Es gab eine Zeit, da war die Einbindung von Schriften und
Bibliotheken von den Google-Servern deutlich schneller als sie
vom typischen kleinen Webhostingserver zu laden. Aber das hat
sich für https-Seiten schon deutlich relativiert, und nun,
im Zeitalter von http2, verkehrt sich das oft ins Gegenteil,
speziell wenn der eigentliche Webserver schnell ist, was er
sowieso besser sein sollte.



Das letzte Argument für die Benutzung von ajas.googleapis.com
und dem Fontserver ist Bequemlichkeit. Und die rechtfertigt die
Nebenwirkungen nicht.

Taunus im Nebel
Taunus im Nebel 3

Profile:


Die Verfahren zum Zusammensetzen von Informationen werden immer besser.

Bald werden sie gut genug sein, für die Mehrzahl von euch zielgerichtete Werbung auf den Monitoren an der U-Bahn-Haltestelle einzublenden. Wie peinlich wird es sein, wenn für den Mann auf der einen Bank Werbung für ein Nobelrestaurant gezeigt wird, für Dich aber McDoof? Sie eine Galapagos-Reise mit allen Extras, Du Malle?

Ihr meint, das wird keiner wollen? Doch. Werbung funktioniert besonders gut, je genauer man das Ziel trifft. Das ist in der virtuellen Welt so, und es ist auch in der realen Welt so.

Und glaubt ja nicht, dass das nicht geht. Unsere Smartphones liefern physische Bewegungsdaten. Smartphones und größere Computer liefern virtuelle Bewegungsdaten. Das zusammen zu setzen ist keine Kleinigkeit, aber mit entsprechendem Aufwand machbar. Und der Aufwand _wird_ betrieben (jetzt, nicht erst in Zukunft).

Dass in diesen zusammengesetzten Daten noch euer Name und die Adresse fehlt, ist ein Feigenblatt, hinter dem sich die Branche gegen die Datenschutzgesetze versteckt. Aber mehr ist es auch nicht.

Facebook hat euren Namen. Google hat euren Namen. Hundert Andere haben euren Namen.

Und die Adresse? Da braucht man doch nur bei der Post fragen - die betreibt für ihre "Partner" eine Dienst zum Säubern von Adressen. Und diese Partner zeichnen sich dadurch aus, unverlangt Briefkästen vollzumüllen.

Wir stehen nun kurz davor, dass es diese perfekten Profile gibt.

Taunus im Nebel
Taunus im Nebel, 4

Datenschutz und Privatsphäre, Finale:


Ich persönlich glaube, dass es Zeit wird, die Entwicklung mal zu Bewusstsein zu bringen: In Kürze werden die größten Datendienstleister und Werbeunternehmen der Welt mehr über euch wissen, als ihr selbst, und sie werden dieses Wissen _nutzen_.


Ein kleiner Einschub: gelegentliche Fehler in den Profilen
interessieren übrigens nicht. Die gehen im Rauschen unter.

Das ist so lange wenig kritisch, so lange es nur um Werbung geht.
Es wird extrem kritisch, sobald es um andere Fragen geht.

Dieses Wissen für die gewinnversprechendste Werbung zu nutzen ist eine Sache (wobei ich da schon gewisse Bedenken habe).

Aber im nächsten Schritt läßt sich damit noch viel mehr machen. Menschen mit ähnlichem Profil fahren richtig saumäßig Auto? Klar, die Versicherung wird höher. Menschen mit ähnlichem Profil werden öfter krank? Du bekommst den Job nicht. Menschen mit ähnlichem Profil wohnen normalerweise in günstigeren Gegenden? Die Versicherungsprämien Deiner Nachbarn steigen, Deine Kinder werden in anderen Stadtteilen eingeschult. Menschen mit ähnlichem Profil kaufen meist ein 600er-Tele? Der Verkäufer weiß das auch, und redet Dir das 500er aus.

Und auch das ist erst der Anfang.

Wenn wesentliche Bewertungen von Menschen durch automatische Verfahren getroffen werden, deren Funktionsweise nicht offen gelegt wird, und die durch Interessengruppen, die von der Gesellschaft nicht kontrolliert werden können, verändert werden können, dann _wird_ die Gesellschaft eines Tages eben diesen Interessengruppe angepasst werden - mit anderen Worten, von diesen kontrolliert werden.

Falls ihr denkt, das kann nicht funktionieren: https://de.wikipedia.org/wiki/Sozialkredit-System_(VR_China) (und das ist noch harmlos - sobald physische Bewegungsdaten hinzu kommen, wird das erst richtig übel).

Falls ihr denkt, es könnte hier nicht kommen: Es ist technisch machbar, es verspricht Gewinn, also wird es kommen, wenn sich niemand wehrt. Vielleicht kommt es auch, wenn sich jemand wehrt, aber dann hätte man es wenigstens versucht.

Es ist Zeit, dass diese Entwicklung gestoppt wird. Egal wie.

Grübel' doch mal eine Weile darüber nach, bitte.

Katze mit Menschen
Spiegelung

Das Bild entstand in einem Gnadenhof mit Tierheim und -Pension während eines Tages der offenen Tür. Fotografieren war da schon unter anderen Umständen nicht einfach, aber an dem Tag… Dieses eine Bild gefällt mir jedoch.

Zu guter Letzt möchte ich Danke sagen - danke an alle Helfer, Silke, und insbesondere auch an Toph.

Und euch wünsche ich frohe Weihnachten, viel Spaß hier, und möge 2018 euch Gutes bringen.

Meise im Spechtloch
Die Meise ist nur neugierig. Der Specht war's. Ich hab's gesehen.
Technik:
Brennweite 105.6mm, entsprechend 587mm Kleinbild
10/5000 Sekunden, F/2.8, ISO 200
Belichtungsautomatik, automatischer Weißabgleich
DMC-FZ300
Das gilt so für das Bild ganz oben.

Die anderen Bilder entstanden mit derselben Kamera (Überwasser) oder mit der Olympus X-Z 1 (Unterwasser).

Fotografischer Anspruch: Dokumentarisch ?
Dokumentarischer Anspruch: Ja ?
Größe 373.6 kB 748 x 1000 Pixel.
Attachments:P1070675-750.JPG (272 KB),P1080129-750.JPG (206 KB),P1080236-750.JPG (409 KB),P1080496-750.JPG (146 KB),P1080506-750.JPG (136 KB),P1080809-750.JPG (209 KB),P1080923-750.JPG (162 KB),P1080981-750.JPG (159 KB),P1090189-750.JPG (130 KB),P1090242-750.JPG (192 KB),P1090785-750.JPG (301 KB),P1100279-400.JPG (141 KB),P1100604-750.JPG (259 KB),P1100725-750.JPG (313 KB),P5275095-750.JPG (190 KB),P5295254-750.JPG (183 KB),P6015295-750.JPG (210 KB),advent-21.jpg (18 KB),alt_thumb-164-220.jpg (26 KB)
Ansichten: 161 durch Benutzer472 durch Gäste
Schlagwörter:
Rubrik
Adventskalender:
Rubrik
Mensch und Natur: