Codebalancer

Zur Info: Wenn man auf »Ja« klickt, bricht man das Script tatsächlich ab. Wer hätte das gedacht.

Gerade mal wieder ein Account registriert und nun sitze ich schon eine Viertelstunde hier und mir fallen nicht 2 gute »Sicherheitsfragen« ein.

Der Grund ist ganz einfach: Es gibt keine guten Sicherheitsfragen. Denn Sicherheitsfragen sind vom Prinzip her unsicher, weil sie das genaue Gegenteil eines guten Passworts bedeuten:
Die Antwort darf sich nie ändern, sollte nicht zu lang und kryptisch sein, ist oft bei der Eingabe sichtbar und die Frage selbst gibt einen sehr guten Hinweis zur Eingrenzung der Antwort.

Da bringt kein noch so gutes Passwort irgendwas, wenn es mit der Antwort auf die Frage nach Lieblingsfarbe, der Marke des ersten Autos oder des Lieblingsvereins, die aus einer einer Menge von 5 oder vielleicht 50 möglichen Antworten stammen, umgangen werden kann.
Die gängigen vorgegebenen Sicherheitsfragen sind außerdem der größte Schrott: Mädchenname der Mutter, Geburtsort, Lieblingssport. Sachen, die jeder aus dem Bekanntenkreis weiß, oder man in Zeiten von Blogs, Twitter und Social Networks meist mit ein paar Klicks herausfinden kann und genauso bei allen anderen Anmeldungen angeben soll.

Das ist so ähnlich, wie wenn Captain Picard vor versammelter Brückenbesatzung samt Praktikanten Fähnrich sagt: »Sicherheitsautorisation zum Abwerfen das Warpkerns: Picard Alpha Tango Zwei.«

Nicht zuletzt die Frauen Palin oder Hilton durften am eigenen Leibe Account erfahren, wie blöd Sicherheitsfragen (oder einfach schlechte Passwörter) sind.

Und was hab ich jetzt eigentlich mit meinen 2 Sicherheitsfragen gemacht?
Hab' mir von meinem Passwortverwaltungstool 2 kryptische Buchstabenfolgen erzeugen lassen und gespeichert. Da hab' ich jetzt quasi 3 Passworte für 1 Account. Aber immernoch sicherer als Mutters Nachname.

Der Google Reader ist ein sehr beliebter, und meiner Meinung nach sehr guter Feed-Reader.
Ein sehr cooles Feature ist der Cache, der es den Lesern ermöglicht, bis zum Zeitpunkt des ersten Abonnieren eines Feeds beim Google Reader zurück zu scrollen.

Ein Problem macht dieser Cache jedoch: Es ist für Feed-Publisher nicht ohne Weiteres möglich einmal gecachte Einträge wieder zu löschen. Was einmal rein geht, bleibt also für immer drin.
Das ist schon ärgerlich, wenn man ggf. irgendwie doppelten Inhalt, Testeinträge, Spam, unbezahlte ungekennzeichnete Werbung, versehentlich zu früh veröffentlichte Einträge, Postings mit wüsten Beschimpfungen, Postings im stark alkoholisierten Zustand annähernd ohne Grundregeln der Grammatik oder Sinn, Einträge der neuen Ex-Freundin mit »Arschloch. Die Bank PIN lautet: 5543« – oder sonst wie unerwünschte Inhalte – hat, die nun auf Ewigkeit von jedermann abrufbar bleiben.

Ich hatte mir vor ein paar Tagen selbst ein kleines Problem gemacht, indem ich die Subdomain eines Blogs entfernen wollte. Mittels permanent Redirect und die entsprechenden Einstellung in der Software zu ändern, dachte ich, wäre alles in Butter. Leider war dem nicht so.
Durch die Änderung der guid der Feed-Items von www1.domain.com auf domain.com sahen alle Einträge für den Google Reader nach neuem Content aus, und ZACK! hatte ich 10 doppelte Einträge, die ich quasi nie wieder rausbekomme. Sieht ganz schön doof aus.

Nun, ein kleiner Workaround ist mir zumindest eingefallen:

Ich war gerade etwas überrascht, keine etablierte Übersetzung des Begriffs »data rot« zu finden, was ich hier dann mal mit Daten-Fäule oder -Verwesung selbst festhalten würde.
Datenverwesung ist ein Thema, das uns wohl in den nächsten Jahrzehnten zunehmend beschäftigen wird, wenn wir nicht in die Geschichte als »das große schwarze Loch« eingehen wollen.

Ehrlich gesagt, ist es jetzt überhaupt erstmal da.
Nach zwei-drei anfänglichen Einträgen im Blog (damals noch unter de.pixelpope.com) – quasi ohne Namen, ohne eigenes Layout, ohne eigentliche thematische Idee – war dann auch wieder ganz schnell eine ganze Weile Ruhe.
Das soll jetzt ein bisschen anders werden, denn neben einem passenden Namen gibt's auch ein eigenes minimalistisches Theme und dann hoffentlich auch demnächst mehr Ideen und Musse, um ein paar Gedanken und Inhalte aus dem Technologie-, Internet-, und Super-Off-Topic-Bereich zu liefern. :)

