1 From: Boris Kraut <krt@nurfuerspam.de>
\r
3 Date: Sun, 10 Jun 2012 10:07:40 +0200
\r
5 Message-ID: <20120610080740.Psqpjz@silberbruch>
\r
8 To: undisclosed-recipients: ;
\r
9 Subject: Kontaktverwaltung
\r
11 Es gab eine Zeit, da habe ich Daten gesammelt -- eine "Leidenschaft"
\r
12 die man mir auch heute noch anmerkt. Jeder Kontakt wurde von mir
\r
13 fein saeuberlich in einer vCard abgespeichert, ein komplettes und
\r
14 wohlgepglegtes Archiv: Freunden, Bekannten, Kollegen, alle waren
\r
15 indiziert und ich konnte einen unglaubliche Ehrgeiz entwickeln, wenn
\r
16 es darum ging, diese Daten auf einem aktuellen Stand zu halten oder
\r
17 sie zu vervollstaendigen.
\r
19 Dann setzte das Denken ein. Es gab schon mehrmals die Zeit, in der
\r
20 ueber Menschen Buch gefuehrt wurde -- gerade wir in Deutschland
\r
21 sollten uns dessen doch bewusst sein. Datensaetze, Akten, wo ist
\r
22 der Unterschied? Ein Archiv ueber so etwas zu fuehren ist kein
\r
23 Gewinn, es ist ein Verlust an Menschlichkeit. Nicht nur weil das
\r
24 Vergessen menschlich ist, sondern weil Menschen mehr sind als
\r
25 Daten und Zahlen. Datenhaltung kann Menschen gefaehrlich werden,
\r
26 kann sie toeten. Ich moechte nicht, dass meine Daten bzw. die, die
\r
27 ich ueber andere habe, Menschen kompromittieren (koennen).
\r
29 Seither verfolge ich eine radikale "no log" Politik, treibe meine
\r
30 Mitmenschen damit in den Wahnsinn, dass ich eMail-Thread leosche,
\r
31 wenn ich der Meinung bin, dass sie zu genuege beantwortet sind --
\r
32 kommt dann doch eine verspaetete Nachfrage, muss ich eben nachfragen,
\r
33 mir den Kontext, das Backlog schicken lassen. Ich selbst habe es
\r
34 nicht mehr und das ist auch gut so. Was meine Kontakte angeht, so
\r
35 habe icht seither nur eine .aliases Datei, die die Mail-Adressen
\r
36 und Nickanmes einiger Menschen speichert -- und selbst diese Datei
\r
37 raeume ich regelmaessig auf. Dazu gesellt sich noch ein generisches
\r
38 Notizbuch, um mal eben schnell Kontaktdaten aufzuschrieben.
\r
40 Doch meine steten Bemuehungen, die sozialen Gefuege der Gesellschaft
\r
41 besser verstehen zu koennen, fuehrten leider dazu, dass ich immer
\r
42 mehr Informationen sammeln sollte, weil es eben zur Norm gehoerte.
\r
43 Es wurde von mir erwartet, Dinge zu wissen, die ich selbst als be-
\r
44 langlos eingestuft hatte und ein vergessener Geburtstag auf meiner
\r
45 Seite scheint ja schwerer zu wiegen, als die vergessene Einladung
\r
46 zu einer Geburtstagsfeier fuer diesen wirren Facebook-Veweigerer,
\r
49 Von daher plagen mich schon laenger Gedanken, ob und wie ich meine
\r
50 Kontaktverwaltung neu gestalten will. Natuerlich koennte ich wieder
\r
51 zuruek zu vCards gehen, deren Vorteil auf der Hand liegt: Es ist
\r
52 ein wohletablierter, offener Standard, der auch u.a. von Mobil-
\r
53 Telefonen genutzt wird. Die Informationen sind in Plaintext ge-
\r
54 speichert, so dass ich sie mit den ueblichen Unix-Tools leicht
\r
55 so nutzen koennte, wie es mir richtig zu sien scheint -- die vor-
\r
56 gefertigten Tools sind leider meist veraltet, grafisch oder schlicht
\r
57 verbuggt. Ausserdem ist der vCard-Standard eng mit dem vCalendar --
\r
58 heute besser als iCal bekannt -- und vJournal verwandt. Leider
\r
59 bin ich schlecht darin, mich dann nur auf das benoetigte zu be-
\r
60 schraenken; man koennte ja dieses "Blog" nicht als Mails, sondern
\r
61 als Journals in einem iCal pflegen und veroeffentlichen.
\r
63 Eine andere Idee war, dass man dafuer ja die im System vorhandenen
\r
64 Mittel nutzen koennte, sprich den Blanko-Eintrag in der /etc/passwd.
\r
65 Klingt zwar absurd, aber ich "leide" schon laenger darunter, dass
\r
66 Unix viele grundlegenden Funktionen fuer den Alltag schon parat hat
\r
67 -- so eben auch fuer die Benutzer- und/oder Kontaktverwaltung --
\r
68 aber diese nicht mehr genutzt werden. Im konkreten Fall ist das
\r
69 natuerlich verstaendlich, denn man dachte damals vornehmlich an
\r
70 innerbetriebliche Kontakte, sodass Informationen wie Geburtstage
\r
71 eher nicht vorgesehen waren. Genauso ist man erstmal auf die lokalen
\r
72 Nutzer beschraenkt und erst als Finger (o.ae.) auch netzwerkfaehig
\r
73 wurde, konnte man wirklich theoretisch auch Remote-Nutzer erreichen.
\r
75 Letztere Ueberlegungen fuehrten mich wieder weg von meinem Vorhaben,
\r
76 denn warum sollte ich mich damit beschaeftigen, Kontaktdaten zu
\r
77 speichern und zu pflegen? Warum nicht die Gegenseite? Es ist doch
\r
78 fuer jeden selbst am einfachsten, an einer bekannten Stelle seine
\r
79 eigenen Kontaktdaten fuer alle zugaenglich zu haben. Finger hat
\r
80 es vorgemacht und Jabber bringt es in die XML-Wunderwelt von heute:
\r
81 Die Nutzer haben eigene xCards, also XMLifizierte vCards, die sie
\r
82 selbst pflegen und aktualisieren sollen. Andere Nutzer koennen diese
\r
83 dann abrufen. Leider werden solche Moeglichkeiten heute von kaum
\r
84 jemand -- auch von mir nicht -- genutzt, zu tief sitzen wohl die
\r
85 schlechten Erfahrungen, die man mit einem aehnlichen Modell in den
\r
86 Anfangszeiten von ICQ und Co. gemacht hat.
\r
88 Einzig und allein die Avatar-Funktion, die Moeglichkeit kleine User-
\r
89 bildchen einzubetten, ist inzwischen weit verbreitet. Interessant
\r
90 ist, dass hier wie auch bei den Nutzerbildern, die manche Betriebs-
\r
91 systeme oder Webservices anbieten, meist nur Symbole genutzt werden,
\r
92 keine echten Bildern; einen Umstand, den erst die sog. "sozialen"
\r
93 Netzwerke und Smartphones langsam loesen. Sie machen es so leicht
\r
94 (oder erfordern es gar) echte Bilder zu nutzen -- wer wohl davon
\r
95 profitiert -- dass der innere Widerstand, sein echtes Anlitz publik
\r
96 zu machen, in kurzer Zeit merklich nachgelassen hat. Aber noch ist
\r
97 nicht alles verloren: Der Klarnamenzwang sorgte erst letzens bei
\r
98 Google+ wie auch Facevook fuer Aufregung und viele Nutzer sind sehr
\r
99 kreativ darin, ein Profilbild zu erstellen, dass sie selbst -- wie
\r
100 in den meisten AGB gefordert -- zeigt, aber doch nichts preisgibt.
\r
102 Zurueck zum Thema: Auf der GPN habe ich auch mit meillo darueber
\r
103 gesprochen und nachdem wir erst OpenPGP-Keyrings mit den Kontakten
\r
104 entsprechenden UIDs verwenden/missbrauchen wollten -- mit der
\r
105 datenschutzrechtlich bedenklichen Option ueber die Keyserver von
\r
106 ueberall Zugriff auf das "Adressbuch" zu haben -- sind wir dann
\r
107 wieder bei Mail gelandet. In ein paar Minuten hat meillo sein
\r
108 mmh so modifiziert, dass es die Kontaktinformationen aus mit
\r
109 Zusatzhaedern versehenen Mails rauspopelt. Ich finde das sehr
\r
110 gelungen, weil es fuer mich ein weiterer Schritt zur "unified
\r
111 communication". Unix-Philosophie? One Tool, one job -- das haengt
\r
112 ganz und gar davon ab, wie man die Aufgabe formuliert :) Trotzdem
\r
113 werde ich das vorerst nicht einsetzen, zu sehr ueberwiegen die
\r
114 Gedanken, dass Datensammlungen boese Folgen haben koennen.
\r
116 Und weil jetzt PGP angesprochen wurde. Auf dem "What to hack?"-
\r
117 Eroeffnungsvortrag der GPN wurde Werbung fuer Keysinging gemacht,
\r
118 dass so schoen mit "Speeddating fuer Nerds" umgschrieben wurde.
\r
119 Ich finde die Vorstellung amuesant und warte eigentlich nur darauf,
\r
120 bis es normal ist im Cafe zu sitzen und jemanden mit "Hey, ich
\r
121 wuerde gern deinen Key signieren. Erzaehl doch mal mehr von dir."
\r
122 anzusprechen. Vielleicht funktioniert das auch bei den Co's...
\r
124 ...aber eigentlich wollte ich auf das Web of Trust raus. Das ist
\r
125 in gewisser Weise auch ein "Social Network", auch wenn es hier
\r
126 nur zwei Werte gibt: signed und nicht. Ausserdem ist die Intention
\r
127 natuerlich eine andere. Waehrend bei PGP alle Informationen frei
\r
128 verfuegbar sind und man sie nur unterschiedlich gewichtet, ist
\r
129 das "Friends of Friends" Modell ein Gatekeeper: Informationen
\r
130 sind nur fuer bestimmte Vertrauensstufen sichtbar. Einschaetzungen,
\r
131 ob das Profil zu einer bestimmten Person gehoert oder wie richtig
\r
132 Informationen sind, sind nur indirekt abzulesen.
\r
134 Um die Nachteile die eine Nichtnutzung von FB usw. mit sich bringen
\r
135 etwas auszugleichen und meinem chronisch schlechten Gedaechtnis
\r
136 etwas auf die Spruenge zu helfen, hatte ich schon mal die Idee in
\r
137 den vCards auch noch die jeweiligen Freunde oder Kollegen einer
\r
138 Person zu speichern -- da vCards auch mit UUIDs versehen werden
\r
139 koennen ist das ja kein Problem. Die Implementierung war zwar
\r
140 nicht wirklich gut, aber prinzipiell hat es funktioniert. Auch
\r
141 wenn man natuerlich nicht im Voraus mitbekommt, welche Personen
\r
142 man uebe rwelche Ecken kennt, kann man doch im Nachhinein sehr
\r
143 interessante Erkenntnisse gewinnen: Sein eigenes soziales Netz
\r
144 mal zu analysieren und zu visualisieren ist wirklich Gold wert;
\r
145 ich weiss nicht, ob sich die ganzen FB-Nutzer sich das mal
\r
146 angeschaut haben...
\r
148 Da ich jetzt schon wieder abschweife, komme ich mal zum Punkt:
\r
150 1. Datensammlungen sind zu vermeiden.
\r
151 2. Kontaktinformationen sollten hauptsaechlich durch die
\r
152 Kontakte selbst aktualisiert werden.
\r
153 3. Man muss sich also nur eine UUID pro Kontakt merken,
\r
154 mit der man dann an diese Informationen kommen sollte.
\r
155 4. Finger und Jabber bieten das technische Ruestzeug, sind
\r
156 aber leider nicht verbreitet genug. [Und was Jabber
\r
157 betrifft waere ich fuer eine Umsetzung der Unix-Tools
\r
158 talk, finger, who usw. auf XMPP-Basis dankbar.]
\r
160 Ich werde jedenfalls vorerst nicht wieder mit der Sammlerei
\r
161 anfangen und wie bisher nur Name und Mail/Jabber-Adresse
\r
162 speichern. Telefon- und Handynummern wechseln zum einen zu
\r
163 schnell, zum anderen werden sie irrelevant, da inwzischen
\r
164 auch die Normalbevoelkerung immer haeufiger zu Online-
\r
165 Kommunikationsformen greift. Geburtstage sind noch ein
\r
166 offenes Thema, werden aber wohl wie "normale" Termine
\r
167 von meinem Mail-Setup bearbeitet werden.
\r
projects / krt-msg / blob