Sie sind hier: Startseite / Blog

Blog

OpenStreetMaps hat Google Maps weit überholt

Steigen Sie um!

Neulich wollte ich einem Freund zeigen, wohin wir fahren müssen. Auf der linken Karte habe ich das Ziel mit einem roten Punkt markiert. Eigentlich ganz einfach: Ungefähr da, die Straße über die Bahnline und direkt daneben ist es. Nun kenne ich mich in der Gegend kaum aus, aber an der Bahnline kann man sich echt einfach orientieren.

Nicht so hier: Denn er hatte auf seinem Handy nur Google Maps (rechte Karte). Können sie erkennen wo das Ziel ist? Ich kaum.

Die linke Karte ist von OpenStreetMap, eine Art Wikipedia für Landkarten. Sie sehen: die Karte ist viel detailierter und vollständiger. Aktueller ist wie zudem auch. Ein paar Beispiele:

Wenn sie also noch immer Google Maps verwenden: steigen Sie um! Außerdem überwacht OpenStreeteMap Sie nicht.

Vergleich eines Kartenausschnitts in einer ländlichen Gegend: links von OpenStreetMap, rechts von Google Maps. Im linken ist ein Zielpunkt markiert, der direkt neben einer Bahnlinie ist. Die gleiche Stelle bei Goolge Maps zu finden, gelingt kaum, da man die Bahnline fast nicht erkennen kann und auch sonst viele Orientierungspunkte wie Gehöfte fehlen. 

18.11.2019 07:30

Finger weg von Kurz-URL-Diensten

Kurz-Links sind beliebt, aber ich rate aus mehreren Gründen davon ab

Just diese Woche gab es an mehreren Stellen in meiner Wolke Diskussionen über Kurz-URL-Dienste.

Kurz-URL-Dienste, wurden mit Twitter beliebt: Dort durften Nachrichten bis 2016 nur 140 Zeichen lang sein. Damit kann man fast keine Links in eine Nachricht packen, ohne an diese Grenze zu stoßen - oder nichts außer dem Link in der Nachricht zu haben.

Link-Verkürzer haben aber mehrere Nachteile:

  1. Man sieht nicht, wohin der Link wirklich zeigt. Zu Google? Zu  Facebook? Zu YouPorn? Auf eine Website, die Viren oder Tronjaner verteilt?
  2. Der Verkürzungs-Dienst ist eine weitere Stelle, die mitbekommt, wer sie wo im Internet bewegt. Wenn der Dienst z.B. Google, Facebook oder Twitter gehört, fügt das dem Überwachungsprofil diese Konzerne weitere Mosaiksteinchen hinzu. Ein gefundenes Fressen für Regierungen in totalitären Staaten.
  3. Der Verkürzungs-Dienst kann die Links manipulieren - aus Lust und Laune, weil er damit Geld verdient, oder weil es dazu gezwungen wird.
  4. Wenn der Verkürzungs-Dienst eingestellt wird, sind alle solche Links tot, auch wenn das Ziel noch existiert

 

Link-Verkürzer braucht man nicht mehr: Beispielsweise werden auf Mastodon (einem verteilten Kurznachrichtendienst im Fediverse) Links immer mit 23 Zeichen gezählt, egal wie lange sie sind. Daher ist es dort gar nicht üblich, Links abzukürzen.

14.09.2019 11:40

Frauenhofer promoted GNUnet - mit heißer Luft

re:claimID wäre ein brauchbarer Ansatz für dezentrales Identitätsmanagement. Leider gibt es bislang nur einen Prototypen.

Als ich die Meldung Re:claimID: Fraunhofer bietet Login-Dienst auf Open-Source-Basis an gesehen habe, habe ich im ersten Moment gedacht: Nach der Totgeburt Volksverschlüsselung kommt das Frauenhofer mit dem nächsten Vaporware-Produkt, das nichts taugt, aber einen coolen Namen hat.

Dazu kommt, das letztes Jahr mehrere Konzerne in Deutschland angekündigt haben, eine eigenen Plattform für das Identitätsmanagement zu bauen. Sie wollen damit Google, und Facebook entgegentreten - und vermutlich selbst die wertvollen Nutzerprofile erstellen.

Ist re:cailimID also auch nur ein weiterer zentraler Ansatz?

