Hanno's blog

After some more »out of memory«-messages by josm, I thought it's time to look out for alternatives.

For the openstreetmap-project, the two main editors are josm (java) and potlach (flash). I think using java probably wasn't a very wise decision (I still wonder how an app can get »out of memory« after loading about 5 MB of images, do they create a pixel class and store every pixel in an object?) and I don't like flash either.

There's another project called merkaartor and today I had a look. My first feeling is that it's promising. It has good performance, it does nice live-rendering and it supports the basic features (adding nodes and ways, up/downloading stuff to the osm-system).

Sure, comparing to the large list of plugin features josm has, it's limited. Maybe I'll try to hack in some bits I'm missing at the moment.

In my continuing effort to improve gentoo for geo-related stuff, I've just added a merkaartor package to portage.

Heute früh hat das Bundesverfassungsgericht geurteilt, das ganze so, dass jeder sich ein bißchen als Sieger fühlen darf. Grob lautet das Urteil, dass Onlinedurchsuchungen zwar prinzipiell zulässig sind, aber nur unter extrem eingeschränkten Bedingungen und mit Richtervorbehalt. Letzterer wird leider allzu oft als Allheilmittel gegen Mißbrauch gesehen, was sich dummerweise mit der Realität äußerst selten deckt.

Das Problem, was ich bei Diskussionen über die sogenannte »Onlinedurchsuchung« erlebe, ist, dass meine Hauptbedenken erst da anfangen, wo das technische Verständnis der meisten anderen (insbesondere auch der entscheidenden Politiker) längst aufgehört hat. Ich gebe mich heute dem Versuch hin, selbige Bedenken auszuformulieren, ohne alle Nicht-Techies abzuhängen.

Zunächst mal muss man ungefähr begrifflich fassen, was »Onlinedurchsuchung« sein soll. Im Regelfall meint man damit, dass in ein fremdes Computersystem eingedrungen werden soll und dort Daten geholt oder manipuliert werden (Detailunterscheidungen in Datenbeschlagnahmung, Quellen-TKÜ o.ä. unterlasse ich jetzt mal). Nun ist der vielfach herzitierte Vergleich mit der Hausdurchsuchung ein problematischer, weil Computer üblicherweise keine virtuelle »Tür« haben. In der Realwelt wird eine Tür eben eingetreten oder das Schließsystem anderweitig umgangen (ja, es gibt elegantere Wege, die kenn ich auch). Sowas ist jetzt erstmal bei einem Computersystem nicht zwangsweise möglich, weil es nichts gibt, was man im Zweifel mit roher Gewalt (Türe) überwinden kann.

Um dennoch in ein System einzudringen, macht man sich üblicherweise Sicherheitslücken in Systemen zu Nutze. Und hier kommen wir meiner Ansicht nach zum Kern des Problems: Nämlich der Umgang mit dem Wissen über Sicherheitslücken. Im Hacker-Slang unterscheidet man manchmal zwischen Whitehats (»gute« Hacker) und Blackhats (»böse« Hacker). Whitehats sind solche, die ihr erlangtes Wissen über Sicherheitslücken lediglich dazu nutzen, diese zu beheben, indem sie etwa den Hersteller des Systems/der Software informieren und die Lücke anschließend publizieren. Blackhats sind solche, die die Kenntnis über Sicherheitslücken nutzen, um in fremde Systeme einzudringen.

Nun haben wir den etwas ungewohnten Fall, dass der Staat als Blackhat agieren will, sprich Sicherheitslücken NICHT publiziert, weil er sie für Onlinedurchsuchungen nutzen möchte. An diesem Punkt wird auch klar, dass das Thema eben nicht nur für die von einer Durchsuchung Betroffenen relevant ist, sondern für praktisch jeden. Woher der Staat diese Informationen bekommt, wäre eine eigene spannende Frage.

Nun ergeben sich daraus einige interessante Folgefragen. Ab und an kommt es ja vor, dass ein Computervirus mal eben das halbe Wirtschaftsleben lahmlegt (vor nicht allzu langer Zeit wurde ein Großteil der Rechner der Deutschen Post befallen). Bei zukünftigen derartigen Fällen wird man, nicht zu Unrecht, die Frage stellen, ob ein solcher Vorfall möglicherweise hätte verhindert werden können, hätte der Staat sein Wissen über Sicherheitsprobleme mit dem Rest der Menschheit geteilt. Was das für eventuelle Schadensersatzansprüche bedeutet, damit mag sich ein ambitionierter Jurist vielleicht einmal beschäftigen.

Ein weiterer, möglicherweise durchaus nicht unspannender Aspekt, der sich auftut: Der Staat begibt sich hier auf ein Gebiet, auf dem gewisse Regeln nicht unbedingt so gelten wie andernorts. Um oben genanntes Beispiel einer Hausdurchsuchung heranzuziehen, dürfte es in aller Regel so sein, dass ein Staat eine Hausdurchsuchung durchsetzen kann, egal in welcher Form sich die Hausinsassen wehren, aus dem simplen Grund, dass der Staat ein übermächtiges Repertoire an Gewaltmitteln zur Verfügung hat (zumindest gilt derartiges für westeuropäische Industrieländer).
Nun begibt sich der Staat in Außeinandersetzungen, wo dieser Vorteil plötzlich schwindet. Was der Staat hier tut, darauf hat er kein Monopol. »Onlinedurchsuchung«, das kann der Spammer, der Terrorist oder der Feierabendhacker möglicherweise genau so gut.

