kritikant

laut nachgedacht

Zum Zubehör springen

Idee für anonymes elektronisches Bezahlen

Durch Fefe bin ich auf einen Artikel über das Überwachungspotential von Debit Cards gestoßen. Eines, das wir alle wegen der Bequemlichkeit schon längst akzeptiert haben. Die Kurzform:

Wenn ich mit meiner Karte bezahle, baut das Terminal eine Verbindung mit meiner Bank auf, die meinen Kontostand bzw. mein Kreditlimit checkt, und bucht den Rechnungsbetrag ab. Dabei entsteht eine Datenspur meines kaufenden Lebens, in der alle Orte, Zeiten, Beträge und Produkte (zumindest Händler) gespeichert werden.

Dabei hatte ich folgende Idee: Ein Teil der Lösung existiert schon: Die Geldkarte. Ich kann an Bankterminals beliebige Beträge auf den Chip meiner Karte laden und dann damit wie mit Bargeld bezahlen bis es verbraucht ist. Es ist aber gerade der Vorteil von EC- bzw. Kreditkarten, dass ich nicht ständig zu meiner Bank gehen muss und daran denken, immer genügend auf die Karte geladen zu haben. Das gleiche Problem hatten auch die frühen Prepaid-Handys: Der Dran-Denken-Overhead ist zu groß, als dass es Leute haben wollen.

Also, was ist, wenn man ein ähnliches System wie mittlerweile bei den Handy-Prepaid-Anbietern existiert auf Geld überträgt? Eine Skizze:

Ich vereinbare mit meiner Bank einen Aufladebetrag, z.B. 100 Euro. Dieser Betrag wird von meinem Konto abgebucht und auf den Chip meiner Karte geladen. Ich kann damit bezahlen, wie mit einer Geldkarte (allerdings bitte flächendeckend). Wenn ein ebenfalls vereinbarter Threshold unterschritten wird, z.B. 20% oder 30% des Aufladebetrags, bucht die Karte ohne mein Zutun den Aufladebetrag erneut von meinem Konto ab auf den Kartenchip. Idealerweise versieht man das ganze mit etwas Fuzzyness: Denn wenn immer genau dann aufgeladen wird, wenn ein Bezahlvorgang die Grenze überschritten hat, habe ich ja wieder eine enge Datenkorrelation mit meinem Verhalten. Also vielleicht ungefähr so: Es gibt zwei untere Grenzen: eine „weiche“ Grenze, die ich sagen wir bei 40% einstelle, und eine „harte“ bei vielleicht 20%. Nur wenn die harte Grenze unterschritten wird, läd sich die Karte sofort wieder auf (verhindert, dass ich ohne Geld im Laden stehe). Unterschreite ich aber nur die weiche Grenze, wird zufällig ein Zeitpunkt in den nächsten 3 oder 5 Stunden gewählt, zu dem die Karte sich wieder bei meinem Konto bedient. So werden Aufladung und Bezahlvorgang zeitlich und wahrscheinlich auch räumlich entkoppelt. Darüber hinaus könnte man noch implementieren, dass die Karte einmal alle 1 oder 2 Tage feststellt, ob überhaupt weniger als der Grundbetrag auf dem Chip ist und wenn ja, dann wird zwar nicht der gesamte Betrag aufgeladen, aber ein kleinerer, zufällig gewählter Betrag.

Auf diese Weise hätte ich die Möglichkeit ständig bargeldlos zu bezahlen, wenn auch nicht beliebig hohe Beträge (es sei denn ich lade die Karte mit sehr viel Geld auf). Und trotzdem wüsste weder meine Bank noch jemand, der möglicherweise auf die Bankdaten zugreift, was ich wo wann kaufe. Es gäbe nur sporadische, unregelmäßige Aufladezyklen, die lediglich einen Rückschluss darauf zulassen, wieviel Geld ich in einer bestimmten Zeitperiode ausgebe – nicht anders als ob ich Bargeld abhebe.

Der offensichtliche Nachteil ist, dass die Karte selbstständig mobil kommunizieren muss. Das heißt, sie ist ebenso ortbar wie mein Telefon, und sie ist über die Luft angreifbar.

Cron läuft zur falschen Zeit

Vor zwei Wochen habe ich auf meinem Vserver, der eh die meiste Zeit idlet, einen Tor-Relay aufgesetzt. Das solltet ihr übrigens auch machen.

