man bedim len?

Microsoft geht auf die Lehrstühle zu und bietet das Produkt SharePoint an, das an der FH Gelsenkirchen für den LS Wirtschaftsinformatik implementiert worden ist.

http://www.einfach-zusammen-arbeiten.de/fbportal

Ich hatte heute das zweifelhafte Vergnügen, dieses Demoportal zu analysieren.
...
Jetzt sind wir am überlegen, ob wir nicht zentral ein Warnhinweis an alle Einrichtungen herausgeben sollen.
Das was dort angeboten wird, mag zwar für Nichtexperten eine nette Lösung sein, jedoch zeigen sich teilweise gravierende Schwächen im System, die so stark sind, daß die Benutzung dieser Lösung zu nachhaltigen negativen Folgen für die Lehrstühle führen kann.

Weil ich heute danach gefragt worden bin, eine kleine Statistik auf die ich doch etwas Stolz sein kann.

Die Webauftritte, die mein Team und ich pflegen zeigten
im Mai folgenden Statistik:

381 gehostete Web-Domains
Je Domain = mind. 1 Webmaster

Zugriffe im Monat (05 / 04):

• 221.343 MByte
• 23.333.168 Hits
• 4.408.170 Webseiten
• 14.152.100 URLs (Webseiten plus Objekte oder Attribute)

Dies alles wird von nur 2 Servern bewältigt. (Eine SunFire 280f und eine E450).

Wo ich 1999 damit angefangen hatte, die Webauftritte zu organisieren und den Dienst zu etablieren, hatten wir gerade mal 8 Web-Domains.

Eine interessante Übersicht über Skript-orientierte Programmiersprachen findet sich unter:
http://merd.sourceforge.net/pixel/language-study/scripting-language/

Dabei wird bewertet, wie leicht sich mit welchen Sprachen programmieren läßt.

Ich hab gerade den CVS-Manager fürs RRZE weiter verschärft :)

Ab jetzt muss die erste Überschrift im Seitentitel enthalten sein und der Dateiname muss einer gueltigen Syntax entsprechen.
Hier wird erstmal nur eine dicke Warnmeldung ausgegeben. Später mach ich wohl ne Autokorrektur und/oder ein Fehler mit Abbruch.

Neue Dateien, die Sonderzeichen haben oder nicht sinnvoll sind, werden ablehnt. Beispielsweise kann man jetzt keine neue Datei mehr ins CVS einchecken, die den gleichen Namen hat wie das Oberzeichnis, bzw. wo der Verzeichnisname Teil des Dateinamens ist.
Macht schließlich keinen großen Sinn, eine Datei
"../blafasel/blafasel1.html" zu machen; Stattdessen soll man halt ../blafasel/1.html" nehmen.

Mal sehen, welche Lücken im System die Kollegen als nächstes finden >:)

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).

....finden sich morgen (err: heute!) im RRZE ein:
http://www.rrze.uni-erlangen.de/news/meldungen/meldung.shtml/189

Heiko Brenn (GROUP Technologies AG), Dirk Fox (Secorvo Security Consulting GmbH), Andreas Abecker (Forschungszentrum Informatik FZI), Andreas Marx (AV-Test GmbH) und Markus Ehrl (Microsoft).

Das wird sicher einige interessante Vorträge geben.

Mal sehen ob ich Zeit finde, mich mit dem Laptop reinzusetzen und mir einige Notizen zu machen.

ich kann endlich wieder Licht am Ende des Tunnels sehen: ich hab gestern Nacht den UnivIS-Datenexport über die PRG/XML-Ausgabe soweit über ein Perlmodul vernünftig umwandeln können.
Dazu hab ich ein solch allgemeines Modul erstellt, welchesnun in der Lage ist, alle Daten die ich aus UnivIS und dem XML::Parser bekomme, so weiterzuverarbeiten, daß man auch komplexere Aktionen mit den Daten machen kann.

Heute musste ich erstmal den HTDig'ger der Uni anpassen. Bei unseren neuen Design darf natülich auch nie Suchmaschine nicht zu kurz kommen.
Was aber nach einer simplen Template-Konfiguration klingt ist mehr:
Da im Design auch die gesamte Navigation und der Klickpfad enthalten bleiben muss, kann man nicht einfach auf eine andere Domain umspringen. Die Navigation, die dynamisch erstellt wird, könnte nicht richtig arbeiten und auch vom URL-Design würde es nicht mehr klappen.

Kurz gesagt: Der unvermittelte Sprung von einer Domain auf einer anderen (Subdomain), würde merkbare Auswirkung auf Navigation und URL haben. Hierdurch würde die einheitliche Struktur der Website durchbrochen werden und damit die Usability verletzt.

Zudem erwartet man bei der Ausgabe von Suchergebnissen von Seiten aus der Domain X, die dann auch noch im denselben Design erscheinen, daß man noch immer auf Domain X ist. Wenn man aber stattdessen aud Domain Y ist, dies nicht merkt und deswegen es genauso zu bedienen versucht, landet man auf Fehler.
Es sei denn, der Admin trifft vorsorge.

Veranschaulichendes Beispiel:
Stellen Sie sich vor, Sie binden als Suchmaschine einen Google-Aufruf in ihre Webseiten ein. Soweit so gut.
Wenn man die Suche betätigt hat (und neben der Sucheingabe hoffentlich auch das Google-Logo ist!) erhält man die Ergebnisse.
Wenn aber nun die Ergebnissausgabe nicht im Design von Google ist, denkt der Benutzer auch, dass er noch immer auf der Ursprungsdomain ist.
Obwohl er in Wirklichkeit dort eben nicht ist.
Dies ist aber nicht der Fall.

Also haben wir hier schon den Benutzer in die Irre geführt. Zwar wird dies nur dann folgen haben, wenn der Benutzer die URL bis zur Domain verkürzt und daran einen gewohnten Pfad der Ursprungsdomain anhaengt, jedoch ändert dies nichts an der simplen Tatsache, daß der Benutzer im Unklaren über seine Netzbewegung gelassen wurde.

Ein weiteres Problem ergibt sich dann, wenn der Benutzer an einem restriktierten Rechner sitzt, welcher nur auf das lokale Netz, nicht jedoch ins Internet zugreifen kann.
In diesem Fall würde das Ausführen der Suche, die ja optisch für den Benutzer als lokaler Aufruf gestart wurde, zu einem Fehler führen.


Was ist die Lösung?
Suchmaschinen, die nicht auf derselben Domain laufen, wie der Webauftritt, sollten über einen Wrapper aufgerufen werden.
Beim Wrapper handelt es sich um ein lokales CGI- oder PHP-Skript, welcher die Eingaben entgegennimmt und ein Request zur Suchmaschine ausführt.
Die Ergebnisse werden an den Wrapper zurückgegeben, der diese dann in das Design aufbereitet und dann ausgibt.


Im simpelsten Beispiel ist das bei Perl ein 5-Zeiler.

(Eingaben Parsen und per LWP an die Suchmaschine schicken und den Returnwert ausgeben.)