Laden externer Inhalte unterbinden

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 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...

das cookie-ding ganz oben haben wir einer eu-richtlinie/verordnung zu verdanken...

frueher wurde n cookie gesetzt und das hat gepasst...
heute ist das so nicht mehr rechtskonform...
es muss ja aufgeklaert werden fuer was der keks zustaendig ist...
und ob man das auch wirklich will

------------

jquery usw koennte auch von lokal ausgeliefert werden...
aktuell ist aber (noch) viel outgesourct da der 32biter lahmt ;)

Japp. Da ist dir/euch ganz bestimmt kein Vorwurf zu machen. Das muss wohl so sein. :-)

Allerdings ist solch eine Cookie-Information nicht zwangsweise notwendig, das mit dem Anmeldecookie ginge heute noch ganauso wie früher ohne Hinweis. Soweit ich weiß ist es nur bei Werbe- und anderen Tracking-Cookies verpflichtend (wichtig: ich bin jedoch kein Jurist!). Klassische Login-Cookies sind auch ohne Hinweis legal. Dass Google+co. das natürlich anders darstellen und unter den Tisch fallen lassen, dass nur ihre Tracking-Cookies den Hinweis benötigen, ist klar. Die wollen, dass die Seitenbetreiber generell auf Cookies hinweisen, damit sie den Nutzern ihre Cookies unterschieben dürfen und derwegen nichts gegen ihre Produkte und Datensammelei spricht. Ohne Google APIs/Analytics/Adsense/DoubleClick/usw. oder ähnliche Einbindungen kommt man trotz Cookie ohne Hinweis aus. Das soll sich aber nicht publik machen, da das ja durchaus die ein oder andere Meinung bzgl. "externes Nachladen" ändern würde.

(Bzgl. notwendiger Cookies zur Anmeldung ein Zitat aus der EU-Richtline 2009/136/EG, die wohl Grundlage besagter Umstände ist: "Ausnahmen von der Informationspflicht und der Einräumung des Rechts auf Ablehnung sollten auf jene Situationen beschränkt sein, in denen die technische Speicherung oder der Zugriff unverzichtbar sind, um die Nutzung eines vom Teilnehmer oder Nutzer ausdrücklich angeforderten Dienstes zu ermöglichen." - Die Anmeldung bei der WBC wird vom Nutzer ja ausdrücklich angefordert (-> cookie ok), das Tracking durch Google+co. nicht (-> cookie nicht ok), daher kann man da prima unterscheiden. Ist aber auch egal, googleapis wird ja eingebunden, da ist wohl ein Cookiehinweis erforderlich und damit lebt der Nutzer im Netz ja üblicherweise eh sowieso.)

---

Bzgl. jquery: Wie auch immer, egal, das ist heute sowieso üblich - das stört 99% der Nutzer nicht die Bohne, wo was nachgeladen wird. So lang es auch so funktioniert, unterbinde ich das einfach und gut is ;). (Btw: Das einmalige Nachladen einer statischen Datei dürfte kaum stören - entsprechende cache-tags helfen da.)

Auch meine Meinung: ohne eingeblendete Werbung oder anderem Tracking ist die Warnung nicht notwendig. Aber ich glaube nicht, dass Wolfgang uns das glauben wird ;)
Du wirst deinen langen Text umsonst geschrieben haben.

Aber warum hier total dilettantisch JQuery 1.7.1 (2x, einmal http einmal https), 1.9.1, 1.4.1, 1.6.4, 1.7.2, 2.1.4 - also 7x JQuery Downloads auf einer Seite -
so einen Pfusch habe ich mein Leben nicht gesehen!!!

@hspolt

sieht diese seite fertig aus?
steht irgendwo was von optimierungen durchgefuehrt

nein?

was reisst du dann dein maul goschert auf ?!

aktuell rennen die meisten module so wie sie von dragonbyte geschrieben wurden...
und ja... wenn man ein neues modul erstellt nimmt man aktuelle versionen von libaries und keine alte weil man die schon wo anders verwendet hatte
leuchtet dir das nicht ein ?

da kannste schoen sehen welches modul wann urspruenglich erstellt wurde....

mickeysoft kame doch auch nicht auf die idee heute noch .net 1 fuer neue produkte zu verwenden....
nur weil se das irgendwann mal geschrieben haben
selbst auf win10 muss man meist .net 2.x und 3.x nachinstallieren obwohl 10 ja mit .net 4.x daherkommt damit die anwendungen die man so verwenden will laufen...
somit sind dann 2.x 3.x und 4.x am rechner...

aber ich erwarte ja nicht dass man logisch nachdenkt...

hspolt is ja einer der gegen alles was von mit kommt ist ;)

lass ihn doch Wolfgang. Vielleicht bekommt er ja mal den Nobelpreis, weil er VB zur Zusammenarbeit mit ssl/https überredet hat.....

@dees
get tor, use duckduckgo, activate noScript globally, be happy. Doesn't make this page load any faster though, no magic is strong enough for that and the wisdom seems to be lost...

w3c crys for valid html code, for an upgrade to strict somebody might as well build a new cms from scratch. Why it was changed from html5 to xhtml in the first place for this "new" version of vB, only god knows... Then again my html viewer says "somebody" bought an old version of vB...

It's funny how this is in production for longer than I'm here and nobody actually tried, tested or stresstested it obviously... QA must be on vacation in the bermuda triangle.

Zitat:

---

Errors found while checking this document as XHTML 1.0 Transitional!
Result: 453 Errors, 48 warning(s)

---

For some reason I can't imagine that's how vB released it, as their own forum mostly throws the occasional "obsolete html" error because they have html activated in the editor. vB 5.2 with html5 ftw...

P.S. I had to edit this post or it would have been a block of text, don't use the extended editor, it doesn't work...