Jedenfalls interessiert mich unheimlich, wieviel Daten denn da so durchgehen und wie sich der Datenstrom über die Zeit verhält. Ich habe in der Konfiguration als Bandbreitenlimit 128 KB/s eingestellt und bin einfach gespannt, ob und wie das ausgenutzt wird.

In den ersten Tagen habe ich mich morgens zu Fuß auf den Server connectet und im Tor-Log die Beacons angeguckt, die alle 6 Stunden über die geöffneten Circuits und die Gesamtdatenmenge berichten. War mir auf Dauer zu lästig, deshalb habe ich einen Cron-Job eingerichtet, der mir morgens um 8 eine Mail mit den aktuellen Daten schicken soll.

Das klappte zwar super, aber leider drei Stunden zu früh. Statt um 8:05 wurde die Email stur um 05:05 verschickt. Ich hatte folgende Zeile in meiner crontab:

5 8 * * * /Pfad/zum/Shellscript.sh

Die Systemzeit hatte ich vor der Installation von Tor bereits per NTP richtig gestellt und sie zeigte auch immer noch die korrekte Zeit und Zeitzone. Nach langem und wiederholtem Googlen fand ich den Tipp, nach dem Stellen der Systemzeit den Cron-Dienst zu restarten. Gesagt, getan. Und siehe da: Die nächste Mail kam um fünf nach acht.

Vererbung von viewport-percentage lengths in Chrome

Ich stolperte neulich über ein Problem mit viewport-relativen Längen in CSS. Die Situation war konkret folgende:

Ich hatte eine ungeordnete Liste, deren Elemente je ein <div> enthielten, in dem sich wiederum ein <a> befand:

<ul>
    <li>
        <div><a href="#">Test</a></div>
    </li>
</ul>

Zuerst ein Beispiel, wie es funktionieren sollte. Die <li>-Elemente sollen eine definierte Höhe haben und die <div>s sollten genauso hoch sein. Das CSS dazu:

* { margin:0; padding:0; }
ul { list-style-type:none; }

li {
    background:blue;
    height:10em; 
}
div {
    background:red;
    height:100%; /* Genau so hoch wie sein Container */
}

Hier ist ein JS-Fiddle dazu. Wie erwartet bedeckt das rote <div> das gesamte Listenelement. Ruhig auch mal in verschiedenen Browsern ansehen.

Jetzt geben wir dem <li>-Element aber eine vom Viewport abhängige Größe:

li {
    height:30vw; /* Die Höhe soll 30 Prozent der Breite des 
                    Viewports betragen */
}

Hier die geänderte Demo.

Im Firefox sieht es immer noch genau so aus wie vorher. Das würde man (ich) auch erwarten. Schließlich hat das Listenelement eine definierte Größe und ich sage, dass sein direktes Kindelement 100% dieser Größe haben soll. Sieht man sich das Ergebnis in Chrome an, zeigt sich aber ein anderes Bild.

Das <li> hat zwar die richtige Größe, aber das <div> ist nur so hoch, wie es sein Inhalt (eine Textzeile) erfordert. Sogar im IE9 wird es korrekt (wie im FF) dargestellt. Opera unterstützt derzeit keine viewport-related lengths, aber da auch dort demnächst ein Webkit rendert, wird es sich wohl auch nur mittelmäßig zum Guten ändern.

Anscheinend muss man derzeit also entweder für Chrome in solchen Fällen auch jedem Kindelement die v*-Größe zuweisen, oder mit anderen Längeneinheiten arbeiten. Schade.

jQuerys scrollTop() und border-box

Das Folgende betrifft soweit ich sehe nur jQuery < 1.8.

Letzte Woche habe ich den ersten Kandidaten für den irrsten Bug in diesem Jahr gefunden.

Der Fehler, den der Kunde berichtete, beruhte darauf, dass das ursprünglich verwendete $(document).scrollTop() nicht im IE8 funktionierte und nachdem er dies durch das funktionierende $('html').scrollTop() ersetzt hatte, lief es nicht mehr in Webkit-Browsern.

