Tarnkappen-Links enttarnen

Heise hat „Breaking News“ parat: über Javascript-Events kann man Hyperlinks andere Adressen unterschieben. Das ist nicht neu, macht Google schon seit Jahren.

Dabei wird über das onclick- oder onmousedown-Event einfach das href-Attribut des a-Elements verändert. So ziemlich alle Browser führen den Eventhandler vor dem Öffnen des Links aus. So weit, so schlecht.

Nun kann man entweder Javascript deaktivieren (und viele Seiten kaputt machen) oder einen „faulen“ Trick anwenden, der zumindest bei onmousedown funktioniert:

Mit der rechten Maustaste darauf fahren und in die Statusleiste gucken, dann die rechte Maustaste drücken, das Menü schließen, wieder auf den Link fahren und gucken, ob sich der Text in der Statuszeile verändert hat. Funktioniert genauso, wenn man den Link per Drag & Drop anfängt zu ziehen, dies aber abbricht.

Wäre da noch das onclick-Event. Das kann man als Benutzer so einfach nicht ermitteln. Auch die Durchsicht des Quelltextes hilft nicht, da das Attribut samt Miniscript nicht direkt im Element stehen muss (siehe das Beispiel auf heise.de).

Da muss man Feuer mit Feuer bekämpfen. Ich habe dazu ein kleines Bookmarklet geschrieben, das alle Links im Dokument auf onclick- und onmousedown-Events durchsucht und im Falle dessen hinter dem Linktext ein kleines Ausrufezeichen einblendet.

Nach dem „Installieren“ kann es sogleich getestet werden, da meine Bookmarklet-Seite das Onclick-Event verwendet.

tarnkappen-links

So schaut’s aus

Allerdings sei dazu gesagt, dass Hyperlinks mit hinterlegten Events nicht per se nicht „böse“ sind, sondern auf manchen Seiten (wie hier im Wiki bei den Miniaturansichten von Bildern) eine Zusatzfunktion anbieten.

Happy Clicking!

Nein, ich mache nicht deinen Job!

Man bekommt ja durchaus Mails mit Hilfegesuchen, die ich auch gerne beantworte.

Gut, manchmal muss man dem Fragenden nötige Informationen noch herauslocken, aber meistens klappt das ganz gut.

Manche sind aber etwas dreist. Schreiben, dass sie etwas machen wollen und es nicht verstehen, sind aber gleichzeitig nicht gewillt, sich in das Thema einzulesen geschweige dem einzuarbeiten und lassen schon durchklingen, dass sie von mir eine Lösung wollen.

So gesehen relativ aktuell bei einer Mail zu Hardwareanbindung am Raspberry PI. Schon fast (Entschuldigung) dummdreist finde ich dann, wenn im Mailfooter „Dipl.-Ing. Elektrotechnik“ steht und nach kurzer Suche nach Namen das zugehörige Ingenieursbüro zu finden ist.

Zum Einen ein Armutszeugnis für den Ing, zum Anderen: Eh? Nein! Ich werde garantiert nicht deinen Job machen! Dazu fehlt mir momentan einfach die Zeit und ehrlich gesagt sehe ich es nicht ein, die Bequemlichkeit von anderen zu unterstützen.

Dazu kommt noch, dass ich das ein oder andere „Wunschprojekt“ schon Jahre liegen habe und es gerne mal anpacken würde…

…vielleicht im kommenden Jahr. In diesem Sinne: guten Rutsch und immer gute Ideen!

SVN + Dropbox

ist nur für Menschen, die auf Schmerzen stehen – kann ich jetzt nach eigenen Erfahrungen überhaupt nicht empfehlen.

Hintergrund ist der, dass ein Kommilitone und ich gerade dabei sind, Studienarbeit zu schreiben. Da ich keinen privaten Server mit SVN habe und es an der Hochschule SVN nur mit Einschränkungen (50MB für’s gesamte Repo und nur über SSH auf einen langsamen Server) geht, haben wir uns dafür entschieden, eine Dropbox als Repository zu verwenden. Theoretisch funktioniert das ganz gut, ABER:

