Achtung: Dieses Blog ist umgezogen auf die Adresse blog.xwolf.de
Bitte ändern Sie Ihre Bookmarks entsprechend.

Samstag, 1. Mai 2004
Konzept zum Ersatz von E-Mail
Webworking
Das Medium E-Mail wird derzeit mehr oder minder zerstört durch das hemmunglose Marketing einiger weniger Dutzend Unternehmen.
Eine Besserung ist nicht in Sicht, im Gegenteil zeigt sich immer mehr, daß der Kampf zwischen Angrifftaktiken und Verteidigungsmöglichkeiten immer mehr verloren wird.

Zeit über neue Verfahren nachzudenken.
Der folgende Text soll meine Überlegungen darstellen, was man machen kann. Diese Überlegungen definieren ein Verfahren mit dessen Hilfe man Informationen, Texte und andere (wie eben bei Mails) anderen Personen zukommen lassen kann. Dabei jedoch auf eine Weise, die es Spammern unmöglicht macht, jemand zuzumüllen, wenn diese es nicht selbst will.

Vordefinitionen:
1. Person A will Person B einen Text zukommen lassen.
2. Person A und Person B kennen sich.
3. Beide haben die notwendigen softwaretechnischen Mittel. (siehe unten)
4. Beide Personen verfügen über eine eindeutige Identität im Netz dadurch, daß sie einen speziell Konfigurierten Bloggdienst nutzen.
Somit könnte A ueber a.example.org und B ueber b.example.org abrufbar sein.

Grobe Verfahrensbeschreibung:
Damit A einen Text an B senden kann, legt er diesem aufs einer eigenen Identitätsdomain ab. Genauer gesagt:
B erhaelt von A keinen Hinweis und keine Sendung, welche ihm sagt, wo eine Nachricht für B liegt.
Die Nachricht liegt dann auf beispielsweise auf a.example.org/msg/b/nummer/.
Die Nachricht wird als RSS abrufbar gemacht.
Dies bedeutet, daß mit dem ablegen der Nachricht ein Eintrag in einem RSS-Stream abgelegt wird, worin auf die eigentliche Nachricht verweisen wird.
Es handelt sich dabei um den allgemeinen RSS-Stream, den A in der Kategorie "Nachrichten" zur Verfuegung stellt.

Wenn nun B die Nachricht lesen soll, geschieht folgendes:
B muss die allgemeinen Nachrichten-Channel von A abonniert haben, dmait er mitbekommt, daß A eine Nachricht für ihn hat.
Wenn eine Nachricht für B im Stream erscheint, kann B diese abrufen -wie bei jedem anderen abonnierten RSS-Channel auch.

Wenn nun B auf A antworten will, geschieht dies auf selben Wege: B legt auf seinem Blogdienst b.example.org ebenfalls eine Nachricht ab und weist in seinem "Nachrichten"-Channel darauf hin. Wenn A den Channel aboniert hat, kann er dies sehen und die Nachricht abrufen.

Sicherheit und Identitaetseigenschaften:
Damit dies alles funktioniert müssen insbesondere bei der Identifikation von Personen neue Funktionen geschaffen werden.
1. Jede Person, die sich bei einem Blogdienst, also z.B. auf einem Host wie a.example.org umschaut, kann dies auf zweierlei weisen tun: a) als anonymer Webuser oder b) als identifizierter User.
Wenn man identifiziert ist, sieht man mehr. Nur dann sieht man auch die für sich bestimmten Hinweise im Nachrichtenchannel. Andernfalls sieht man diese garnicht.

2. Damit eine Identifizierung möglich ist, muss ein Verfahren geschaffen werden, wie sich Benutzer auf fremden "Blogdiensten" einloggen können.
Unter der Vorraussetzung, daß jeder einen solchen DIenst nutzt, kann dies folgendermassen gehen:
Jeder Blogdienst wird erweitert um dezentrale Funktionen zur Identifikation von Leuten.
Wenn eine Person X auf einen fremden Dienst "geht" oder auch nur den RDF-Channel abruft, dann erfolgt eine Identifizierung: Die Person X senden als Auth-Variablen mit: seinen eindeutigen Namen und ein Einmalpasswort.
Eindeutiger Name ergibt sich aus der Kombination aus dem Usernamen auf dem Dienst und Dienstnamen und dessen Lokalität. (dazu später mehr)
Das Einmalpasswort wird im Rahmen eines PIN/Tan-Verfahrens entweder als Liste an X gesendet damit er diese nutzt, oder aber bei jedem Login und vor jedem Aufruf einer fremden Seite wird zuvor dem Client von X das Passwort mitgeteilt, damit dieser es wieder an den fremden Dienst weitergeben kann.
Hier wären aber auch andere Verfahren denkbar.

Eindeutige Identifikation:
Es wird folgendes Identifikationsverfahren eingeführt (basieren auf den Überlegungen von Iain Banks: Anmerkungen zur Kultur im Buch Bedenke Phlebas, Seite 760f).
Namen dienen als Adresse. Es werden zuerst die notwendigen Anteile der Herkunft genannt, danach der Kurzname, dann der vollstände selbst gewählte offiizielle Name.