Die Lösung dafür war relativ schnell gefunden: Ich ersetzte einfach in dem betreffenden Script den einen scrollTop()-Aufruf durch den Ausdruck ($(document).scrollTop() || $('html').scrollTop()). Damit war der Drops gelutscht und jeder Browser konnte sich aussuchen, was ihm passte (bzw. was nicht gleich 0 war, da der Code nur beim Scrollen zur Anwendung kam, reichte das aus).

Aber was war die Ursache? Nach viel Ausprobieren blieb mir nichts übrig als in die jQuery-Source zu schauen und mir anzusehen, wie jQuery.scrollTop() definiert ist. Für das verwendete jQuery 1.6.4 sieht das so aus:

// Create scrollLeft and scrollTop methods
jQuery.each( ["Left", "Top"], function( i, name ) {
	var method = "scroll" + name;

	jQuery.fn[ method ] = function( val ) {
		var elem, win;

		if ( val === undefined ) {
			elem = this[ 0 ];

			if ( !elem ) {
				return null;
			}

			win = getWindow( elem );

			// Return the scroll offset
			return win ? ("pageXOffset" in win) ? win[ i ? "pageYOffset" : "pageXOffset" ] :
			jQuery.support.boxModel && win.document.documentElement[ method ] ||
			win.document.body[ method ] :
			elem[ method ];
		}

		// Set the scroll offset

		// Interessiert uns hier nicht
	};
});

Der Fall des IE8 sollte mit der Zeile abgedeckt werden, die mit jQuery.support.boxModel beginnt. Diese Eigenschaft dient eigentlich dazu, zu überprüfen, ob das W3C-Box-Modell vom Browser unterstützt wird. Das Problem ist, in diesem Fall gibt sie false zurück, obwohl das Dokument in Ordnung ist und der Browser sich im Standardmodus befindet. Warum? Also nachsehen, wie jQuery.support.boxModel gesetzt wird:

// Figure out if the W3C box model works as expected
div.style.width = div.style.paddingLeft = "1px";
support.boxModel = div.offsetWidth === 2;
Es wird ein Test-Div erzeugt, dem verschiedene Eigenschaften zugewiesen und das dann an den body angehängt wird. Da das Element hier einen Pixel breit ist und außerdem ein Padding von einem Pixel erhält, sollte offsetWidth, das die Gesamtbreite enthält, 2px zurückgeben.

Tut es aber nicht.

Der Grund dafür ist, dass ich im CSS box-sizing: border-box; gesetzt habe. Das ist eigentlich eine prima Sache, denn dadurch sind Elemente, denen man eine bestimmte Breite zuweist, auch wirklich so breit – egal ob sie Innenabstände oder Rahmen enthalten. Aber in diesem Fall passiert dann folgendes: Wir geben einem Element den linken Innenabstand 1px und sagen dann, dass das gesamte Element, mit Innenabständen und Rahmen, 1px breit sein soll. Das bedeutet, für den eigentlichen Inhalt ist kein Platz mehr, was egal ist, weil das Element sowieso keinen Inhalt hat und nur zum Testen da ist. Aber das bedeutet auch, dass offsetWidth nun auch 1 enthält, das ist schließlich die Gesamtbreite des Elements. Damit schlägt der Test div.offsetWidth === 2 natürlich fehl, und scrollTop() gibt nicht mehr window.document.documentElement.scrollTop zurück, sondern 0.

Darauf muss man erstmal kommen

Ab jQuery 1.8 besteht das Problem nicht mehr, weil dann nicht mehr auf Box-Model-Support getestet wird bzw. dieser Test nicht mehr in scrollTop() abgerufen wird.

Warum Webkit übrigens $('html').scrollTop() nicht versteht, ist mir noch nicht so ganz klar.

Zuckerbäcker

Selbstgebackener Christstollen

Weihnachten ist endgültig vorbei und ich habe auch mal Zeit, dieses Blog hier weiter zu befüllen. Heute geht es um Kulinarisches – passend zur Jahreszeit.

Ich habe einen Christstollen gebacken. Jawohl. Meine Oma, bei der ich seit ich denken kann mit Stollen – aus dem Erzgebirge, von der Verwandschaft geschickt, natürlich – zugeschüttet wurde, lebt jetzt seit einem Jahr nicht mehr. Seit Jahren reift in mir die Idee, selbst mal Stollen zu backen nach Erzgebirge-Art. Obwohl man dort ja traditionell nur die Zutaten kaufte und sie zum Bäcker brachte, der dann aus genau diesen Zutaten den oder die ganz persönlichen Stollen buk.

