Googles Web Accelerator and Damager

Google at it again - Ian sagt eigentlich schon alles, was es dazu zu sagen gibt. Google behauptet, sie wollten nicht "evil" sein. Aber dafür sind sie grenzenlos dämlich, wie sich am wiederholten Start des Web-Damagers zeigt.

Was macht der Web-Accelerator, und warum ist er so ein dämliches Stück Software? Nunja, er verfolgt einfach nur Links. Und zwar im Vorab, bevor der Benutzer es macht - sozusagen spekulatives Webcrawlen, nur eben privat für den Benutzer. Das klingt ja erstmal garnicht so schlimm, ausser das Server mit Traffic bombardiert werden, den sie möglicherweise so nie hätten - denn jeder Link wird schön weitergewandert, auch wenn der User da garnicht hin geht. Und das multipliziert mit den Benutzern die das Teil einsetzen ...

Aber der Traffic ist nicht das eigentliche Problem - das eigentliche Problem kommt erst, wenn man sich überlegt in welchem Context das Teil läuft. Und zwar hängt es ja auf dem privaten Rechner des Benutzers, zwischen Browser und Netz. Einfach ein eigener kleiner Proxy. Der für seine Arbeit sich Cookies und ähnliches merkt und an die Seiten dann Requests schickt, die so aussehen als kämen sie vom Browser des Benutzers. Mit dessen Security-Headern. Und Cookies.

Abgesehen davon, das ich es nicht sonderlich prall fände wenn meine Header mit Passwörtern oder Sessioncookies woanders als im Browser und im Zielserver auftauchen - diese Vorgehensweise ermöglicht es dem Webaccelerator sich auch Bereiche anzugucken, die ein zentraler Crawler nicht sehen würde. Nämlich zum Beispiel Seitenbereiche, die hinter Logins liegen. Content-Management-Systeme, bei denen nach Login zusätzliche Links auftauchen. Wikis, deren Edit-Links dann kommen, wenn jemand eine Session startet. Webmailsysteme, bei denen jede Mail als ein Link abgebildet ist.

All diese Systeme haben eines gemeinsam: für verändernde Aktionen ist nicht immer ein Formular-Absenden notwendig. Oft reicht es, einen Link zu klicken. Die aktuelle Version einer Seite im Wiki zu löschen, um schnell Wikispam zu beseitigen - ein einfacher Link, nur für den angemeldeten Benutzer sichtbar. Die Mail im Webmail-Postfach, die bei Aufruf automatisch auf gelesen gesetzt wird. Der Veröffentlichen-Link im CMS, mit dem eine Seite scharfgeschaltet wird.

Natürlich versuchen verantwortungsvolle Programmierer von Webanwendungen die destruktiven Aktionen hinter Formulare (und damit POST Requests) zu packen, damit nicht ein einfacher Link irgendwas zerstört. Aber das passiert in der Regel nur in den öffentlich zugänglichen Bereichen, bei denen sonst die Webrobots der diversen Suchmaschinen und Spam-Automaten sonst Chaos verursachen würden.

Aber gerade in den durch Login abgeschotteten Bereichen rechnet man normalerweise eben nicht mit Automatenklicks - und baut daher Komfortfeatures ein, weil man ja sicher sein kann, das ein Link bewusst und in Absicht geklickt wird.

Tja, bis dann der Web Accelerator von Google kam. Von der Firma, die von sich behauptet das Web kapiert zu haben. Schönen Dank auch, ihr Arschlöcher.

PS: und entgegen der ersten Version schickt die neue Version keinen Header mehr mit, an dem man die Prefetch-Requests erkennen könnte um sie in solchen kritischen Bereichen zu blocken.

tags: Programmierung, Sysadmin