Die WBC lädt mit Standardeinstellung der Browser Daten von diversen externen Seiten nach. Als Beispiel jquery.com oder diverses von Google. Diese Seiten haben somit die Möglichkeit, das Nutzerverhalten vollständig zu verfolgen - inkl. angesurfter Unterseiten etc.

Wer das noch nicht bemerkt hat bzw. wen das generell nicht interessiert, der möge diesen Beitrag gerne völlig ignorieren. Ebenfalls Leute, deren Aufmerksamkeitsspanne mehr als eine Hand voll Sätze nicht verträgt. Hier steht für dich nichts sinnvolles drin.

Wer besagtes Nachladen externer Inhalte und das damit verbundene Nutzertracking nicht mag und auch generell auf der sicheren Seite sein möchte, nutzt selbstverständlich auch schon auf anderen Seiten entsprechende Einstellungen oder Plugins in seinem Browser, die das verhindern. Viele Seiten nutzen heute die Google APIs oder Google Analytics, die die Nutzer weltweit tracken. Das ist nichts ungewöhnliches und die Mittel dagegen sind in Fülle vorhanden. Als Beispiel NoScript und RequestPolicy für Firefox, z.B. kombiniert mit dem privaten Modus. Aber auch Plugins, die sich speziell dem Thema Privatsphäre widmen.

Wer nun die WBC auf Inhalte rein vom WBC-Server beschränkt, den stört hier dann der Cookiedialog, der sich im oberen Teil der Seite breit macht und wichtige Inhalte (wie die Anmeldeinformationen) abdeckt. Dieser kommt bei der gerne genutzten Einstellung, Cookies nur für die aktuelle Session zu akzeptieren und bei jedem Neustart alle Cookies zu löschen, jedes Mal wieder. Sehr unschön, da sich dieser Dialog nicht ohne Nachladen externer<sic> Skripte vermeiden lässt (oftmals lässt sich das durch Aktivieren des seiteneigenen Javascripts beheben - hier bei VBulletin/DragonByte jedoch kann der Dialog offensichtlich nur durch ein von externen Servern bereitgestelltes Skript entfernt werden).

Doch auch dafür gibt es eine Serverunabhängige, lokale Lösung: Das Firefox-Plugin Stylish. Hiermit lassen sich Seiten im Hintergrund nach Bedarf modifizieren. Als Beispiel eignet sich das folgende Stylish-Skript, das unerwünschte Cookie-Overlay der WBC loszuwerden, ohne seine Daten an jquery, Google und all die anderen zu übermitteln:
Code:
@-moz-document domain(www.wb-community.com) { 
  #cookieControlWrapper {
    visibility: hidden !important;
  } 
}
Das Setzen des Cookie selber wird hierdurch nicht verhindert, ohne geht es schlicht nicht. Man muss dies nur einfach nicht auch noch bestätigen.

#### noch etwas persönliches - off topic ####

Ansonsten kann ich zur Umstellung gratulieren. Endlich ist man die Sache angegangen und kann auf eine moderne Forumssoftware setzen - sogar noch eine, die generell recht gut ohne Javascript funktioniert (heute nicht immer der Fall). Glückwunsch - Account- und Datenübernahme scheinen gut geklappt zu haben. :-)

Ich find es übrigens gut, dass hier auf ein kommerzielles Produkt gesetzt wurde. Die Software läuft noch nicht rund, es gibt Probleme an allen möglichen Ecken und sogar grundlegende Dinge machen Probleme oder funktionieren gar nicht¹, was mitunter der Forumssoftware zugeschrieben wird, der Fehler stecke dort. Man stelle sich vor, es wäre auf billige Open Source gesetzt worden, dann wäre das ebenfalls eine gute Ausrede gewesen und die Vermutung, das wäre mit guter kostenpflichtiger Software alles viel besser und einfacher und fehlerfreier gegangen, hätte - wie halt allgemein sehr gerne üblich - permanent im Raum gestanden. So zeigt sich, dass solch eine Umstellung auch mit den teuren und vermeintlich besten Produkten nicht fehlerfrei abläuft. Das ist halt so, da kann man wenig machen. Fehler passieren jedem Admin und keine Software ist perfekt, egal ob nun freie Software oder kommerzielle. Da ist es ziemlich egal, wozu man da nun greift. Jedoch ist es mir bei Leuten, die gerne alle Fehler von sich weisen und auf andere schieben - wie z.B. verwendete Software - generell lieber, wenn da zu kommerzieller Software gegriffen wird. :-P

Ich wünsche viel Erfolg bei der weiteren Arbeit. Ihr seid da auf einem guten Weg und Fehler, die mich wirklich ernsthaft stören, sind mir bisher nicht aufgefallen (bis auf die fehlende Verschlüsselung, ein Rückschritt gegenüber vorher... nu ja, wobei die zuvor auch nicht wirklich gut umgesetzt war mit dem Nachladen unverschlüsselter Inhalte etc.). Wenn ssl mal in Zukunft funktioniert, könnte man es richtig machen (so wie Wikipedia oder Google oder ein paar andere bekannte Seiten) und generell allen Traffic auf https verschieben. Wobei, so träge wie der Server jetzt schon reagiert, ist das vielleicht auch keine so tolle Idee...

¹) Notabschaltung von ssl/https, falsche Seitentitel, Galerieupload problematisch, uvm., das ganze Ding ist stellenweise noch lahmer als das alte Forum, um nur ein paar zu nennen...