Dieses Jahr wie gesagt habe ich es geschafft. Vielleicht hat meine Oma daran auch ihren Anteil. Es ist ein bisschen das Festhalten dessen, was eigentlich vergangen ist. Fairerweise muss ich natürlich sagen, dass es meinem Opa noch gut geht, und dass ich bei ihm immer noch Stollen aus der Heimat bekomme. Dennoch ist es etwas Anderes.

Die Frage war jetzt, wie ich an ein Rezept komme. Theoretisch würde die Möglichkeit bestehen, in Sachsen anzurufen, was ich noch nie im Leben getan habe, und Tante Marianne (Tante meines Vaters, wenn ich nicht irre) zu fragen, was denn so hineinkommt in diesen Stollen. Und ob es Geheimnisse bei der Zubereitung gibt. Ich bin aber ein echter Sozialkrüppel, insbesondere wenn es um Leute geht, die ich kenne, aber praktisch nie Kontakt mit ihnen habe. Furchtbar. Nach den Erfahrungen, die ich letztlich mit diesem Stollen gemacht habe, überlege ich es mir vielleicht doch noch mal, ob ich sie nicht anrufe. Aber dazu später mehr.

Nein, eine andere Rezeptquelle musste her. Das Netz, natürlich. Die Suche war schwierig, weil nämlich die allermeisten Stollenrezepte, die es gibt, absolut nichts, aber auch gar nichts mit den Stollen zu tun haben, die ich seit klein auf kenne und liebe. Ein schnöde puderbezuckertes Etwas, am besten noch mit einer Marzipanrolle gefüllt, halb drüber geklapptem Teig, der als Gipfel auch noch Orangeat enthält. Wenn ich sowas essen will, geh ich zum Aldi und hol mir so ein Ding für zwei Euro fünfzig. Will ich aber nicht.

Der im weiteren Sinne Dresdner, genau genommen aber erzgebirgische, präzise: Neudorfer Stollen, den wir aus diesem Kaff dicht an der tschechischen Grenze unterhalb des Fichtelbergs bekamen, ist etwas ganz Anderes. Er ist groß. So groß, dass man einen gerade auf einem Backblech unterbringt. Im Prinzip geformt wie ein Brot mit einem Längsschnitt, der weit aufreißt und sozusagen eine köstliche Caldera bildet, die am Ende noch eine wichtige Rolle spielt. Der Teig enthält Mandeln, Rosinen – viele Rosinen – und Zitronat. Marzipan gibt es nicht. Ist er fertig gebacken muss er reifen, mehrere Wochen, während derer das Wichtigste in mühevoller Arbeit hinzugefügt wird: Butter und Zucker. Der Bäcker schmilzt Butter und streicht den Stollen großzügig(!) damit ein, so dass sie in alle Täler und Spalten läuft und dann streut er Zucker darüber, so viel, wie die Butter aufnehmen kann. Dann wird der Stollen verpackt und man wartet, bis das Gemisch erhärtet ist, um die nächste Schicht aufzubringen. So entsteht, Schicht um Schicht, ein manchmal zentimeterhohes Topping aus Butter und darin teils gelöstem, teils kristallinem Zucker, dass die erwähnte Caldera ausfüllt.

Beim Essen der dünn geschnittenen Scheiben (halbe Scheiben, der Stollen ist ja so breit) muss die Scheibe stets im Lot gehalten werden, während sich der Kopf demütig neigt, um abbeißen zu können. Andernfalls würde die Butter-Zucker-Mischung einfach vom Teig kippen und auf Teller oder Schoß in kleinste Bröckchen zerbersten (die natürlich sorgsamst wegschnabuliert werden bis nicht mal das kleinste Krümelchen zurückbleibt).

Es ist einfach ein Gedicht!

Leider hat sich in dem besagten Dorf in den letzten Jahren durchgesetzt, dass statt normalem Zucker Puderzucker genommen wird, was in einer Art Guss resultiert. Der ist dann auch nicht so hoch aufgetürmt, kann nicht umfallen und schmeckt einfach auch anders. Ich kann dieser Form lange nicht mehr so viel abgewinnen, wie dem Original, aber bisher hatte ich darauf keinen Einfluss. Bisher. Denn nun habe ich meinen eigenen Stollen backen wollen.