Blogroll undso Kram (und auch Kommentare) kommen später, weil ich das Design ohne Seitenspalte eigentlich ganz cool finde, aber irgendwie braucht man sie dann ja doch...

Designmadeingermany ist nach einer mehrwöchigen, unfreiwilligen Pause endlich wieder da.
Grund waren Probleme mit 1&1. Kenne ich irgendwoher.

Nachtrag (2008):
Die Zahlen haben sich inzwschen wieder stark verändert. Durch die Verwendung von XML-Sitemaps und häufig aktualisiertem Inhalt kann man Google dazu bewegen, etwas öfter vorbei zu schauen, und eine Seite ggf. schon nach ein paar Stunden in den SERPs zu berücksichtigen.

Eine typische Frage, die man von Menschen hört, die eine neue Website haben, oder man sich bei neuen eigenen Seiten mal selbst stellt: Wie lange dauert es, bis eine komplett neue Website von Spidern von Google (oder Yahoo, MSN, etc.) überhaupt besucht, indiziert, und in dessen Index für Suchergebnisse berücksichtigt wird?

Kurze Antwort: Kommt drauf an.

Lange Antwort: Kommt drauf an.

Es gibt z.B. die Möglichkeit eine Website/URL manuell anzumelden.
Vergesst es. Das dauert ewig. 3 Monate ist da garnichts.

Schnellere Möglichkeit (auf die man natürlich nicht immer Einfluß hat): Website von irgendwo verlinken.
Die Bots der Suchmaschinen finden neue Seiten nämlich viel lieber von alleine.
Faustregel: Ein Link von einer »wichtigen«, oft aktualisierten, Seite macht eine neue Site schneller bekannt.
Im Idealfall ist die neue Site ja für themenrelevante Seiten interessant. Da kann man ja mal nett Bescheid geben. Aber bitte nicht in Blogs oder Foren rumspammen. Da hat man es sich schnell verscherzt.

Dabei ist noch zwischen interner Verlinkung (also innerhalb der selben Domain) und externer (zu anderen bzw. Subdomains) zu unterscheiden. Ersteres geht, da angenommen wird, dass die Seite zum eigenen Angebot gehört, schneller.

Meine Erfahrungswerte:

• Interne Verlinkung: ca. 36 Stunden
• Externe Verlinkung: ca. 2-3 Tage

Klar dürfte sein, dass diese Werte je nach »Wichtigkeit« einer Site, mehr oder weniger stark nach oben oder unten variieren, sprich: Oft und regelmäßig neuer Inhalt und eine gute Verlinkung helfen wie immer.

Nicht mal »Suchmaschinenprofis« können die Frage beantworten (außer ich glaube, wahrscheinlich und Google wird das schon wissen), warum Google Analytics offenbar Java und JavaScript durcheinanderwürfelt.
Etwas stutzig macht nämlich der Wert von um die 97% der Surfer, die Java installiert haben sollen.

Aber wozu gibt es denn Google?
Google verrät selbst die Antwort auf die Frage, die es bei der Unterscheidung von Fisch und Fleisch garnicht gäbe:

Java-Aktivierung bei Besuchern?
Die Variable zur Aktivierung von Java gibt an, ob JavaScript im Browserprogramm des Besuchers aktiviert ist.

Aha, ist doch mal eine Antwort. Obwohl:
Wie will Google Besucher ohne JavaScript überhaupt erkennen?

Der Analytics-Schnipsel sieht in etwa so aus:

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
_uacct = "UA-123456-7";
urchinTracker();
</script>  

Der Webbug besteht hier also nur aus einem Script. Das Script wird von Browsern ohne JS-Support bzw. wenn dies deaktiviert ist schlicht ignoriert (auch nicht geladen). Analytics kriegt in diesem Fall also garkeine Rückmeldung.
Ein Test mit LiveHTTPHeaders (eine Firefox Extension) läßt das leicht selbst nachvollziehen.

Ist also doch Java gemeint. Oder?

Ein Blick in das (relativ unleserliche) urchin.js zeigt (so um Zeile 64 rum):

else if (self.java) {
  var j=java.awt.Toolkit.getDefaultToolkit();
  var s=j.getScreenSize();
  sr=s.width+"x"+s.height;
 }

Es wird also durchaus die Java-Unterstützung überprüft. Daher könnte also wirklich Java und nicht JavaScript gemeint sein (ich halte es sogar für den sinnvollsten und daher wahrscheinlichsten Umstand).
Genau wissen das aber nur ein paar Leute bei Google (oder auch nicht).