Schädlich…

…sind laut Google sämtliche Suchergebnisse, zumindest waren sie das Heute Nachmittag.

Die Ursache…

…ist die Liste mit Bruchstücken schädlicher URLs, die Google offenbar führt, und gegen welche alle Suchergebnisse geprüft werden. Aufgrund eines `menschlichen Fehlers` hat beim heutigen Update ein einzelner Slash (`/`) seinen Weg in die Blacklist gefunden – ein leider nicht seltener Bestandteil vieler gültiger URLs, vor welchen als Folge lauthals gewarnt wurde. Vollkommen unabhängig davon, ob nun Google selbst, die Wikipedia oder eine beliebige andere Seite das Ziel war, jede Webseite `kann ihren Computer beschädigen` und jeder Besucher bekam die Google-eigene Vorschaltseite vorgesetzt, auf der ausdrücklich vor dem Besuch der betreffenden Seite gewarnt wird. Nun, generell mag ja gesunde Vorsicht im Internet angebracht sein, besonders, wenn es sich um Google handelt…

…und die Wirkung…

…war letztlich nicht nur ein leichter Image-Verlust seitens Google und verwunderte, zuweilen entsetzte Äusserungen einiger Google-User in diversen Boards. Auch die Webseite des gemeinnützigen Projekts StopBadware.org, mit dem Google kooperiert, wurde für Stunden ausser Gefecht gesetzt – der Grund dafür war ein Link auf StopBadware, der auf der zwischengeschalteten Warnseite zu finden war und weiterführende Informationen versprach. Angesichts dessen, dass es wohl einige Besucher interessiert hat, warum die Webseiten ihrer Bank oder die Wikipedia urplötzlich ihren Computer gefährden sollen, war StopBadware.org in Folge einem typischen – nur `etwas` stärkeren – Slashdot-Effekt ausgesetzt, einem Besucheraufkommen, mit dem die Betreiber wohl schwer rechnen konnten.

Generell scheint fraglich…

…in wie weit die Erkennung `böser` Seiten seitens Google überhaupt wünschenswert ist – und das nicht erst seit diesem Vorfall. Jeder sollte wissen, dass man seinen Browser und die verwendeten Plugins auf dem neusten Stand halten sollte und von bestimmten, nicht näher zu erwähnenden Browsern, die in der Vergangenheit immer wieder durch über längere Zeit offene und währenddessen auch aktiv ausgenutzte Schwachstellen aufgefallen sind, Abstand nehmen soll – nicht weniger klar ist, dass man das seltsam anmutende Binary, welches einem eine Webseite automatisch zum Download anbietet, nicht herunterladen und schon gar nicht ausführen sollte. Für viele User ist dies selbstverständlich – für alle anderen besteht eine Gefahr ähnlich derjenigen bei der Verwendung von Malwarescannern oder Desktop-Firewalls: Aus einer Implikation kann stillschweigend eine Äquivalenz angenommen werden; warnt Google, ist die Webseite vermutlich `böse` (was man auch immer darunter verstehen mag…), warnt Google allerdings nicht, bedeutet dies selbstverständlich nicht, dass man nun jedes Binary, das einem die Webseite anbietet, blind herunterladen und ausführen soll. Ausserdem besteht die Gefahr einer `Brandmarkung` von Webmastern und ihren Webseiten durch falschpositive Treffer – was das bedeutet, muss nach dem heutigen Vorfall vermutlich nicht näher erörtert werden.

1337 XOR Elite

…wobei sich dieser Artikel nicht um 13375p34k (Leetspeak) drehen soll, sondern viel eher um die 1337crew (oder neu auch 1337-crew, da wohl die SLD 1337crew unter der TLD `to` schon vergeben war, und die Befürchtung umgeht, die frühere `info`-Second-Level-Domain könnte deaktiviert werden). Hinter dieser zweifelsohne kindischen Bezeichnung verbirgt sich eine Community, die zumindest zu einem grossen Teil aus Personen mit dunklen Hüten und Skript-Kiddies besteht. Neben einigen wenigen durchaus legitimen Themen finden sich vor allem Anfragen von Skript-Kiddies, wie man $seite `hacke` (auch ich hatte vor einiger Zeit einen Fan dort), wie man $malwarebaukasten bediene oder wie man die damit erstelle Malware vor Malwarescannern verstecken könne. Zur Anonymisierung steht unter anderem eine eigene Tor-Node zur Verfügung, samt Anleitung, wie man Tor angeblich dazu bringt, statt des üblichen Circuits aus 3 Nodes nur die 1337crew-Node zu verwenden (dass dies das grundlegende Konzept von Tor – dass die Anonymität niemals auf dem Vertrauen zu einer einzigen Autorität beruhen darf – untergräbt, sollte klar sein. Ich will nicht behaupten, dass die 1337crew-Node loggt; wenn sie es aber – aus welchem Grund auch immer – täte, dann würden sämtliche Informationen anfallen, die zur De-Anonymisierung der Nutzer notwendig sind).

Von `hochwertigen Angeboten`…

Es wäre jedoch falsch zu glauben, die Community bestünde nur aus Skript-Kiddies – eine andere, wesentlich unschönere Seite sind die `hochwertigen Angebote`. Hier werden gestohlene Kreditkartennummern von Privatpersonen, Malware-Generatoren, gestohlene Accounts, Keys für diverse Spiele und ähnliches verkauft. Auch kann man das Botnetz von 13speedtest37 für DDoS-Attacken `mieten`.
Wie mittlerweile bekannt sein dürfte, habe ich für vieles Verständnis, nur nicht für solcherlei Handel. Und für die Verbreitung von Malware auch nicht – wobei es zum Glück (oder leider, das hängt ganz vom Standpunkt ab) bei Baukasten-Malware immer noch sehr populär ist, zur Übertragung der gestohlenen Daten nicht verschlüsselnde Protokolle wie FTP oder SMTP zu nutzen – und das meist nicht als Drop-Box. Wenn da rein zufällig ein Netzwerksniffer läuft…

…und dem Umgang mit Kritik

Das Botnetz des Inhabers ist freilich nicht nur da, um vermietet zu werden – nein, auch gegen die Kritiker (ob nun sachlich oder nicht, sei dahingestellt) der Crew, respektive gegen die Server, die deren Webseiten ausliefern, werden DDoS-Attacken gefahren. Opfer war erst dug-portal.com, wohl weil ein Mitglied einen abfälligen Kommentar bei newsbox.cc eingestellt hatte (in der Folge war auch newsbox.cc `temporär überlastet`). Im Verlauf des Werbethreads im G:B, der in einen Diskussionsthread ausartete, wurde erst onesworld und etwas später – komischerweise kurz nach einem Post von Mati, der einen Link zu FreiBrief.net in seiner Signatur stehen hatte – auch YourFTP (unbeteiligt; das ist aber egal, schliesslich war FreiBrief.net darauf gehostet) seltsamerweise Opfer von DDoS-Attacken – aber das war wohl nur ein seltsames Zusammentreffen unglücklicher Umstände…

DDoS Mania…

Der kritische Thread liegt nun schon einige Wochen zurück. Ob YourFTP jemals zurückkommt, steht in den Sternen – wobei man fairerweise anmerken muss, dass das nach eigenen Angaben nicht nur mit der DDoS-Attacke in Verbindung steht. onesworld ist wieder da, FreiBrief.net war einige Zeit bei CroneKorkN auf einem Homeserver gehostet, wo auch alles glatt lief – doch wenige Stunden nach dem Umzug auf einen neuen Webspace gingen die Angriffe wieder los, wobei die angeforderten URIs darauf schliessen lassen, dass ein gewisser Administrator der 1337crew wohl auf die etwas kritischen, zuweilen leicht sarkastischen Posts CroneKorkNs im Ankündigungsthread auf FreiBrief aufmerksam wurde. Seit jenem Tag ist ein ständiges auf und ab – zeitweise lassen die Attacken nach, einige Stunden später sind die Zombies wieder da – gang und gäbe.

Update: 13speedtest37 hat seine Angriffe unter der Voraussetzung, dass einige von CroneKorkNs Posts, die wohl zugegebenermassen etwas über das Ziel hinausgeschossen sind, entfernt werden, eingestellt.

Designfehler von CCF 3.0…

…wurden vor einigen von Lukas und laxity untersucht und veröffentlicht (an dieser Stelle sei angemerkt, dass keine direkte Gefahr für diejenigen besteht, die den Container zum Schutz ihrer Links eingesetzt haben. Es gibt momentan keinen öffentlichen Decoder dafür, und die Autoren des Artikels haben keine Intention, einen solchen zu veröffentlichen).

Eine Ergänzung…

meinerseits: Der Cipher ändert die Daten nicht mehr, sobald des niederwertigste Byte des Schlüssels einmal 0×00 ist. In diesem Fall findet in jedem Schritt eine Bitrotation der Schlüssels um 0 statt und die Daten werden mit 0×00 XOR-Verknüpft. Beides hat offensichtlich keine Änderung des inneren Zustandes mehr zur Folge und die Ausgabe entspricht fortan der Eingabe.
Schwach sind nun die Schlüssel, die nach wenigen Durchläufen diesen Zustand erreichen. Die triviale Lösung ist natürlich ein Schlüssel, der zu Beginn schon in dieser Form vorliegt, mit einem low-Byte von 0×00 (was im Artikel genannt wurde). Ebenfalls ungut ist aber z.B. der Schlüssel `00 ?? ?? 08`. Die erste Bitrotation (Links, um 8 Bit) wird den Schlüssel in `?? ?? 08 00` überführen, womit der Endzustand wiederum erreicht wäre. Ähnlich beim Schlüssel `?? ?? 02 01` – hier wird das das letzte Bit bei der ersten Rotation (Rechts, um 1 Bit) ans andere Ende des Keys rotiert, das letzte 0-Bit des nächsten Bytes (02) rutscht nach. In Binärdarstellung – vor der ersten Rotation:

???????? ???????? 00000010 00000001

…und danach:

1???????? ???????? ?0000001 00000000

Clickjacking – CSRF, revisited!

Seit kurzem ist eine neue Form von Cross-Site Request-Forgery (oder auch `UI Redress Attack`, da der Angriff eben keine CSRF-Attacke im klassischen Sinne darstellt) im Gespräch – das so genannte Clickjacking. Während beim klassischen CSRF versucht wird, einen Request (z.B. durch das Abschicken eines versteckten Formulars) an eine fremde Seite zu schicken, in der Hoffnung, das Opfer wäre dort z.B. per Cookie authentifiziert (was dazu führt, dass der Request in `seinem Namen` ausgeführt wird), ist der Weg beim Clickjacking ein anderer. Hier wird die Seite, auf der man das Opfer bestimmte Aktionen vornehmen lassen will, in einem (unsichtbaren) IFRAME geladen. Nun wird versucht, das Opfer auf bestimmte Bereiche klicken zu lassen (die Bereiche, wo sich – rein zufällig – die Buttons und Links im unsichtbaren IFRAME befinden).

Vom Klickdieb…

Bis die Technik von Robert Hansen und Jeremiah Grossman näher untersucht wurde, wurde sie vor allem mit Manipulation von Umfragen in Verbindung gebracht. Die Analyse brachte jedoch zu Tage, dass solche Angriffe weitaus gefährlicher sind, als bisher angenommen – Scheinbar sind die Informationen darüber so brisant, dass Adobe die Forscher bat, den angekündigten Vortrag OWASP-Konferenz zurückzuziehen – was sie am Ende auch taten.

…zum Spion

Nun hat aber Guy Aharonovsky ein Proof-of-Concept einer solchen Attacke veröffentlicht. Seine Demo-Seite simuliert ein JavaScript-basiertes Klickspiel (bei dem es – angeblich – darum geht, möglichst viele Buttons in möglichst kurzer Zeit anzuklicken). Im Hintergrund wird die Seite
http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager06.html
geladen – das Privacy-Tab des Flash-Einstellungsmanagers. Durch Mischung von wirklich sinnlosen `Spielklicks` und Klicks, die im unterliegenden IFRAME mit der Flash-Einstellungsseite Aktionen auslösen, wird schlussendlich erreicht, dass der (in diesem Fall hoffentlich nicht ahnungslose) Benutzer für die Domain in den Webcam- und Mikrofonenstellugen das `immer zulassen`-Flag setzt. Die im ursprünglichen Proof-of-Concept gezeigte Schwachstelle wurde durch Macromedia soweit behoben, als dass das Einbinden der obigen Seite in einen IFRAME durch einen JavaScript-Hack verhindert wird. Dies hindert einen Angreifer jedoch nicht daran, direkt die Flash-Datei
http://www.macromedia.com/support/flashplayer/sys/settingsmanager.swf?defaultTab=privacy
in den IFRAME zu laden. Ein entsprechend gepatchtes PoC findet sich hier.

Und nun?

Es dürfte nun klar sein, dass die Gefahren, die von einem Benutzer ausgehen, der gutgläubig da klickt, wo es ihm eine bestimmte Webseite vorgibt, nicht zu unterschätzen sind. Wie kann man sich schützen? Schutz verspricht die Firefox-Erweiterung Noscript seit Version 1.8.2 – aus dem Changelog:

New „ClearClick“ protection, specifically addressing Clickjacking, Clickjacket and other UI-redressing vulnerabilities: UI interaction with embedded objects is disabled if they’re obstructed or not clearly visible (thanks Sirdarckcat, RSnake, Michal Zalewski and Matt Mastracci for inspiration and discussion)

In den folgenden Versionen wurde der `ClearClick` genannte Algorithmus weiter verbessert.
Eine weitere Lösung bestünde natürlich darin, sich zu überlegen, welche Webseiten man besuchen will und welche nicht – und darin, JavaScript, Flash und ähnliche Spielereien nur dort zu aktivieren, wo man sie auch braucht…

Freie Software und ein erfreuliches Beispiel…

…dafür, wie schnell man sich um Fehler und mögliche Sicherheitsprobleme kümmert, stellt der Mac OS X-Multi-Protokoll-Messenger Adium dar. Vor kurzem fiel mir beim Löschen eines Kontakts von der Kontaktliste auf, dass der Screen-Name des Kontakts im anschliessenden Bestätigungsdialog als Format-String interpretiert wird – mit allen unguten Folgen, die das hat.

Ich meldete dies gleich in #adium-devl, und war positiv überrascht, wie schnell man sich des Problems annahm.

Wed, 07 Oct 2008
[22:02:44] _Kugelfisch_
Hi folk. I just discovered a possible security problem – when deleting an user from my contact list, its name seems to get parsed as a format string in a *printf()-family call. This can cause Adium to crash and possibly allows the execution of arbitrary code. I’m using Adium 1.3.1 with a localized (german) interface.
[22:05:37] hal2k
_kugelfisch_: do you have the file where that happens?
(the name of it)
or did you just have issues with a name that contains a %
[22:06:25] _Kugelfisch_
Just rename any Buddy to `%x%x` and have a look at the confirmation dialog box when trying to remove him from your contact list.
[22:07:25] hal2k
ok, I’ll look into it
[--SNIP--]
[22:16:56] CIA-17
am * r25322 /trunk/Source/AIContactListEditorPlugin.m:
Fixed an issue where printf-style escapes caused troubles in an alert when deleting the contact. Reported by _Kugelfisch_ in #adium-devl.
http://trac.adiumx.com/changeset/25322
[22:17:02] hal2k
_kugelfisch_: there you go
thanks for the report

Fazit: Nach kaum 15 Minuten war der Fehler im Subversion-Trunk des Projekts behoben, mit der nächsten Version wird das auch für die User der Fall sein. Bis dahin lässt sich das Problem umgehen, indem man keine Kontakte, deren Screennamen Format-String-Tokens enthalten, löscht – oder diese vorher umbenennt.

Um einen ähnlichen, aber weitaus gefährlicheren Fehler in ihrem proprietären Client zu beheben, hat ICQ Inc. im Frühjahr knapp 2 Monate gebraucht. Und das, obwohl die Ausnutzungsmöglichkeiten bekannt und die Schwachstelle aktiv ausgenutzt wurde – wenn auch nur, um den Client abstürzen zu lassen.

Update, 10.10.08: Die soeben veröffentlichte Version 1.3.2 behebt das Problem.

Heute feiert Google…

…seinen zehnten Geburtstag. Dass Google von Sergey Brin und Larry Page in einer Garage gegründet wurde, ist gemeinhin bekannt – dies geschah am 7. September 1998, Heute vor relativ genau 10 Jahren (die genaue Tageszeit der Gründung ist nicht bekannt). Vorläufer war die Suchmaschine BackRub – eine Technologie, die bei den damaligen Portalen auf Abneigung stiess. Ja, Internetportale – erst Google brachte die Erkenntnis, dass eine Suchmaschine keine Wettervorhersagen oder News braucht, um Erfolg zu haben, in die breite Masse. Jahre später wird sich das mit der `personalisierten Startseite`, später `iGoogle` genannt, wieder ändern. Schon damals war bei Google im ersten Jahr ein Merkmal vorhanden, das man von vielen heutigen Web 2.0-Diensten kennt – ein `Beta`-Vermerk.

Von der beliebten Beta-Version…

Anfänglich war Google beliebt – 1999, zum Ende der Beta-Periode, wurden täglich bereits über eine halbe Million Suchanfragen verzeichnet. Dienste wie Google Groups, AdWords/AdSense, Google News und GMail sollten in den nächsten Jahren hinzukommen. Gut und schön, wäre da nicht die eine Sache…

…zur missliebigen Datenkrake

Schon relativ früh stellte sich heraus, dass Google nicht nur auf die gespiderten Ausschnitte aus Webseiten scharf ist. Google möchte irgendwann in der Lage sein, Fragen wie `Was soll ich morgen tun?` oder `Welchen Job soll ich morgen annehmen?` sinnvoll zu beantworten. Ob das möglich ist, sei dahingestellt – wenn es möglich wäre, müsste man in jedem Fall ein umfangreiches Wissen über das Privatleben des Suchenden haben – und genau darauf ist Google aus. GMail mit seinen bald 7GiB Speicherkapazität – nett für die User die keine Mails löschen müssen, aber auch nett für Google, da die Mails ewig zur Kombination zur Verfügung stehen (an dieser Stelle sei jedoch angemerkt, dass der oft kritisierte Paragraph der Nutzungsbedingungen, dass die Mails automatisch durchsucht würden, bei praktisch jedem anderen Freemail-Anbieter in ähnlicher Form zu finden ist – kontextsensitive Werbung ist nun einmal leider zeitgemäss). Zusammen mit den Daten aus Web-Suchanfragen, den News- und Usenet-Recherchen, Kalender-Einträgen, eingestellten Texten & Tabellen, eventuellen Blog-Posts oder -Kommentaren auf blogger.com sowie den Informationen, die aus den in vielen Seiten eingebundenen Google-Ads gewonnen werden können, lassen sich durch Kombination wohl einige persönliche Details erfahren, die man selbst lieber nicht veröffentlicht hätte.
Gerade der Kalender wurde kürzlich kritisiert, da anscheinend einige Personen unbeabsichtigt das `öffentlich`-Flag gesetzt haben, und danach Suchanfragen wie `Kreditkarte` Daten zu Tage gebracht haben, die man üblicherweise geheim halten will – gut, dafür kann Google nichts.

Unmut, verchromt!

Ebenfalls viel Kritik und Lob erntete der neue Google-Browser – Google Chrome. Während die Geschwindigkeit des kürzlich veröffentlichten und auf WebKit basierten Browsers gelobt wurde, sorgt insbesondere die Tatsache, dass in der Standardkonfiguration alles, was in das eine Eingabefeld getippt wird, an Google gesendet wird, für Unmut. Auch der anscheinend 1:1 von Google Docs kopierte, schon damals hart kritisierte und mittlerweile wieder entferne Passus der EULA, der besagte, dass man Google ein irreversibles Nutzungsrecht an allen übermittelten Daten einräume, sorgte für allgemeinen Missmut. Mittlerweile warnt laut Golem.de auch das deutsch BSI vor Chrome – aus sicherheitstechnischen Gründen sei die Anhäufung von Daten bei einem einzelnen Unternehmen kritisch. Völlig korrekt!

Die Zukunft…

…liegt laut Google in Webapplikationen. Darauf ist Chrome ausgelegt, dafür wurde Google Gears entwickelt. GMail, Google Docs (Texte & Tabellen) und Google Calendar illustrieren diese Idee. Als Nebeneffekt würden eventuell sogar die oben genannten Zukunftsfragen von Google beantwortet. Nur – will man das wirklich? Diese Frage mag jedermann für sich entscheiden.

`Aber du…

…benutzt doch auch GMail!` – Korrekt. Ich benutze tatsächlich GMail, um automatisch generierte Blog- und Board-Benachrichtigungen zu verwalten. Mit dem Webfrontend von GMail kann sich kein anderer Freemailer messen. Allerdings blocke ich sämtliche Cookies, die nicht direkt von mail.google.com stammen. Hiermit wünsche ich Google viel Spass mit der Information, dass ich blogge und unter dem Nick `Kugelfisch23` im gulli:board registriert bin.

Last but not least, trotz allem – Happy Birthday, Google!

Von der Schliessung der gulli:börse, Spinnen, Urlaubern und Plagiaten…

Die gulli:börse, einst Umschlagplatz für Millionen Bytes an Warez, wird geschlossen – Phase 1, die Read-Only-Zeit, wurde am Freitag, dem 08.08.08, eingeläutet, Phase 2, die Komplettschliessung erfolgte am Monag, dem 11.08.08. Die drei Tage Übergangsfrist sollten den Benutzern die Möglichkeit geben, Backups anzulegen.

Nimm, was du kriegen kannst…

Die Folge war abzusehen – das Board hatte dieser Tage eine Spider-Plage zu beklagen. Viele wollten sich zumindest Teile der Börse sichern, was verständlicherweise einen `leicht` negativen Einfluss auf die Boardperformance hatte, um nicht zu sagen, das Board sei ständig überlastet gewesen. Nun, ein drei Tage überlastetes Board will man ja auch nicht. Also lässt man kurzerhand alle User, die einige Requests mehr tätigen, automatisiert für 3 Tage beurlauben. `Too many spider …` – ja, zu viele Spinnen, die zu viele Requests tätigen. Prominentes Beispiel eines solchen Urlaubers ist vmk. Auch mein Perl-Skript, das einige Backups machen wollte, war nicht wirklich gerne gesehen, auch ich gewann einen 3-Tage-Luxusurlaub.

gulli ($version++)

Mit der Schliessung der Börse geht unbestritten eine Ära des g:b’s zu Ende. Doch auch nach der Schliessung der Börse wird das gulli:board garantiert weiterleben, mit dem hübschen Nebeneffekt, dass die Serverlast – und damit auch die Frequenz der Überlastungsmeldungen – sinken dürfte. Insgesamt habe ich selbst die Börse selten verwendet, dennoch war sie da, praktisch, wenn man einmal etwas laden wollte. Aber so ist das Leben – altes vergeht, neues entsteht.

build gulli replica now!!!

…dieser Text entstammt keineswegs der Betreffzeile einer allseits erwünschten eMail. In der Phase der Börsenschliessung schossen Gulli-Plagiate in rauen Mengen aus dem Boden, den höchsten Bekanntheitsgrad geniesst ein Projekt, das erst `gulli:open`, dann `open gulli:börse` und schliesslich open:gully genannt wurde. Während dieses sowieso unter Erreichbarkeitsproblemen leidet, macht die Administration des g:b’s indes die Betreiber solcher Kopien auf Markenrechtsprobleme aufmerksam.
Doch auch open:gully selbst hatte Trittbrettfahrer – ein in hohem Masse kreatives Individuum hielt es für nötig, die Domain opengully.de zu registrieren und dort zu behaupten, open:gully sei `ins UseNet umgestiegen` (dieses Individuum sollte eher lernen, sicheren PHP-Code zu schreiben). Der nötige Ref-Link zu einem berüchtigten Usenet-Provider durfte natürlich nicht fehlen.

Update 1.0: open:gully ist tot. Der Administrator hat das Projekt aufgegeben, nachdem vermeintliche Realdaten `von jemandem, der nur helfen wollte` veröffentlicht wurden.
Update 2.0: open:gully entschwebt der Asche – oder soll das zumindest am 30. August tun. Eigenen Angaben zufolge wird ein anderer das Projekt weiterführen. Die zweite, bekannte Kopie gulli2.com soll seinen Angaben zufolge indes für DDoS-Angriffe verantwortlich sein.

RapidShare und die `armen` Leecher

RapidShare.com ist böse, Müll und überhaupt irgendwie schlecht – zumindest, wenn den `armen` Leechern mit dynamisch vergebenen IP-Adressen glauben darf.

Von glücklichen Stunden und Katzen…

Hintergrund dieser `Kritik` ist, dass RapidShare in den letzten Wochen das Hund- und Katzspiel mit Captchas leid geworden ist. Nach den verzerrten Katzencaptchas, die immerhin einige Wochen hielten, kam kurze Zeit ein tEABAG_3D-Derivat zum Einsatz, wessen Status einige Tage zwischen den Extrema `per OCR erkennbar` und `für Menschen nicht lesbar` schwankte. Nicht unerwähnt sollten die zu dieser Zeit aktiven `Happy Hours` bleiben – immerhin 16 Stunden am Tag kamen überhaupt keine Captchas zum Einsatz. RapidShares Plan war wohl, die extreme Bandbreitenauslastung während des Ansturms in den frühen Abendstunden durch Verlagerung der Free-User-Aktivitäten in Zeiten schwächerer Auslastung abzufangen. Dieses Unterfangen wurde aber durch automatisierte Erkennungsmethoden für die Captchas vereitelt – der verbotene Apfel musste zwingend gepflückt und gegessen werden, die täglich verbleibenden 8 Stunden mussten dringend auch zur automatisieren Generierung von Traffic ausgenutzt werden.

Aus dem Paradies vertrieben…

Dass RS.com dieses Spiel nicht ewig mitspielen wird, war abzusehen. Vor einigen Tagen wurde statt eines Captchawechsels eine neuartige Massnahme ergriffen – die Geschwindigkeit für Free-User wurde auf 500 Kilobit (ca. 63KiB) pro Sekunde gedrosselt, dafür entfallen die Captchas sowie die Wartezeit nach jedem Download. Unter den deutschen Leechern mit ihren dynamisch zugewiesenen IP-Adressen machte sich sehr schnell Unmut breit. Man brauche jetzt viel länger für die neuen Urlaubsfilm-BluRay-Discs, da man nicht mehr ununterbrochen mit 16 Megabit pro Sekunde laden könne. Dass man früher eigentlich mehr als zwei Stunden nach jedem 100MiB-Download hätte warten müssen, und dass die knappen 30 Minuten, die man als Free-User nun für 100MiB braucht, verglichen damit durchaus human sind, braucht keiner zu wissen. Schliesslich konnte man die Wartezeit durch ein Neuaufbauen der DSL-Verbindung und den damit verbundenen IP-Wechsel abkürzen.

…oder auch nicht?

Freilich hat nicht jeder eine dynamisch zugewiesene IP-Adresse. In vielen Ländern sind IP-Adress-Pools so gut wie unbekannt. Da zeigte das alte System sein wahres Gesicht – schön, wenn man für 5 Minuten die DSL-Leitung glühen lassen konnte, unschön, dass man danach einige hundert Minuten warten musste. Für all jene, die das alte System nicht ausgetrickst haben – etwa, weil es aufgrud einer fixen IP-Adresse nicht möglich war – stellt das neue System eine deutliche Verbesserung dar. Ausserdem bringen im neuen System auch Downloads von Premium-Usern Punkte, was den Uploadern sicherlich gefallen dürfte.

Auch die Premium-User…

…wurden in den letzten Wochen mit einigen Neuerungen beglückt. Neben einer – nach kurzer Zeit wieder zurückgenommenen – `Vereinfachung der Trafficabrechnung`, welche zur Folge hatte, das pro Tag `nur` 10 GiB Traffic erzeugt werden durften (statt 50GiB beliebig über 5 Tage verteilen zu können), wurden auch Massnahmen gegen Accountsharing ergriffen. Während auch hier eine grosse Menge höchst sinnvoller Beschwerden von Personen kamen, die vorher – den AGB zum Trotz – Accounts geteilt haben, gab es doch auch begründete Kritik – da der Premium-Account 15 Minuten nach jedem Download gesperrt bleibt, hat eine Zwangstrennung der Verbindung seitens des Providers eine Verzögerung von bis zu 15 Minuten zur Folge. RS.com versuchte, diesem Problem durch Lokerung der Sperre für das jeweilige /24-Subnetz Einhalt zu gebieten. Da einige ISPs jedoch verschiedene /24er-Netze in ihrem DHCP-Pool haben, ist das Problem dadurch nicht endgültig gelöst.

Früher…

…war bekanntlich alles besser. Was wollen die Power-Leecher? Diese Frage ist einfach zu beantworten, die Antwort wird jedoch verständlicherweise ein Wunschtraum bleiben. Was einige wollen, ist ein System, dessen Limits man austricksen kann. Keiner will wirklich wieder Captchas und Wartezeiten nach jedem Download. Das `gute` alte System ist nicht so beliebt, weil es wirklich grosszügiger war, sondern, weil es seine Wirkung – zumindest im Lande der dynamischen IP-Adressen – nicht entfalten konnte – und diese Tatsache ist RS.com verständlicherweise ein Dorn im Auge.

Im Endeffekt…

…ist dieser Post uninteressant. Die Leecher wollen soviel wie möglich in möglichst kurzer Zeit gratis herunterladen. Punkt. Alles andere ist uninteressant.

Mit Wine 1.0 und Firefox 3.0…

…können gleich zwei populäre freie Softwareprojekte am gleichen Tag ein Major-Release zeigen.

Wine hat, wie bei freien Projekten üblich, mit Version 1.0 nach 15 Jahren Entwicklungszeit die erste Version veröffentlicht, die offiziell nicht mehr den Beta-Status trägt. Die Implementation der Windows-Bibliotheken und die Nachbildung der WinAPI sind jedoch nach wie vor nicht komplett, neben den vielen Anwendungen, die mit Hilfe von Wine auf diversen unixoiden Betriebssystemen (Linux, FreeBSD/Darwin/Mac OS X, Solaris) laufen, gibt es nach wie vor einige, die gar nicht oder nur sehr eingeschränkt oder instabil funktionieren. Wenn man bedenkt, dass die nachgebildeten Schnittstellen oft schlecht oder gar nicht dokumentiert sind, ist der jetzige Status des Projekts jedoch schon eine gewaltige Leistung seiner Entwickler. Auch die Tatsache, dass es mit CrossOver und Cedega gleich zwei kommerzielle Forks gibt zeigt die Leistung, die das Wine-Projekt erbracht hat.

Auch die Mozilla-Entwickler können ein neues Release ihres Browsers vorzeigen, Firefox 3.0. Neben vielen anderen Änderungen wurde die Performance entscheidend verbessert (wobei fixe Hintergrundbilder nach wie vor einen Performanceeinbruch beim Scrollen zur Folge haben), eine Suche in die Adressleiste integriert und die endgültige Version des Browsers besteht – wie schon die erste Beta – den Acid2-Test. Für einige der populäreren Erweiterungen existieren bereits Kompatibilitätsupdates, weitere sollen in den nächsten Tagen folgen. Wer nicht warten will und wer experimentierfreudig ist, dem sei gesagt, dass viele Erweiterungen mit der neuen Browserversion problemlos zusammenarbeiten, nachdem sie z.B. mit den `Nightly Tester Tools` als `kompatibel` markiert wurden.

Neben dem eigentlichen Release des Browsers macht Mozilla noch mit einer anderen lange angekündigten Aktion von sich reden – mit dem `Firefox Download Day`. Im Vorfeld konnte ein Downloadversprechen abgegeben werden, am Abend des 17. Juni 2008 wurde der Download schliesslich freigegeben. Während normalerweis gerade bei populären freien Projekten der Ansturm der Besuchermassen nach einem neuen Release ein Schrecken der Administratoren sind, wurde dieses Verhalten hier – durch den Weltrekordversuch `Download Day` – provoziert. Die Turbulenzen kamen, wie sie kommen mussten, die Downloadserver zeigten zeitweise typische Überlastungssymptome, waren kaum oder gar nicht erreichbar. Doch die Aktion wurde dennoch ein Erfolg – beinahe 7 Millionen Downloads wurden getätigt, wenn man beachtet, dass das Firefox-Setup je nach System zwischen 7 und 17 Megabyte gross ist, kommt man auf etwa 70 Terabyte an Traffic in aller Welt, welcher dank Firefox in den letzen 24 Stunden verursacht wurde und den die Mozilla-Server und ihre Mirrors verkraften mussten.

Update: Firefox’ `Download Day` ist vorüber – gut 8.5 Millionen Downloads kann die Mozilla Foundation vorweisen, die Guieness-Leute werden den Rekord in den nächsten Tagen prüfen.

«All packtets are equal…

…but some packets are more equal than others.»

Die Netzneutralität ist ein wertvolles Konzept, das in der heutigen Zeit immer weiter eingeschränkt wird. `Netzneutralität` bedeutet, dass sowohl ISPs als auch Carrier jedes Datenpackt gleich zu behandeln haben – insbesondere darf keine Filterung oder Priorisierung anhand des Inhalts, des Protokolls oder des vermuteten Anwendungsbereichs vorgenommen werden. Während Internetzensur ebendieses Konzept von der einen Seite bedroht, steht an der anderen Front die Anti-P2P-Lobby sowie einige ISPs wie Comcast, die versuchen, Pakete, die vermuteterweise mit einem Peer-to-Peer-Netz ausgetauscht werden, zu verwerfen oder zumindest stark zu limitieren. Das ist jedoch nicht alles – Sandvine, die Entwickler des Filtersystems, das unter anderem von Comcast eingesetzt wird, hat vor kurzem ein neues Produkt vorgestellt, `FairShare` genannt. Während die Pressenotiz von Sandvine nicht viel über die Funktionsweise von `FairShare` verrät, spricht Sandvines Paper `The Value of Traffic Optimization in a World with Network Neutrality` eine deutlichere Sprache.

A policy is applied to heavy users during periods of congestion to allow light users a fair opportunity to use the available bandwidth. This policy usually consists of traffic shaping action and/or traffic prioritization to limit the abusive traffic during the congestion period.

Folglich soll die Bandbreite derjenigen, die ihre bezahlte Flatrate stark auslasten, zumindest während den Spitzenzeiten eingeschränkt werden. Ihre Pakete werden niedriger priorisiert, ihre Übertragungsgeschwindigkeit limitiert. Dies soll, laut Sandvine…

By encouraging heavy users to shift their usage to off-peak times, bandwidth can then be divided fairly among users throughout the day. The overall effect is an improved user experience.

…den armen Usern helfen. Die Wirklichkeit sieht aber so aus, dass sich der ISP in seiner Mischkalkulation vetan hat – schon in der Vergangenheit wurden Fälle bekannt, in denen ISPs Kunden, die viel Bandbreite verbraucht haben, gekündigt haben. Ebenfalls ist die Frage nicht beantwortet, wie die Bandbreiteneinschränkung genau erfolgen soll – wird das über BitTorrent heruntergeladene Debian-Image niedriger priorisiert als der Download des neusten Kinofilms über einen One-Click-Hoster, unter Benutzung des HTTP-Protokolls? Und wie sieht es mit den meist mehr oder weniger sinnlosen YouTube-Streams aus – oder mit Video-Streams von öffentlich-rechtlichen Fernsehsendern, z.B. über BBCs iPlayer, um einen Vorfall aufzugreifen, der sich im August letzten Jahres ereignet hat?