Zurück zum Rezept. Ich habe nach einiger Suche tatsächlich ein Rezept gefunden, das so klang, sowohl von den Zutaten her, als auch von der Meinung über das, was hierzulande so als Stollen verkauft wird, dass ich dachte, es ist einen Versuch wert. Dieses hier, Oma Lenis Stollen aus dem CommonsBlog.

Ich habe es in zwei Punkten geändert und der Autor, Jakob, würde vielleicht ebenso wie Leni selbst sagen, dass meine Variante nicht zählt. Der erste Punkt ist, der nicht weiter schlimm ist, ich habe das Rezept gedrittelt, weil ich ja nicht wusste, ob das wirklich mein Stollen wird und nachher hab ich da drei Dinger, die keiner essen will. Die zweite Änderung ist gravierender. Ich habe den Stollen vegan gebacken. Das bedeutet: statt Butter habe ich Bio Alsan genommen und statt Milch Sojamilch.

Meine Zutaten waren also:

  • 830g Mehl
  • 160-170g Zucker
  • 100g gemahlene Mandeln
  • 40g gemahlene bittere Mandeln
  • 80g Zitronat
  • 420g Rosinen (hier war ich feige, es kam mir so viel vor und die Rosinen ließen sich so schlecht dazu überreden, im Teig zu bleiben, daher war es weniger, wieviel weniger weiß ich nicht)
  • Schale von einer Drittel Zitrone (etwa)
  • Ein Drittel Teelöffel Muskatblüte
  • 330g Bio Alsan
  • 1/4 Liter Sojamilch
  • 2 Würfel Hefe
  • 1 Esslöffel Rum

Für die genaue Zubereitung lest bitte im CommonsBlog weiter.

Stollen vor dem Backen

Nach dem Backen war ich erstmal begeistert. Er riss richtig auf und ging sehr auseinander, so ähnnlich wie ich es kannte. Leider an beiden Enden bis zum Blech, wodurch die Enden nicht so schön waren. Da hätte ich vielleicht doch länger gehen lassen sollen vorher.

Die erste Schicht zerlassene Alsan mit Zucker wurde direkt aufgebracht. Danach habe ich den Stollen wie angegeben in Alufolie gepackt und in den kühlen Flur gestellt. (Das ist außerhalb der Wohnung, da ist es wirklich kühl.) Die nächste zwei Wochen habe ich manchmal täglich, manchmal alle paar Tage wieder eine neue Schicht Alsan mit Zucker darauf gepinselt und der Stollen reifte und gedieh. An Heiligabend, als die zwei Wochen rum waren, die von Kennern als Minimum angesehen werden, habe ich ihn angeschnitten. Das Ergebnis hat mich wirklich positiv überrascht.

Zugegeben, er hat seine Fehler. Was mir als erstes beim Probieren aufiel: Er ist zu trocken. Ich bin nicht ganz sicher woran es liegt. Mögliche Ursachen wären falsche Lagerung (statt Alufolie besser Plasiktüte?), nicht gewaschene/gewässerte Rosinen (dachte, das wär unnötig), zu wenige Rosinen oder einfach zu wenig Flüssigkeit oder Fett. Da werde ich ausprobieren müssen.

Die Butter-Zucker-Mischung ist zwar lecker, aber natürlich schmeckt es nicht ganz so wie mit echter Butter und sie wird auch nicht ganz so fest, was beides zu erwarten war. Damit muss ich leben.

Bei der Gegenprobe mit dem Originalstollen von diesem Jahr von der Verwandschaft ist mir aufgefallen, dass da möglicherweise noch ein paar gehackte Mandeln drin waren. Bin noch nicht ganz sicher, ob Zitronat oder Mandelstücke. Kann ich auch überlegen, ob ich da im nächsten Jahr noch variiere.

Ansonsten bin ich aber echt angetan von meinem ersten Stollenversuch. Ich bin Oma Leni und dem CommonsBlog sehr dankbar für das Rezept und im nächsten Jahr wird früher gebacken, länger gelagert und noch ein bisschen ausprobiert. Und ganz vielleicht springe ich über meinen Schatten und frage mal die eigene Verwandschaft nach ihren Zutaten und Mengen.

Angeschnittener Stollen