Das heißt: Es musste wieder mal eine Sprache her, aber dieses mal besser eine Offline-Sprache. Und da ist sie: Sie hört auf den einfachen Namen “Go”, was für Spaß und Produktivität steht. Dabei wirbt Google selbst mit der Sicherheit einer C/C++-Kompilierten, der Dynamik und Offenheit von Python und der Kompatibilität, es auf jeden Webserver einsetzen zu können. Große Versprechungen vom großen Riesen also.

Dabei ist das Konzept ganz einfach: Man nimmt sich C, verbindet es mit C++, haut den Garbage Collector dazu und etwas von Python und fertig ist Go. Daneben kann man Import-Funktionen von C nutzen, hat aber auch gewisse Freiheiten, wie die Datentypen int, float oder struct. Der Umstieg von C++ sollte also Go-Programmierern kein großes Problem darstellen.

Und auch völlige Neuanfänger können sich einlesen, indem sie das mitgelieferte Tutorial durchgehen und die Häufigen Fragen (beides noch in Englisch) lesen. Dazu haben die Entwickler der Programmiersprache außerdem noch ein hübsches Video produziert:

[YouTube Direkt-Go]

Was meint ihr dazu? Ist Go für euch vielversprechend oder sagt es euch nicht zu? Kann es Konkurrenz machen?

Konkret geht es darum, dass mehr als eine Millionen Datensätze (Name, Alter, Wohnort, Interessen, Geschlecht, Profilbild usw.) gephist wurden. Durch Löcher im SchülerVZ-CMS. Dass SchülerVZ nicht aus vergangenen Pannen, wie bei StudiVZ oder MeinVZ, gelernt hat, ist wirklich bedauerlich.

Zurück zum Artikel von netzpolitik.org. Markus hat in der Verbraucherzentrale um Rat gefragt und ein Interview erhalten:

Die Betreiber sozialer Netzwerke sind in der Pflicht, Daten ihrer Mitglieder gegen unbefugten Zugriff zu schützen. Das aktuelle Beispiel zeigt, dass Benutzer sich nicht in Sicherheit wiegen lassen sollten: Netzwerke sind ein Teil des Internets und nicht von ihm getrennt. [...]

Kurz nach der Veröffentlichung auf netzpolitik.org hatte sich SchülerVZ selbst zu Wort gemeldet und lässt verlauten, dass man “die Datenschutzbehörden umgehend informiert und [...] rechtliche Schritte gegen Unbekannt einleiten” wird.

Übrigens stammen die Löcher von so genannten “Cross Site Request Forgery”, kurz XSRF, eine Unterart der XSS, der Cross Site Scripting-Attacken, wie sie auch mal bei Redio vorkamen. Mit diesen Lücken, so Insiderinformationen, ließen sich auch Accounts übernehmen und andere tolle Dinge tun, wie Accounts löschen oder Inhalte hochladen. Desweiteren soll eine kleine Lücke darin bestehen, dass Bilder nicht vom Server gelöscht werden, sondern nur der Link zum Bild. SchülerVZ streitet dies aber ab.

Mittlerweile soll sich die unbekannten Eindringlinge schon bei SchülerVZ gemeldet haben, um die Lücke zu beheben. Von eine Anzeige möchte SchülerVZ bei voller Kooperation absehen.

Der Webserver führt ausschließlich ein Logbuch für Fehler, es werden also nicht alle Zugriffe protokolliert, sondern nur solche, die einen Status ungleich 200 zurücklieferten. Eine typische Zeile sieht so aus und enthält die Zeit, IP-Adresse, Datei, Referer und, je nach Fehlertyp, noch andere Informationen:
[Fri Oct 16 22:29:38 2009] [error] [client *] File does not exist: /home/www-data/htdocs/e/example/www/example.php, referer: http://www.example.com
Speicherdauer: 14 Tage.

Auch jeder Versand von Mails wird protokolliert. Gespeichert werden hier Skriptpfad plus Zeile des mail()-Aufrufs und alle E-Mail-Header:
mail() on [/home/www-data/htdocs/e/example/www/emailer.php:212]: To: ...
Speicherdauer: 14 Tage.

