Whats App Messenger und der Datenschutz – eine klare „Nichtkaufempfehlung“

In den letzten Monaten wurde mir immer mal wieder die „Whatsapp Messenger“ App empfohlen. Diese soll dem Nutzer hohe SMS Gebühren ersparen und plattformübergreifendes Instant Messaging ermöglichen (soweit ich das gelesen habe inkl. Attachments wie Bildern, Videos etc.).

OK, Geld sparen klingt immer erstmal gut – da ich in Sachen App Kauf aber zur sehr sparsamen Fraktion gehöre, hatte ich die App bisher nicht auf Verdacht gekauft. Aktuell steht sie aber kostenlos im iTunes Store zur Verfügung, ich habe also mal den Download gestartet.

Öffnet man die App, so begrüßt einen gleich der folgende Screen:

OK, mein spontaner Reflex ist da natürlich der gleiche wie wenn z.B. Facebook einen Abgleich des Adressbuches vorschlägt: Nein, natürlich will ich das nicht – es wird also auf „verbieten“ geklickt.

Die App wird dann sofort eher trotzig und ermöglicht einem keine Nutzung des Dienstes:

Das gefällt mir in der Tat nicht – ich wollte die App eigentlich nur für die allmorgendliche Abstimmung mit einem Freund und Arbeitskollegen nutzen („und, wann fahren wir heute..?“). Somit möchte ich der App natürlich nicht mehr Zugriffsrechte auf meine Daten einräumen als genau diese eine Telefonnummer oder User-ID.

Ein kompletter Abgleich mit meinem Adressbuch ist weder notwendig noch zumutbar und in der EU nebenbei nichtmals gesetzlich zulässig. Letzteres scheint dem Anbieter auch klar zu sein – zumindest wird in den Bedingungen und in der ihren Namen kaum verdienenden Privacy Policy auch hierauf eingegangen. Hier wird versucht, die Verantwortung für eine Übertragung der Daten aus der EU in die USA unterzuschieben – ob dies zulässig oder möglich ist, vermag ich nicht sicher zu sagen.

Was hier passiert ist ja ohnehin etwas, wo es nicht um meine Daten, sondern diejenigen meiner Kontakte geht – also die privaten Daten Dritter. Diese haben keine Chance, der Datenfreigabe bzw. der Übertragung zu wiedersprechen, also sollte man selber mit diesen Daten besonders verantwortungsvoll (besser: paranoid!) umgehen.

An der Stelle darf ich meine Kontakte auch darum bitten.

Dann mal zur Frage was denn im normalen Betrieb hier wohl passiert – bzw. was passiert wäre, hätte ich dem Adressbuchabgleich zugestimmt:

  • durch den Abgleich mit meinem Adressbuch wären alle (ca. 800) Einträge meines iPhones an die Fa. Whatsapp übertragen worden
  • ob hierbei nur Rufnummern oder stets der komplette Datensatz inkl. Name, ggf. vorhandener Beschreibungen, Photos etc. auf deren Server geht ist unklar; in Ermangelung einer anderen Information gehe ich mal vom schlimmsten aus (kompletter Transfer)
  • die Kontaktdaten (mindestens die Rufnummern) bleiben dauerhaft (!!) auf den Systemen des Anbieters gespeichert (sonst könnte die App ja keinen sofortigen Abgleich für neue User machen)
  • ein Test der App und darauf folgendes Löschen verhindert also nicht, dass das Unternehmen zumindest die Möglichkeit hat, die Adressbuchdaten für immer gespeichert zu lassen

Warum man nicht einfach die seriöse Option verwendet (nämlich ein manuelles Eintragen der gewünschten Kontakte bzw. die manuelle Suche nach schon bei Whatsapp registrierten Usern) ist klar: Vertriebsziele bzw. eine möglichst große und aktive Userbase sind wichtigere Anliegen als der Datenschutz -nicht unüblich bei Internetstartups…