Aber siehe an: Hinter re:claimID steckt GNUnet (siehe auch Wikipedia), das ich schon länger beobachte. GNUnet soll später mal die Basis für Pretty Easy Privacy (pEp) bilden und damit dezentrale, anonyme und zensur-resistente Kommunikation ermöglichen. Auch das anonyme Bezahlsystem GNU Taler [4] setzte GNUnet ein. Es handelt sich also um durchaus solide Kryptotechnik.

Und tatsächlich gibt es im GNUnet-Blog zwei Beiträge, die genau das Prinzip von re:claimID beschreiben (die zugehörigen wissenschafltichen Veröffentlichungen sind jeweils in den Beiträgen unten verlinkt). Die zweite Veröffentlichung verwendet auch den Namen "reclaimID" und der Hauptautor wird im Heise-Artikel zitiert. Andere im Heise-Artikel-Genannte sind ebenfalls als Autoren aufgeführt.

Das schaut schon mal besser aus, als bei der Volksverschlüsselung, bei der die Grundidee schon unbrauchbar war (siehe meinen Blogbeitrag).

Bei re:claimID schaut es allerdings auch mager aus. Leider!

Ich hätte gerne gewusst, ob und wo ich es schon nutzen kann, was genau "Unterstützung des Standards OpenID Connect" bedeutet, oder was ich

Die Seite vom Frauenhofer zu re:claimID beschreibt nur die Idee, nicht das Konzept. Die beiden o.g. Paper beschreiben im akademischen Stil die Technik. Leider fehlt eine Beschreibung dazwischen: Technisch fundiert, aber leicht verständlich.

Das Frauenhofer verlinkt auch noch auf ein Gitlab-Projekt, dort findet sich aber -- quasi nichts. Es gibt den Quelltext, aber keine Dokumentation, wie man die Puzzlesteine zusammensetzen soll. Es gibt noch nicht einmal sogenannte Tags, mit denen bestimmte Versionsstände gekennzeichnet werden. Es gibt auch keine Software-Release, die sich ein.e End-User.in herunterladen könnte.

Bislang doch nur heiße Luft. Schade, sehr schade!

Bleibt zu hoffen, das Frauenhofer macht noch was daraus. Ich bleibe verhalten optimistisch.

23.01.2019 12:32

Steuerbehörden torpetieren Freie Software

Steuermeldungen sind nur noch mit proprietärer Software möglich

13 Jahre lang konnte man mit Geierlein bzw. Taxbird die Umsatzsteuervoranmeldung mit freier Software abgeben. Das ist nun nicht mehr möglich, weil die Steuerbehörden die Schnittstelle zugemacht haben. Daran sieht man, dass Regierungsaussagen wie "Wir fördern Freie Software" nur leere Versprechungen sind.

Um die Umsatzsteuervoranmeldung abzugeben, benötigt man nun eine proprietäre Software, die die Plausibilität der Daten prüft (Quelle). Nicht nur, dass Nutzer nun eine Software installieren müssen, deren Funktion sie nicht kontrollieren können und der sie blind vertrauen müssen. Viel schlimmer ist, dass die Steuerbehörden damit gegen fundamentale Sicherheitsgrundsätze verstoßen: Ein Server sollte nie, nicht, niemals Daten vertrauen, die eine Client schickt.

Die Plausibilitätsüberprüfung auf Client-Seite darf immer nur eine Zusatzfunktion sein, aber der Server darf sich nicht darauf verlassen. Ein Angreifer könnte die Schnittstelle (inoffiziell) nachprogrammieren und dann ungeprüfte Daten schicken. Daher muss ein Server alle Daten, die er bekommt, prüfen. Immer! Und ich hoffe, das tut er in diesem Fall auch.

Da der Server die Daten prüft, könnte man die Schnittstelle auch offen legen und damit möglich machen, dass Freie Software die Steuermeldung abgibt.

Wenn Ihnen das auch nicht gefällt, dann unterstützen Sie bitte die Aktion "Public Money? Public code" der Free Software Foundation Europe.

03.01.2019 19:44

Petition: Containern ist kein Verbrechen!

"Containern", also weggeworfenes aber noch brauchbares Essen aus den Müllcontainern der Supermärkte holen, gilt heute als Diebstahl. Dagegen ist die Verschwendung von Lebensmitteln straffrei. Diese ...

06.12.2018 12:48

Really Verifying LineageOS Build Authenticity

Re-establish the chain of trust after the way to verify public builds has changed

Really Verifying LineageOS Build Authenticity

LineageOS Logo (Quelle: Wikipedia)

The Lineage team has changed the way they sign the public builds. Unfortunately this change is not yet well communicated: The "Verifying Build Authenticity" wiki page as of today only describes the old method. Well, after some "startpaging" (how I call searching the internet) I found a patch and a pull-request describing the new method.

Formerly the Java-based "keytool" was used, which prints out some checksums the user has to compare her/himself. The new tool is Python-based and just says "verified successfully".

While this user-friendly, it leaves open how to verify the provided public key? How to build a chain of trust from the checksums published on the wiki to the public key included in the new tool's archive? Here is how-to.

The basic idea is to extract the public key from an installation archive we could verify using the old method and check if the public key in the new tool's archive matches the one used in the old installation archive.

In detail:

  1. Download and verify an installation archive using the old method, e.g. lineage-14.1-20180803-nightly-i9100-signed.zip
  2. Get the checksums from https://wiki.lineageos.org/verifying-builds.html respective commit 8dca5e117efc77be9bfcfeb39c6f69c1dce041ed (which as far as I can tell was the very first commit of this wiki-page and thus shall be our trust anchor). Define shell-variables to have them at hand:
    SHA1=9B:6D:F9:06:2A:1A:76:E6:E0:07:B1:1F:C2:EF:CB:EF:4B:32:F2:23
    SHA256=51:83:25:EF:7F:96:C0:D1:19:4C:2E:85:6B:04:0D:63:61:66:FF:B8:46:71:7D:72:FA:87:F4:FA:E5:BE:7B:BB

    You may want to pick the values from the aforementioned links so you don't need to trust me.

  3. Extract the X.509 certificate from the installation archive
    unzip -j lineage-14.1-20180803-nightly-i9100-signed.zip META-INF/com/android/otacert
  4. This will extract the certificate otacert into the current directory (unzip -j means: junk paths).
  5. Manually verify the fingerprints using different methods
    echo $SHA1 | tr -d ':' ; \
    openssl x509 -fingerprint -noout -in otacert | sed 's/.*=//' | tr -d ':' ; \
    openssl x509 -outform DER -in otacert | sha1sum --binary | tr '[:lower:]' '[:upper:]'

    echo $SHA256 | tr -d ':' ; \
    openssl x509 -outform DER -in otacert | sha256sum --binary | tr '[:lower:]' '[:upper:]'

    Line 1 will print the SHA1 check-sum picked from the wiki with colons removed. It's easer to remove the colons then inserting them in line 3. Line 2 will print the SHA1 check-sum using openssl x509 -fingerprint, again colons removed. This line is basically to verify our line 3 is correct. And line 3 calculates the SHA1 check-sum using the tool sha1sum.

    Lines 5 and 6 basically do the same, just using SHA256 check-sums. I did not find a way to make openssl x509 -fingerprint use SHA256 check-sums. This is why this step is missing here and why I'm using the external tools at all.

  6. Now we have verified the certificate within the installation archive is the correct one. Fine.
  7. Extract the public key from the certificate and convert into format used by the public key provided in the new tool's archive:
    openssl x509 -in otacert -noout -pubkey | openssl rsa -pubin -RSAPublicKey_out > otacert.pub
  8. Check if the two files are the same
    diff otacert.pub lineageos_pubkey && echo okay
  9. q.e.d.

For reference, here is the otacert.pub file:

-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEApk3T4fhCA4/wP2e46b8JUw/CkTy1PjZUx47CDbyLHnETYoylq8CG
BWDLRCwbUfmLbc5eWcSQN/J/ZPSK7wSQq5kQbwgHohMOGos6rNg05lbwhUtgJne2
bAB7FMLQwo0NxhNB3mSNh521mp554SiIcxo7scYftY9yWsBx3hK2EJPezFaFrCR0
zuLPIvDkS/IIQQ2RxdH2CqeUVUiCK611anDg/hfIPzXl+lm+TdK0RgSPm0IzIYb/
CqR+05whDen9mBxVcZ7I8wyqxEFcIWBfE/V9Ds3waCxITpRWdI3r6A4vLgsc9H+5
XZL/9Gc+FvY3gfOyx81LkEBBq+td+FBZmQIDAQAB
-----END RSA PUBLIC KEY-----
30.08.2018 18:56

Flüchtlinge von heute sind auch "Opfer von Flucht"

Wie verlogen: Der Bundesinnenminister hetzt gegen Flüchtlinge von heute. Gleichzeitig veranstaltet er einen "Gedenktag für die Opfer von Flucht und Vertreibung". Gemeint sind die nach den 2. ...

23.06.2018 09:58

Appell gegen Polizeigesetze und innere Aufrüstung

Die deutsche Innenpolitik legt mit einer unverhältnismäßigen Aufrüstung der Exekutive und mit Überwachungsgesetzen der demokratisch erstritten Freiheit, Sicherheit und den Bürgerrechten schwere ...

23.06.2018 09:21

E-mails weiterhin verschlüsseln!

S/MIME und PGP sind nicht gebrochen

E-mails weiterhin verschlüsseln!

EFail-Symbolbild (CC-0)

Mitte Mai veröffentlichte eine Gruppe deutscher Wissenschaftler eine Warnung vor neu entdeckten Problemen mit verschlüsselter E-Mail. Dies Veröffentlichung führte zu Aussagen, wie "E-mails nicht mehr verschlüsseln".

Ich bitte darum, die Falschmeldung nicht weiter zu verbreiten - auch wenn sie von der renommierten Electronic Frontier Foundation losgetreten wurde.

Die beiden zugrundeliegenden Verfahren S/MIME und PGP sind nicht gebrochen. Lediglich nutzen etliche Mailprogramme diese Techniken falsch, so dass Angreifer mit ziemlichen Aufwand an den Inhalt verschlüsselter Mails kommen können. Dazu ist aber ein aktiver Angriff nötig!

Der Rat ist noch immer: E-mails verschlüsseln. Dann ohne Verschlüsselung kann jeder den Inhalt der Mails lesen, im andren Fall nur der Angreifer - wenn er denn angreift.

Abhilfe ist zudem leicht:
a) keine externen Inhalte in Mails nachladen
b) neue Version des Mailprogramm verwenden

Mehr hierzu unter https://digitalcourage.de/2018/05/21/e-mail-verschluesselung-und-sicherheitsnihilismus

19.06.2018 18:10

„Kamera-Safari“ durch die Münchner Innenstadt

am 21. April 2018, 14 Uhr im JIZ, Sendlinger Str. 7 (Innenhof)

„Kamera-Safari“ durch die Münchner Innenstadt

"Mutig warf sich die kleine Kamera zwischen den Täter und das Opfer."

Es gibt immer weniger öffentliche Orte, an denen man sich bewegen kann, ohne dabei von öffentlichen und privaten Überwachungskameras aufgezeichnet zu werden. Viele Überwachungskameras sind rechtswidrig angebracht, doch das fällt selten auf, Strafen gibt es keine. So mehren die vielen Kameras in der Öffentlichkeit das Gefühl, permanent unter Beobachtung zu stehen. Dies ist eine Einschränkung unserer Freiheitsrechte - denn wer beobachtet wird, ist nicht frei.

Die Digitalcourage Ortsgruppe München veranstaltet am Samstag, den 21. April um 14 Uhr eine „Kamera-Safari“ durch Münchner Innenstadt. Um 14 Uhr startet der Spaziergang am JIZ. Ab ca. 16:00 Uhr wollen wir dort gemeinsam die ermittelten Videokameras kartieren und in OpenStreetMap einpflegen. Ziel ist es, das Ausmaß der Videoüberwachung und ggf. rechtswidrig angebrachte Kameras zu dokumentieren.

Bitte Digitalkamera oder Handy, mit denen man Fotos machen kann, mitbringen, damit wir die Kameras besser dokumentieren können.

Alle, denen außerhalb des Spazierganggebietes Kameras auffallen, können die Standorte und ein Dokumentations-Foto gerne mitbringen, um die Kameras zu kartieren.

05.04.2018 17:30