Der FTP-Server (das betrifft die wenigsten) speichert alle Verbindungsversuche und alle Aktionen mit Zeit, IP-Adresse und Benutzername:
Thu Oct 15 17:20:21 2009 [pid *] CONNECT: Client "*"
Thu Oct 15 17:20:23 2009 [pid *] [anonymous] FAIL LOGIN: Client "*"
Speicherdauer: 30 Tage.

Das HVS protokolliert diverse “wichtige” Aktionen wie zum Beispiel “Account erstellt”, “Account gelöscht”, “Neues Passwort angefordert”, diverse von Administratoren ausführbare Aktionen, sowie Meldungen von Verwaltungsskripten. Was genau gespeichert wird hängt recht stark vom Meldungstyp ab (Benutzername/-ID, E-Mail-Adresse, Datum des letzten Login, “Onetime-ID”, …), Zeit und Benutzername (falls angemeldet) werden aber immer gespeichert, nicht jedoch die IP-Adresse.
Speicherdauer: Zurzeit unbegrenzt. Es ist aber geplant die Daten nach etwas mehr als einem Monat zu löschen.

Außerdem wird nachts ein Backup der Redio-Datenbank (nicht der Benutzerdatenbanken!) erstellt. Darin befinden sich natürlich alle Daten, die das HVS erhebt (Nutzerdaten wie E-Mail-Adresse und Accountname, aber auch Domains und Datenbanknamen/-passwörter).
Speicherdauer: 14 Tage.

Wenn mehrere Seitenbetreiber das selbe Verzeichnis benutzen, in dem sie Sessions speichern wird es problematisch. Zumindest wenn jeder auch noch Leserechte in dem Verzeichnis hat oder zumindest die Dateien auflisten darf.

Denn die heißen meistens sess_$sid  und wenn man $sid hat, hat man die Session, kann sie auslesen, verändern usw …

Es gibt im Moment 1980+2347 = 4327 Benutzer (jeweils lexu + azure). 522+430 = 952 (22,0%) davon haben 0(!) Bytes auf ihrem Webspace (der Webspace ist also leer). 567+499 = 1066 (24,6%) sind mit < 1KB dabei, 568+890 = 1458 (33,6%) haben weniger als 1 MB, 1382+1572 = 2954 (68,2%) weniger als 10 MB und 1947+2300 = 4247 (98,1%) weniger als 100 MB auf ihrem Webspace gepeichert. Datenbanken sind hier aber nicht eingerechnet.

Das heißt im Klartext: Jeder vierte im Moment existierende Account ist “unbenutzt”, wenn man unbenutzt als “weniger als 1 KB belegt” definiert.

400(!) Nutzer weniger. Das ist an sich kein Fehler, denn es waren alles Nutzer, die sich — selbst nach Aufforderung per E-Mail — vor mehr als 6 Monaten eingeloggt hatten und damit als “inaktiv” markiert wurden. Aber ein bisschen viel ist es schon…

Typische Log-Einträge sind dann:

[error] FastCGI: comm with (dynamic) server "/usr/local/fcgi-bin/fcgi-php-user" aborted: (first read) idle timeout (30 sec)
[error] FastCGI: incomplete headers (0 bytes) received from server "/usr/local/fcgi-bin/fcgi-php-user"

oder auch

[error] (4)Interrupted system call: FastCGI: comm with server "/usr/local/fcgi-bin/fcgi-php-user" aborted: select() failed
[error] FastCGI: incomplete headers (0 bytes) received from server "/usr/local/fcgi-bin/fcgi-php-user"

Letztere Meldung lässt sich angeblich durch ein Update von mod_fastcgi beheben. Das wird wohl auch für Redio mal fällig.

Update: Ich sehe gerade, dass die Apache Foundation die Rechte an mod_fcgid übernommen hat und das Modul aktiv weiterentwickelt. Das wäre sicherlich die bessere Alternative, als weiterhin auf mod_fastcgi zu setzen, das schon mehr als eine Jahr kein Update mehr erfahren hat.