Ich denke es ist klar geworden, dass ich wohl kein Whatsapp User mehr werde.

Nachdem das recht schnell entschieden war, wollte ich mir aber zumindest noch die Frage nach Alternativen stellen. Ich selbst habe zwar einen Handytarif mit „nahezu Flatrate“ (die Anzahl der erlaubten SMS und Telefonminuten überschreite ich niemals), aber das gilt ja nicht unbedingt auch für alle meine Freunde.

Statt Whatsapp könnte man…

  • wie bisher SMS nutzen und sich um eine Flatrate kümmern
  • das sichere Jabber Protokoll verwenden, bei dem man sogar den Server selbst betreiben kann und somit nicht nur die gesamte Kommunikation, sondern auch die Speicherung der Kontaktdaten in der eigenen Hand behalten kann (das machen wir z.B. in der Firma)
  • Skype verwenden und damit zwar auch einige Daten bei einem amerikanischen Unternehmen speichern, aber dies nur sehr selektiv. Gleichzeitig kann man bei Skype ja wunderbar mit Pseudonymen arbeiten. Zentral ist aber das vorgenannte Wort „selektiv“: Man ist bei Skype nicht gezwungen, sein komplettes Adressbuch zu synchronisieren (also auf den Server des Anbieters zu kopieren!) Ich hätte mir nebenbei nicht vorstellen können, Skype mal als ein Positivbeispiel für Datenschutz anzuführen, aber es kommt wohl immer auf das Verhältnis an 😉

Wie absurd eine solche Adressbuchfreigabe ist, hat Stefan Dom in seinem Blog recht deutlich und gleichzeitig anschaulich formuliert. Man merkt ihm die Entrüstung an:

so… und nun stelle man sich vor, dass man auf der strasse angequatscht wird: “hey.. willst du umsonst mit deinen freunden telefonieren? dann gib mir mal dein notizbuch mit all adressen, die du in deinem leben gesammelt hast. ich verschwinde kurz damit um mir das zu kopieren. wenn da einer deiner freunde drin steht, dessen adressbuch ich mir auch schon kopiert habe, dann kannst du mit dem telefonieren, aber sonst mit niemandem”. bescheuert oder? niemand wuerde sowas machen.

 

Fazit:

Natürlich, Sicherheit ist unbequem und Datenschutz führt dazu, dass man auf manches Onlineangebot oder eben manche App besser verzichten sollte.

Nun gut, dann ist das eben so – gerade bei dieser App. Hier geht es schließlich nichtmals um meine persönlichen Daten, sondern um diejenigen meiner Familie, meiner Freunde und nicht zuletzt meiner Geschäftskontakte und -freunde (!).

DNS Cache unter Mac OS X leeren/löschen

Nur ein ganz kurzer Reminder, auch für mich selbst:

Den DNS Cache leert bzw. löscht man unter Mac OS X mittels…

dscacheutil -flushcache

Das war auch nicht neu – neu hingegen war mir, dass dieser Cache auf Userebene erzeugt wird und es somit nichts bringt, diesen Befehl auf der Shell als root auszuführen, wenn das Problem mit der DNS Auflösung beim normalen Useraccount besteht 😉

Belkin N Wireless USB Adapter am Mac (iMac)

Nachdem es mich einige Zeit gekostet hatte, einen simplen USB Stick an einem sehr alten PowerPC Macintosh zum Laufen zu bekommen will ich zumindest mal die wesentlichen Dinge hier festhalten. Ich verzichte aus zeitlichen Gründen auf Prosa und hoffe, dass das für den einen oder anderen hilfreich sein könnte:

Ausgangssituation

  • man will einen WLAN USB Stick der Firma Belkin in Betrieb nehmen
  • das Produkt hört auf den Namen „N Wireless USB Network Adapter“ bzw. laut Aufschrift auf dem USB Netzwerkadapter auf die Typenbezeichnung F5D8053
  • im System Profiler des Macs (Apfel-Menü –> „Über diesen Mac“ –> „Weitere Informationen“) meldete sich der Stick bei mir dann als RTL8191S, also als ein Realtek Chipsatz
  • letzteres hatte ich anfangs nicht gesehen, weil mich eine Google Suche stets mit der Typenbezeichnung F5D8053 stets auf Einträge führte, bei denen ein Chipsatz von Ralinktech vermutet wurde – was aber in meinem Fall offensichtlich nicht stimmte – anscheinend gibt es den F5D8053 mit unterschiedlichen Chipsätzen
  • Mac OS (zumindest das auf dem fraglichen Rechner vorhandene Mac OS X 10.4) unterstützt den WLAN Stick von Hause aus nicht

Lösungsweg

  • nicht darauf hoffen, dass Belkin die Treiber bereit stellen könnte 😉
  • den Treiber direkt vom Chiphersteller Realtek downloaden – dort nach „RTL8191S“ suchen
  • dann sollte in den Suchergebnissen u.a. diese Seite auftauchen, dort dann je nach installierter Mac OS X Version dann das MAC OSX 10.4 Install Package, MAC OSX 10.5 Install Package oder eben das MAC OSX 10.6 Install Package downloaden
  • Software entpacken & installieren
  • Rechner neu starten
  • USB Stick anstecken
  • in den Netzwerkeinstellungen noch den neuen Anschluss „Ethernet (1)“ o.ä. aktivieren
  • fertig 😉

iPhone 4 mit iOS 4.2.1 und Ubuntu 10.10 „Maverick Meerkat“

Nachdem sich der Asus eeePC mittlerweile als überraschend brauchbar gezeigt hat (CPU reicht in jedem Fall für ein bisschen Browser-, E-Mail- und Terminal-Nutzung und sogar für Filme, wenn diese nicht in Full HD vorliegen), waren Verbindungsversuche zum iPhone 4 (iOS 4.2.1) leider nicht sofort von Erfolg gekrönt.

Eine kleinere Google Recherche lässt annehmen, dass das mit iOS 4.2 noch anders war, aber das hilft nach dem Update des iPhones auch nicht weiter. Glücklicherweise arbeiten wir ja mit einem Linux-System und nicht mit Windows – wir haben also Fehlermeldungen 😉

Unable to mount iPhone_ org.freedesktop.DBus.Error.NoReply DBus error: MESSAGE DID NOT RECEIVE A REPLY (TIMEOUT MESSAGE BY BUS)

Plug & Play schaut anders aus – echt lästig, dass Apple seine Geräte mit jedem Softwareupdate an irgendeiner Stelle wieder etwas geschlossener Macht. Wenn MacBook, iPhone & Co. nicht so perfekt auf meine Bedürfnisse passen würden und so gut funktionieren würden müsste man in der Tat aufhören, Geld in Richtung Apple zu transportieren…

Wir haben es hier aber mit einem häufig auftretenden Problem zu tun, sodass die Lösung nicht allzu schwer zu finden war (und zwar hier und hier).

  • es braucht einige Paketupdates, die bisher noch keinen Einzug in die Ubuntu Repositories gefunden haben
  • diese sind unter dem Namen „PPA for Paul McEnery“ bei launchpad.net zu haben
  • zentral hierbei sind die Pakete bgpod und iFuse, es werden aber noch ein paar weitere Pakete mit aktualisiert – wichtiger Hinweis an der Stelle: Der Asus eee PC mit Ubuntu dient für mich nur für 4 Wochen als „Urlaubsbegleiter“ – ich bin daher nicht tiefer eingestiegen und habe nicht intensiv geprüft, wie sich die gepatchten Quellen aus o.g. APT-Repository unterscheiden. Wer es mit der Sicherheit ernst nimmt, will das bitte noch tun, bevor er die Pakete z.B. auf betrieblich oder privat dauerhaft eingesetzten Rechnern installiert!