Also in meinen Fall wäre dies
De Blogger Xwolf Aravaeth o'Nan
In dem Fall dass ich weitere Identitäten hätte, würde ich eine "Familie" auf machen, so daß ich einen weiteren Namen anhängen könnte als Familienname.
Der Bloggerdienst könnte zudem einen Aliasnamen bekommen, der den Domainnamen ersetzt.

Wenn ich, bzw. mein Client sich nun bei irgendeinem fremden Dienst anmelden wollte, würde dieser nur meinen vollständigen Namen, bzw. den ersten Teil davon erfahren müssen, um die Möglichkeit zu bekommen an den Blogger.de-Dienst eine Rückfrage nach der Gültigkeit meines temp. Passworts zu senden.

Dieses Verfahren hat ein paar Vorteile, hat aber auch Nachteile.
Ein Vorteil ist, daß man Nachrichten nur von solchen leuten entgegennimmt (genauer gesagt bei denen abholt), die man kennt, bzw. von denen man eine Nachricht erwartet.
Eine unverlangte Zusendung von Nachrichten ist hiermit unmöglich.
Ein weiterer Vorteil besteht darin, daß das abholen einer Nachricht im Log des Dienst auf dem die Nachricht geschrieben wurde, protokolliert werden kann. Dies bedeutet, daß eine Bestätigung an den Autor gehen kann.

Ein Nachteil besteht darin, daß man erst in Kontakt mit anderen kommen muss, um diesen Nachrichten "senden" zu können.
Hier ist die Frage wie dies geschehen kann.
Im Vergleich zu meinen Blog kommen mir hier die Kommentar"channel" in den Sinn. Hier ist der Nachrichtenweg genau andersrum: Ein für mich zunächst Fremder kann auf meinen Blog einen Hinweis hinterlassen, den ich ggf. wieder später lesen kann. Wenn ich in dieser Nachricht dann ein Hinweis finde, wie ich mich mit dem anderen in Kontakt setzen kann, dann stehen alle Daten zur Verfügung, die man braucht.


Allerdings besteht auf diesem Weg wieder die Gefahr von Kommentarspam. ... Der wiederum dadurch effektiv reduziert werden kann, daß alle Poster wirklich über oben beschriebenen Identifikationsverfahren registriert sein müssen. Ein potentieller Spamer müsste sich ebenfalls identifizieren lassen. Und somit könnte man ihn verfolgen oder aber den eigenen Server anweisen, diese zukünftig abzuweisen (zu bannen).


Das beschriebene Verfahren ist derzeit noch in der Planungs-/ Konzeptionsphase. Ich lade jeden ein, sich hieran zu beteiligen und/oder eigene Ideen beizubringen.
Dies muss nicht nur auf diesem Blogg erfolgen, sondern kann auch beliebig woanders. (Bitte Link angeben).


Disclaimer: Dieses Verfahren und die darauf aufbauenden Ideen der Identifikation sind frei nutzbar, kopierbar und verwertbar unter den Bediengungen der GPL.
Durch diese Veröffentlichung in einem weltweit zugänglichen Medium ist eine legale Patentierung dieses Verfahren hiermit unmöglich gemacht und auch nicht erwünscht.


To prevent spam abuse referrers and backlinks are displayed using client-side JavaScript code. Thus, you should enable the option to execute JavaScript code in your browser. Otherwise you will only see this information.

Spamfutter

Die folgenden E-Mail-Adressen dienen lediglich dazu, SPAM-Bots dazu zu verleiten, ungueltige Adressen in die SPAMer-Datenbanken zu schreiben. Bitte ignorieren.

sgnqh@avvhgsnnvtdj.pl, ickjmp@fowojaycmtsrwb.mil, afl@kejxwxkmvofmcghgswjc.dk, vtxveel@lbtkwplzc.us, lpxto@ezvthmez.ca, xmaiqm@xtsuxmlkemnnbmn.st, eswd@cgfxsihpbqlkauqknkq.br, jjwqojxo@yqmhffmhstnjfqwvewdkn.eu, nfehk@wkgzsgwricmwlwgpmiui.tv, asr@prdblaebmieinlh.tv, vwrlz@pbgqnlistveejrwwjxktgu.st, zscbe@kplwcveewmsj.ar, vuyvzlr@ywrbluyqqumlwqoh.tv, wprovityqy@wkxzvbkpevjfoojiqalwzjb.fr, cpvcrqwwt@ryviugyjtlixnynnf.com, lfbqn@nngjbeqzgskwt.st, zoh@dpnkfhgcducvfs.biz, jyyw@hgzfylcyfu.biz, clqhsob@wifbfoege.com, xkkedfqsr@ismyprocnlzpxljyghrnl.mil, wqltwuebm@etuortxtbmsfkyxmbfpv.st, pzj@mrkdrcwelodmtggbuz.st, swbl@cqsbiqyccgkynhnhgwobx.br, udhit@gjbiqtabfaveoni.com, ncmsa@jihouiqjyiyjouq.com, rvvethketx@usugyuqalgimlkvfsrjfnh.at, hpsjfn@btcicxmgj.pl, qjaxtq@bbexstiuepnmfo.it, koxzysnc@qnzujwoxgdb.com, hnbatnp@foqgebssyq.ru