Hat man einmal den Dropbox-Syncer nicht an oder macht ausgerechnet in dem Moment, in dem jemand anders etwas hochlädt, selbst einen Commit, knallt’s. Aber richtig. Dann heißt es Working Copy neu ziehen und/oder Scherben zusammenkehren.

Macht nicht viel Spaß, man verliert Informationen und es ist einfach zum brechen.

Nicht machen. Nicht mal dran denken.

Wenn du das lesen kannst…

…ist die Welt nicht untergegangen. Warum sollte sie auch?

Jeder, der sich einmal auch nur kurz mit dem Maya-Kalender beschäftigt hat, weiß, dass er „rund“ ist und dass sein Ende eigentlich auch sein Anfang ist.

Abgesehen davon – warum sollte die Welt wegen einer Zeitrechnung untergehen?
Eine ähnliche Idiotie gab es zur Jahrtausendwende – gut, damals gab es ein paar technische Dinge, die schief hätten gehen können, aber die von einigen befürchtete nicht-menschheitbedingte Apokalypse blieb selbstverständlich aus. Zumal „unser“ gregorianischer Kalender eh ein paar Jahre daneben liegt.

Wie dem auch sei, wenn schon kein Weltuntergang, dann wenigstens ein Foto von dem Ort, wo sich viele Esos und Fanatiker versammelt haben:

chichen itza

Chichén Itzá

 

20000 Pixel

Ich bin ja so ein idiot, der Software kauft. Da ärgert man sich dann ein wenig, wenn etwas nicht so funktioniert, wie man will. So gesehen bei Corel Paintshop Pro X5. Dort halten es die Entwickler nicht für notwendig, dass man Bilder auf Kantenlängen größer als 20000 Pixel skalieren (sprich Größe ändern) kann. Dagegen kann man deutlich größere Bilder öffnen und problemlos anderweitig bearbeiten.

Der Support von Corel (wenn er nicht gerade die Bearbeitung der Anfrage verweigert), sagt dazu folgendes:

Sehr geehrter Herr Christof Rueß,

Vielen Dank für Ihr Kontakt mit Corel Kundendienst.

Die Funktion zum Ändern der Bildgröße ist leider auf 20000 Pixel begrenzt.
Sie können das nicht ändern. So ist das Programm entwickelt.

Ich wette, mit einem Disassembler könnte ich das ändern. Außerdem habe ich nicht gefragt, ob ich das ändern könnte, sondern gemeldet, dass das ein Problem sei.

So werden also Bugs behandelt. „Ich sehe sie nicht, also sind sie nicht da“.

Danke Corel! (auch übrigens dafür, dass der HDR-Renderer beim Öffnen von Dateien reproduzierbar abstürzt)

AVR Dragon und Xmega A3

Eigentlich wollte ich die Tage damit anfangen, ein wenig mit ATxmega-Mikrocontrollern herumzuspielen und habe mir extra dafür einen AVR Dragon gekauft.

Bis ich heute Abend Platine A mit Platine B verbinden wollte. Nach Auswahl des Controllers und dem Versuch, eine Verbindung aufzubauen, kam folgende Meldung:

[ERROR] Got error setting up PDI mode: 
Device is not supported in this emulator mode. 
Debugger command setParameter failed., 
ModuleName: TCF (TCF command: Device:startSession failed.)

Aha, so ist das also. Dabei habe ich beim Kauf extra noch auf der Atmel-Website geschaut, ob meine Chips kompatibel mit dem Programmer sind, aber sind sie eben nicht. Zumindest nicht per PDI. Der JTAG-Port ist natürlich „verbaut“ und kann nicht wirklich benutzt werden. Ich würde wetten, dass der fehlende Support (wie so oft) eine Kastration in der Software ist. Zumindest finde ich es frech, dass von Atmel keine Angabe gemacht wird, dass ICs nur teilweise unterstützt werden. Hätte ich das gewusst, hätte ich mir gleich den JTAGICE3 gekauft. So bleibe ich wahrscheinlich auf meinem Dragon (da als Student gekauft und Rückgabefrist vorbei) sitzen.