Die Installation an sich ist ebenso einfach wie sie den Titel „Holzhackermethode“ verdient 😉

Erstmal die o.g. Paketquellen hinzufügen:

sudo add-apt-repository ppa:pmcenery/ppa

updaten & los:

sudo apt-get update

sudo apt-get dist-upgrade

Und voilà – das iPhone wird erkannt….

XSL / XSLT als Templatesystem

Bekanntlich setzt das papaya CMS bereits seit Version 1 (um 2000) auf XSL / XSLT als Templatesystem. Auch wenn der Standard schon viele Jahre besteht und z.B. im professionellen Umfeld (große Softwareprojekte, insbesondere im Java Bereich) eine große Wertschätzung und Verbreitung genießt, so ist die Wahrnehmung bei vielen PHP Entwicklern leider noch anders. Und das obwohl XSL / XSLT ein offener Standard ist, der die vielbeschworene Trennung von Logik, Inhalt und Layout sauber implementiert und der nicht zuletzt beliebige Ausgabeformate (HTML, XML, PDF u.v.m.) ermöglicht.

Umso erfreulicher ist es immer, wenn die mannigfaltigen Vorteile gegenüber proprietären Script- und Templatesprachen die Runde machen – wie aktuell in einem lesenswerten Beitrag von phpmonkeys.de.

Fazit der Autoren:

Der Vorteil von XSL ist, dass man dieses Verfahren mit jeder Programmiersprache einsetzen kann, die einen XSLTProzessor mitbringt. Und dabei können Template- und Layout-Dateien ohne Aufwand migriert werden. Man benötigt nur eine ähnliche Implementierung wie der HTMLGenerator und Logik, die die XML-Daten generiert.

…das völlig korrekt – neben weiteren Vorteilen:

  • offener Standard des W3C, keine proprietäre Lösung
  • in die Einarbeitung investierte Zeit ist nicht auf ein Produkt begrenzt, sondern kann in verschiedenen Projekten angewandt werden
  • hervorragend dokumentierter Standard, viel Literatur verfügbar
  • hohe Verbreitung in der Java-Welt
  • mächtiges Werkzeug/Programmiersprache
  • gut nutzbar für Internationalisierung der Ausgabe
  • und viele, viele mehr… 😉

Mantis BT (Mantis Bugtracker) – Notizen

Wir nutzen bei papaya sehr intensiv Mantis als Bugtracker für die Entwicklung des Open Source Content Management Systems „papaya CMS“, gleichermaßen auch in Kundenprojekten. Für ein Projekt kam die Frage auf, ob man nicht in Ergänzung zu unserer bestehenden Zeiterfassungslösung eine rudimentäre Time Tracking Lösung gleich an die Bugs anhängen könne.

Laut Mantis Featureliste soll dies gehen – leider ist aber genau diese Seite in der Mantis Dokumentation leer (!)  😉

Da es keinen Button zum Aktivieren des Mantis Time Tracking Modules gibt (und wegen missing documentation) hat es ein paar Minuten länger gedauert, ist dann aber ganz einfach:

  • Datei config_defaults_inc.php öffnen
  • die entsprechende Stelle in der Datei finden (Suchen nach * Time tracking *)
  • die relevanten Konfigurationsoptionen kopieren und in die Datei config_inc.php kopieren
  • ggf. hier noch Anpassungen nach eigenem Gusto vornehmen
  • fertig…

Irgendwie ein eher ungewöhnlicher Weg, um Leistungsmerkmale einer Software zu verstecken 😉
(Wenn man das aber einmal gesehen hat ist es aber ziemlich selbsterklärend.)

Interessant sind für meinen geplanten Anwendungsfall innerhalb der Scrum-basierten Zusammenarbeit mit einem Kunden vor allem die Funktionen zum Erfassen von Aufwandsschätzungen und zur Zeiterfassung. Diese werden mit folgenden Parametern angeschaltet:

Zeitprognosen

/**
* Enable or disable usage of the ETA field.
* @global int $g_enable_eta
*/
$g_enable_eta = ON;

Zeiterfassung

/*****************
* Time tracking *
*****************/

/**
* Turn on Time Tracking accounting
* @global int $g_time_tracking_enabled
*/
$g_time_tracking_enabled = ON;

/**
* A billing sums
* @global int $g_time_tracking_with_billing
*/
$g_time_tracking_with_billing = ON;

/**
* Stop watch to build time tracking field
* @global int $g_time_tracking_stopwatch
*/
$g_time_tracking_stopwatch = ON;

/**
* access level required to view time tracking information
* @global int $g_time_tracking_view_threshold
*/
$g_time_tracking_view_threshold = DEVELOPER;

/**
* access level required to add/edit time tracking information
* @global int $g_time_tracking_edit_threshold
*/
$g_time_tracking_edit_threshold = DEVELOPER;

/**
* access level required to run reports
* @global int $g_time_tracking_reporting_threshold
*/
$g_time_tracking_reporting_threshold = MANAGER;

/**
* allow time tracking to be recorded without a bugnote
* @global int $g_time_tracking_without_note
*/
$g_time_tracking_without_note = ON;

Asus Eee PC mit Ubuntu 10.10 (Maverick Meerkat)

Auch wenn mein Apple MacBook Pro (13.3 Zoll) ja schon recht handlich ist, so wäre als Reisebegleiter weniger Gewicht und weniger Größe durchaus nett – ich teste daher gerade einen Asus Eee PC (danke an die Kollegen von make.tv für die Leihgabe!).

An Windows mag ich mich aber nicht gewöhnen müssen. Als erstes wurde daher ein Image der bestehenden Platte gemacht und das installierte Windows XP durch ein Ubuntu 10.10 (Maverick Meerkat) ersetzt.

In Ermangelung eines internen CD-/DVD-Laufwerks wollte ich vom USB Stick booten, dies schlug aber fehl. Trotz verschiedener USB Sticks, trotz der Erstellung des bootfähigen Images unter Linux und Mac OS hat der Eee PC partout nicht vom USB Device booten wollen. Mit einem externen USB CD-Laufwerk hingegen klappte die Installation ohne Probleme – bis auf eine Kleinigkeit, die aber schnell zu beheben war:

Displayhelligkeit

Das Display gibt erst einmal ein enttäuschendes Bild ab: Es ist nach der Installation dunkler als beim vorher installierten Windows und läßt sich über die Einstelldialoge von Ubuntu ebenso wenig gut einstellen wie über die Funktionstasten: Die Helligkeit „springt“ zwischen den Stufen stark hin und her – und bei Einstellungen über 79% Bildschirmhelligkeit wird es wieder dunkler (!).

Die Lösung hierfür ist schnell und einfach, gefunden im Blog von Tom Schimana:

Datei „/etc/default/grub“ editieren:

vi /etc/default/grub

Dort zur Zeile GRUB_CMDLINE_LINUX_DEFAULT navigieren und hier folgende Änderung vornehmen bzw. die Zeile durch diesen Text ersetzen:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi=Linux"

Mit sudo update-grub2 die Änderungen speichern bzw. die Grub Konfiguration erzeugen, reboot und schon ist das Problem gelöst…

Zwischenfazit

Nachdem nun der Monitor hell strahlt, bin ich mit dem ersten Eindruck sehr zufrieden. Natürlich ist so ein Asus Eee PC kein Ersatz für mein Apple MacBook Pro, aber mit ca. 250.- Ladenpreis kostet das Netbook schließlich auch nur ca. ein Drittel…