I recently took the new CAcert assurer test. Afterwards, one has to send a S/MIME-signed mail to get a PDF-certificate.

Having the same problem like Bernd, the answer came in an RC2-encrypted S/MIME-mail. I'm using kmail, kmail uses gpgsm for S/MIME and that doesn't support RC2.

While this opens some obvious questions (Why is anyone in the world still using RC2? Why is anyone using S/MIME at all?), I was able to circumvent that without the hassle of installing thunderbird (which was Bernd's solution).

openssl supports RC2 and can handle S/MIME. And this did the trick:

openssl smime -decrypt -in [full mail] -inkey sslclientcert.key

It needed the full mail, which took me a while, because I first tried to only decrypt the attachment.

I want to give some thoughts about some more advanced XSS-issues based on two vulnerability announcements I recently made.

First is backend XSS. I think this hasn't been adressed very much, most probably all CMS have this issue. If you have a CMS-System (a blog is also a CMS system in this case) with multiple users, there are various ways where users can XSS each other. The most obvious one is that it's common practice that a CMS gives you some way to publish raw html content.

Assuming you have a blog where multiple users are allowed to write articles. Alice writes an article, Eve doesn't like the content of that article. Eve can now write another article with some JavaScript adjusted to steal Alice's cookie. As soon as Alice is logged in and watches the frontpage with Eve's article, her cookie get's stolen, Eve can hijack her account and manipulate her articles.

Solution is not that simple. To prevent the XSS, you'd have to make sure that there's absolutely no way to put raw html code on the page. Serendipity for example has a plugin called trustxss which should do exactly that, though there are many ways to circumvent that (at least all I found should be fixed in 1.3-beta1, see advisory here: CVE-2008-0124). All fields like username, user-information etc. need to be escaped and it should be the default that users aren't allowed to post html. If a superuser enables html-posting for another user, he should be warned about the security implications.

A quite different way would be separating front- and backend on different domains. I don't know of any popular CMS currently doing that, but it would prevent a lot of vulnerabilities: The website content is, e.g., located on www.mydomain.com, while the backend is on edit.mydomain.com. It would add complexity to the application setup, especially on shared hosting environments.


Second issue is XSS/CSRF in the installer. I'm not really sure how I should classify these, as an open installer most probably has more security implications than just XSS. I recently discovered an XSS in the installer of moodle (CVE-2008-0123) which made me think about this.

I thought of a (real) scenario where I was sitting in a room with a group, discussing that we need a webpage, we would take Domain somedomain.de and install some webapp (in this case MediaWiki, but there I found no such issues) there. I suddenly started implementing that with my laptop. Other people in the room hearing the discussion could send me links to trigger some kind of XSS/CSRF there. This probably isn't a very likely scenario, but still, I'd suggest to prevent XSS/CSRF also in the installer of web applications.

Schon im vollen Gange, aber da das vielleicht nicht jeder mitbekommt: Ausgehend von der Aktion Mensch laufen gerade in vielen Kinos Filme im Rahmen der Aktion »Die Gesellschafter«.

Das Konzept: In Kinos werden Filme gezeigt, die gesellschaftliche Themen anreißen, zum Großteil solche, die es ohne die Aktion wohl garnicht in die deutschen Kinos geschafft hätten. Dabei beteiligen sich lokale Gruppen, die zu diesen Themen aktiv sind, mit Infoständen und Diskussionen (ich persönlich hab's vor allem über den AK Vorrat mitbekommen).

»A Scanner Darkly« (zum Thema Überwachung) und »Jesus Camp« (über christlichen Fundamentalismus) kenne ich schon, sind beide auf jeden Fall extrem emfehlenswert (und ich bin froh, dass wohl nur durch diese Aktion beide eine deutsche Übersetzung bekommen), aber auch das restliche Programm klingt nicht uninteressant. So werd ich hoffentlich die nächsten Tage möglichst viele der Veranstaltungen besuchen, in Karlsruhe ging's vor wenigen Tagen los.

http://diegesellschafter.de/

Ich behaupte ja nicht, dass meine Geographiekenntnisse besonders ausgeprägt sind, aber »Käsespätzle Allgäuer« mit dem Label »Aus unserer Region« im REWE in Murrhardt zu sehen, das kam mir doch seltsam vor.

(sorry für's verwackelte Bild, war nur die Handycam)

Hatte gestern mal wieder einen OpenStreetMap-Einführungstalk gehalten, diesmal beim Entropia, dem Karlsruher CCC-Ableger.

Vortragstechnisch habe ich diesmal die Folien deutlich reduziert (Download hier als OpenDocument) und den Fokus auf das konkrete Zeigen von Software und Interfaces gelegt.

Für Karlsruher OSM und Geo-Interessierte: Auf der Mailingliste KA-Geo werden lokale Treffen und Aktivitäten koordiniert.

I recently wrote about geo-tagged images. This makes use of the fact that different devices collect data and you can associate the data by the timestamp. It's most probably interesting for much more than gps/images.

While it's possible to get accurate timesetting by hand, it's usually not what you want. Preferably one wants to sync all devices with an internal clock automatically from the computer or some kind of network connection.

As a first step, we want to get our computer's time accurate. There are tons of tools out there, some linux distributions (and also windows xp) do this automatically on boot. I'm usually using rdate, it's small and simple:

rdate -s [any public timeserver]

There's a list of public time servers here. Other tools like netdate, ntpdate etc. will do it as well.

Now, my digital camera is a Canon Ixus 50. It uses PTP (picture transfer protocol) for data communication. If you have a PTP camera, most likely it supports time syncing. Syncing the camera time to the system time was recently added to libgphoto svn, but it's not yet available in a release. It also doesn't support any timezone management yet, so I'll get GMT time (while I live in the CET zone). The command to do it is:

gphoto2 --set-config synctime=on

If you don't have PTP, you're not completely lost. There's support for a lot of proprietary cameras in gphoto, some of them also support time syncing. Give it a try. I don't have information about usb storage devices (many cameras are just storage devices), links welcome.

Next device is my mobile phone, Nokia 6230i. As a mobile phone is permanently connected to the GSM-network, the obvious option would be time syncing over gsm. This protocol exists and most phones (including mine) support that. But bad luck, many mobile providers don't support it. So I'm out of luck here (vodafone, pointers to information about different provider support that are welcome).

Now, this device also speaks bluetooth, so timesetting via the computer should be possible. Both gammu and gnokii (the common applications to talk with all those proprietary mobiles out there) have a timesetting-option, but it rounds down the time to zero seconds, thus making it useless for exact time. I'm not yet sure if this is a limitation of the hardware or a bug in the software. An option would be to send the timesync-signal at the moment seconds turn to zero, but that would require application support, as there's a relevant diff between the application call and the moment the time get's set (because you have to ack the connection on the phone).
Though at the moment my phone needs manual timesetting, but the only data I'm collecting with it is gps-data, which get's it's timestamp via gps, so this is fine.

Over two years ago, it was announced that the security scanner nessus will no longer be free software starting with version 3.0. Soon after that, several forks were announced. For a long time, none of these fork-projekts produced any output.

openvas was one of that forks and from my knowledge the only one that ever produced any releases. It recently had 1.0-releases for all packages, I just added ebuilds to gentoo.

While openvas isn't perfect yet (many of the old plugins fail, because some files had to be removed due to unclear licensing), it's nice to see that we have a free, maintained security scanner again that will fill the gap left by nessus.

Recently geotagging of images became some popularity due to some articles on popular newspages. I'm already using geotagged images regularly for my work on openstreetmap.

Geotagging images means that you add some metadata in the EXIF-header (part of JPEG-files) where the image was taken. Future cameras probably will include a gps module and will be able to do this automatically, but with today's hardware we need some extra work. Beside manually adding the coordinates, e. g. by clicking on a map, we can synchronize gpx tracks (a common format for recorded gps data) with our images.

I'm usually recording gpx tracks on my mobile phone with Mobile Trail Explorer (a Java/J2ME-software) and an external bluetooth gps device. Before starting, you should accurately set the clock of both devices (the camera and whatever you use to get gpx data). For my hardware I have to do this manually. The mobile phone (Nokia 6230i) supports timesetting via gsm, but my german mobile phone provider doesn't transport that signal. It's also possible to set the time via bluetooth, but then it's rounded down to minutes (at least with gnokii and gammu, I'm not sure if this is an application bug or a hardware limitation), so this is useless, too.
My camera (Canon IXUS 50) seems to have no way of automatically setting the time.

Now, considering you were out somewhere, made some photos while you had another device recording gpx data. There's a small skript called gpsPhoto that will give your images GPS data:

gpsPhoto.pl --dir [directory of your images] --gpsdir [directory of your gpx files] --timeoffset 0

Now you have images that contain data where they were made. JOSM (an openstreetmap tool to create map data) supports showing the geotagged images, which makes editing openstreetmap much easier (you don't have to write down/remember street names, you can take photos of postboxes, bus stops etc. instead of writing down/setting waypoints with your device).

Beside that, this brings up the question if openstreetmap should get a database of geotagged free images together with tools to show them on the map. While this brings up some privacy issues (if the photos contain private buildings, people, car numbers), even the ones without any privacy implications (nature, public buildings) would be a nice feature: Having a map and always being able to say »show me some photos of that location«.
At the moment, this is probably far beyond of the computer ressources available for a project like osm, but it's worth a thought for the future.

Update: Bernd just told me that MTE doesn't use the phone's timestamp, but the one from the GPS device. This means this method doesn't work if your gps doesn't send a correct timestamp signal.