WAT

Ich bin gerade dabei, das Wiki hier etwas zu erweitern.

Eine meiner Wunschfunktionen ist es, direkt auf Dateien verlinken zu können – standardmäßig wird ja immer auf die Datei-Seite der Wiki verlinkt, wo man zwar die letzten Revisionen sieht, aber ehrlich: wen interessiert das?

Wie dem auch sei, die Parser-Extension ist eigentlich relativ schnell geschrieben, trotzdem musste ich dabei an Gery Bernhardts Kurzvortrag „WAT“ denken.

PHP geht zwar schnell, ist aber oft nicht unbedingt schön. Nicht ohne Grund gibt es in den Heise-Foren bei nahezu jedem Artikel über PHP einen riesigen Flamewar über die Sprache. Zugegebenermaßen, an einigen Stellen ist die Sprache ziemlich großer Mist – als kleiner Beweis sei dieses hier angeführt:

if("1" == 1)
{
	echo "aww shit!";
}

Ratet mal, was da raus kommt… (kleiner Tipp, es fängt mit „aww“ an und hört mit „shit!“ auf). Um typenstarke Vergleiche anzustellen, muss man === (oder !==) verwenden. Das muss man wissen und so ziemlich jeder ist durch dieses Schlagloch schon durchgefahren.

Was mich aber bei Weitem mehr ankotzt ist folgendes: Fehlerbehandlung. PHP hat ja ganz klein ohne Objektorientierung angefangen und ist dann nach und nach gewachsen. Leider gab es damals noch keine try/catch-Blöcke und man musste alle Fehler über @-Modifier und anderweitige Fehlerüberprüfungen abfangen. Dieser Zopf wurde bis jetzt nie so richtig abgeschnitten und man muss auch heute noch mit @ abfangen.

Dieser Codeblock kann aufgrund zweier Dinge wunderschön gegen die Wand fahren:

try {
	$file = wfFindFile($input, array('time' => false, 'ignoreRedirect' => false));
	$filename = "";

	if($file !== null)
		$filename = $file->getURL();

	return "<a href=\">" . $input . "</a>";

} catch(Exception $ex) {
	echo "oops!";
	return false;
}

(zur Info: in $file wird bei Erfolg ein Objekt zugeordnet)
Eigentlich würde man ja denken, dass bei wfFindFile – da im Erfolgsfall ein Objekt zurückgegeben wird – entweder ein Objekt oder null zurückgegeben wird. Wird es nicht, aber das ist ein (meiner Meinung) Fehler der MediaWiki-Programmierer. Mein Fehler war, darauf zu vertrauen und typenstark mit null zu vergleichen. Hätte ich typenschwach ($file != null) verglichen, hätte das Ding funktioniert.

Nun kommt aber der richtig große Mist: in $file steckt, wenn’s dumm kommt, kein Objekt sondern false. Bei einem Boolean wird es natürlich etwas schwierig, die Methode getURL(); aufzurufen. Anstatt dass nun die Exception ausgelöst wird, tritt der alteingesessene Errorhandler auf den Plan und wirf den Anker von Bord.

WAT!?!

Aanon PowerShot A2100 IR

So, bin wieder aus China zurück, war sehr spannend – ich habe zwar auch einen Artikel für hier geschrieben, werde ihn aber erst die nächsten Tage erst veröffentlichen – falls mir noch etwas einfällt 😉

Wie dem auch sei, beim ersten Durchsehen meiner Bilder ist mir etwas merkwürdiges in den Exif-Informationen meiner Kamera aufgefallen:

Da hat der Kamerahersteller und der Modellname etwas gelitten. Zumindest wäre mir nicht bekannt, dass es eine kompakte Infrarotkamera gibt (war mal IS).

Das würde auch erklären, warum die Kamera seit geraumer Zeit keine mit ihr erstellten Videos mehr erkennt…

Da es mich interessiert hat, habe ich ein kleines Script geschrieben, das von alle mit der Kamera aufgenommenen Bilder die Exif-Informationen ausliest und diese bei Veränderung vom Manufacturer- oder Model-Feld einen kleinen Dump ausgibt. Zusätzlich sucht das Script das erste Vorkommen der Manufacturer/Model-Kombination:

[Make] => Canon
[Model] => Canon PowerShot A2100 IS
[DateTimeOriginal] => 2010:09:18 18:31:16
[ImageNumber] => 1001171
[OwnerName] => sion 1.00
[FirmwareVersion] => IS JPEG

[Make] => Canon
[Model] => CanoN PowerShot A2100 IS
[DateTimeOriginal] => 2011:04:24 11:40:54
[ImageNumber] => 1170699
[OwnerName] => sion 1.00
[FirmwareVersion] => IS JPEG

[Make] => Aanon
[Model] => CanoN PowerShot A2100 IR
[DateTimeOriginal] => 2012:04:16 17:41:22
[ImageNumber] => –
[OwnerName] => –
[FirmwareVersion] => –

Erstaunlich – da sind nacheinander die Bits in der Firmware weggekippt. Genauere Untersuchungen stehen noch au, aber da ist auf jeden Fall etwas nicht in Ordnung.Ich bin nur froh, dass meine Bilder von China inhaltlich unbeschadet sind, ansonsten wäre es mehr als ärgerlich gewesen.

Mit dem Canon-Support habe ich zwar schon telefoniert, aber von dort heißt es lediglich, dass die Kamera repariert werden muss. Frage ist nun: war der Fehler von Anfang an – und wenn ja: muss Canon die Reparaturkosten übernehmen? Das kann bezüglich der Beweislastumkehr durchaus spannend werden. Evtl. geht da aber was über Kulanz…

Aww… sh*t

Heute hatte ich endlich ein wenig Zeit, am Artikel des Energiemessgeräts von Pollin weiter zu schreiben. Als ich speichern wollte kam dann die Meldung, dass ich als Gast nicht bearbeiten darf. Heißt: Session abgelaufen. Idealerweise zeigte Mediawiki weder meine Bearbeitungen an (sodass ich sie noch kopieren hätte können), nicht könnte ich über den Zurück-Button des Browsers mein Geschriebenes wiederherstellen.

Tja, ärgerlich ist es und ich weiß für die Zukunft, dass ich manuelle Backups während dem Schreiben mach. Mal sehen, wann ich dazu komme weiter zu machen…

Flyer + Honeycomb = bloß nicht

Ja, ich weiß – das hier ist weder ein TechBlog noch sonstwas, was mit Tablets zu tun hat. Aber es ist mein Blog und da schreib ich, was ich will ;o)

Wie dem auch sei, gestern vermeldete mein Flyer, dass es nun Android Honeycomb installieren könnte. Obwohl och wusste, dass die Hardware-Buttons in den Bildschirm wandern und sonst noch geschwurbel auf dem Teil landen könnte, habe ich zugestimmt – in der Hoffnung, dass zumindest die Stylusunterstützung und der damit garnierte PDF-Reader besser wird…

Nach nun einem Tag hätte ich nun gerne Gingerbread zurück, das hat mir deutlich besser gefallen. Vor allem, dass es keinen richtigen Vollbildmodus mehr gibt und dass anscheinend die Farbtiefe bei dem eigentlich sehr gutem Display runtergedreht wurde, zeckt mich ziemlich an. Ich hoffe, man sieht das Dithering (links oben und unten an der Wolke) im Bild:

image

Weiter ist jetzt sehr viel Weiß (u.a. der Musikplayer) im Spiel. Wenn ich daran denke, dass ich das Tablet auch hinter die Frontscheibe hängen will: Pfui Teufel! Gerade in Hinblick auf OLED-Displays sollte man doch genau auf das Gegenteil aus sein?!?

Auch scheint das Ganze jetzt etwas stromhungriger zu sein, wobei ich das für den ersten Moment noch auf selektive Wahrnehmung schiebe…

Leider kann man das Update wohl nicht ohne Garantieverlust (Bootloader öffnen) rückgängig machen…

Immerhin kann ich vielleicht noch jemanden abhalten 😉