Ich nutze den Rechner jetzt ein paar Tage zu Hause und entscheide, ob ich damit in unserer Ferienwohnung im Urlaub für ein paar Stunden arbeiten kann. In dem Falle bleibt der Apple zu Hause – das Asus Gerät ist leichter, kleiner und im Falle eines Diebstahls eher zu verschmerzen 😉


rsync zwischen MacOS (HFS+) und Linux (ext3) – und defekte Dateinamen

Bei umfangreicheren rsync-Läufen hier im lokalen Netz (ging um ca. 4 TB die von einem Ubuntu Server mit ext3 auf einen Mac mit HFS+ gehen sollten) stellten sich 2 Probleme heraus, die beim Sync zwischen Linux Maschinen nicht auftraten:

  • Ein großer Teil der Daten (und zwar alle mit Leerzeichen oder Umlauten im Dateinamen) wurde bei jedem rsync Aufruf neu übertragen, obwohl die Dateien sich nicht geändert hatten.
  • Umlaute waren z.T. defekt.

Eine längere Herleitung spare ich mir hier mal – statt dessen nur das Ergebnis der Recherchen, da das ggf. noch für jemanden nützlich sein könnte:

Das Problem entstand durch unterschiedliche Charsets auf beiden Maschinen:

Something else that can trip up rsync is a filesystem changeing the filename behind the scenes. This can happen when a filesystem changes an all-uppercase name into lowercase, or when it decomposes UTF-8 behind your back.

An example of the latter can occur with HFS+ on Mac OS X: if you copy a directory with a file that has a UTF-8 character sequence in it, say a 2-byte umlaut-u (303274), the file will get that character stored by the filesystem using 3 bytes (165314210), and rsync will not know that these differing filenames are the same file (it will, in fact, remove a prior copy of the file if –delete is enabled, and then recreate it).

You can avoid a charset problem by passing an appropriate –iconv option to rsync that tells it what character-set the source files are, and what character-set the destination files get stored in. For instance, the above Mac OS X problem would be dealt with by using –iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac OS X iconv in which all characters are decomposed).

(Die Erklärung stammt aus der rsync FAQ.)

Dem geneigten Mac-User fällt aber leider schnell auf, dass das mitgelieferte rsync den Parameter --iconv leider nicht versteht. Hier empfiehlt sich das Updaten z.B. über Macports – dazu hatte ich hier gerade schon ein paar Zeilen geschrieben.

Lange Rede, kurzer Sinn – nach dem rsync Update und der Angabe der Parameter schaut das bisher sehr gut aus. Folgender Kommandozeilenaufruf wird dabei verwendet:

rsync -a --modify-window=1 --stats --progress --exclude "*.frk"' --delete --iconv=UTF8-MAC,UTF8 root@SERVERNAME:/pfad/zum/Quell-Verzeichnis/ /pfad/zum/Ziel-Verzeichnis/

Kurznotiz: Darwinports, Fink und Macports

Nachdem Stefan in seinem Blog kurz und eindringlich von Darwinports abriet und Fink mich vor einiger Zeit schon nicht begeistert hatte, habe ich heute mal Macports eine Chance gegeben.

Kurzfazit:

  • Installation über einen Mac Installer (!), entsprechend problemlos und schnell
  • Installation von Paketen sehr einfach, automatische Auflösung von Abhängigkeiten klappt gut
  • binnen 15 min. gewechselt vom unerträglich schlechten RSYNC auf dem Mac zu einer aktuellen Version (rsync  version 3.0.7  protocol version 30)

Tipp der Redaktion, sozusagen 😉

Google Street View und der LDI NRW (Landesbeauftragter für Datenschutz und Informationsfreiheit)

Ich bin erstaunt – wenngleich die Datenschützer (m.E. zu Recht) Google Street View das Leben bisweilen schwer gemacht haben, hat der Landesbeauftragte für Datenschutz und Informationsfreiheit NRW anscheinend darauf verzichtet, das Bürogebäude verpixeln zu lassen: