Benutzer Diskussion:LeonWeber/WikiCharts

aus Wikipedia, der freien Enzyklopädie

[Bearbeiten] Manipulierbarkeit (Faktor)

Guten Tag Herr Weber,

die Idee einer Statistik für die deutschsprachige Wikipedia wurde schon häufig geäußert - schön, dass eine Realisierung, die auch die Serverresourcen berücksichtigt, nun geschaffen wurde.

Ich möchte jedoch darauf hinweisen, dass die derzeitige Umsetzung eine sehr einfache Manipulation des Systems gestattet. So reicht ein direkter Aufruf der Datei

  http://pgcount.wikimedia.de/index.png?title=TITEL&factor=FAKTOR&wiki=dewiki

mit beliebigem TITEL und FAKTOR, um die Statistik zu verfälschen. Ein einmaliger Aufruf mit z.B. einem FAKTOR = 6000 bringt einen Artikel derzeit von Platz > 1000 auf ca. 570.

Sicherlich ist die oben geschilderte Möglichkeit der Manipulation bereits bekannt und man darf auf einen fairen Umgang der Nutzer damit hoffen. Eventuell lassen sich jedoch weitergehende Schutzmaßnahmen finden (Filterung von Faktoren ungleich 600, Überprüfung des Refers, Überprüfung, ob es den Artikel überhaupt gibt, ...).

Mit freundlichen Grüßen

A. Gerdes

Es gibt bereits solche Filter. --DaB. 20:28, 31. Jul 2006 (CEST)

Es ist gut, dass solche Filter bereits eingebunden wurden, doch werden diese anscheinend nicht bei jeder stündlichen Aktualisierung auf den Datensatz angewandt. Somit sind zumindest zeitweise manipulierte Ergebnisse online. - A. Gerdes

Soweit ich weiß sind sie in Betrieb. Auf so niedrigen Plätzen wie 570 kann auch sehr schnell eine Änderung passieren. Der Platz 750 hat mom. die Güte von 400 Edits. Das bedeutet, das ein einziger Aufruf (der mom. 600 Pluspunkte hat) reicht um an Platz 570 vorbeizuziehen. Wir (und besonders leon) machen uns aber natürlich Gedanken das Manipulieren so schwer wie möglich zu machen. Anderseits dient das Ganze aber eh mehr der Information und nix Wichtiges hängt davon ab :). --DaB. 21:13, 31. Jul 2006 (CEST)

Die Filter werden anscheinend auch nicht täglich angewandt. Im Übrigen ist es möglich, nicht existente Beiträge mit beliebigem Titel einzustellen. Beispiel: "pgcount" auf derzeit Platz 825, angelegt mit einem Faktor = 6000. Aufgrund der leichten Manipulierbarkeit sollte zumindest ein Hinweis darauf auf der Statistik-Seite nicht fehlen, da immerhin eine Wissenschaftlichkeit mit Fehlerintervallangabe dargestellt wird. Zieht man eine Parallele zu Google Trends, dessen Daten sowohl in Online- als auch Print-Publikationen ein Echo fand, so sollte die Bedeutung der Veröffentlichung von Wikipedia-Statistiken nicht unterschätzt werden. - A. Gerdes

Momentan werden nur Zugriffe mit dreistelligen Faktoren berücksichtigt. Ich habe mit einem einzeiligen Skript trotzdem einmal testweise einen Artikel auf Platz zwei hochgedrückt. Ich mache mir schon Gedanken, wie ich das Manipulieren erschweren kann, wie DaB schon sagte. --Leon ¿! 17:31, 21. Aug 2006 (CEST)

[Bearbeiten] Manipulierbarkeit und Verbesserungsvorschläge

Auch wenn ich mich hiermit als Trottel "oute" und es für mein hackerhaftes Verhalten wohl mal wieder kräftig Anschiss hageln wird, möchte ich euch mitteilen, dass ich leider die WikiCharts mehr oder weniger etwas verunstaltet habe. Dort finden sich nun Seiten in der Rangliste, die nur zum vergleichenden Testen gedacht waren (in als.wp) und rausgehören, aber unter anderem durch den Cache-Effekt weit nach oben geraten sind (und eben eigentlich separat gelistet sein müssten). Die WikiCharts sind momentan leider noch viel zu manipulierbar; meine Abhilfevorschläge:

1. Bitte unbedingt die Auswertung nach Wikis (Wikipedias, Wiktionarys, etc.) trennen, also nicht nur &wiki=dewiki sondern auch &wiki=alswiki, &wiki=dewiktionary, &wiki=enwikibooks, usw. als unterscheidendes Merkmal auswerten bzw. diesen Parameter überhaupt erst mal in die Auswertung miteinbeziehen. Sodann die verschiedenen Wikiseiten wie mit dem Namensraumfilter (rechts) auf verschiedenen Seiten ausspucken lassen (dann verschwinden meine Fauxpas-Misch-Rangeinträge automatisch ("Gsw/..." und "als:...")).

   done. war echt dumm, dass ich es noch nicht hatte... --Leon ¿! 17:35, 21. Aug 2006 (CEST)

2. Bitte in der Scheinbild-URL (bzw. der folgenden Auswertung) Faktoren unter 100 (also [1-9][0-9]?[0-9]? im PHP-Skript) erlauben. Man könnte nun zuerst meinen, das würde den Server überlasten, aber der Serverüberlastungsschutz steckt im JavaScript (Math.random()*Faktor == x), nicht im PHP. Diese Änderung ist für kleine Wikis sehr wichtig. Für enWikipedia würde ich auch einen Faktor über 999 ermöglichen! Aber eben nur für enWikipedia (wegen Missbrauchsgefahr zur Verfälschung).

   kommt, sobald ich es auf andere wikis portiert hab. --Leon ¿! 17:36, 21. Aug 2006 (CEST)

3. Die statistische Rangzuteilung sollte zudem überdacht werden! Sie sollte täglich oder gar stündlich völlig neu berechnet werden. Man muss dann halt stündliche/tägliche Schnappschüsse machen, um dann mal monatliche Auswertungen erstellen zu können. Eine über viele Tage hinweg verlaufende akkumulierende Verwertung der Ergebnisse mit dem Startergebnis als absolutem Anfangsmaximum ist nämlich nicht im Sinne des Erfinders (Wachstum der Besucherzahl verfälscht dann die Auswertung, wenn neue und alte Artikel "verglichen" werden). Momentan ist/war es aber so: Am Tag 31 gab es bei (Test-)Seite X sagen wir 2500 Aufrufe. In der Statistik steht am Tag 31 dann, dass es 2500 Aufrufe pro Tag gibt. Soweit so gut. Am Tag 32 wird die (Test-)Seite X kaum mehr bzw. in meinem Fall gar nicht mehr aufgerufen. Die Zahl der Aufrufe pro Tag wird am Tag 32 aber mit immernoch ca. 2422 angegeben (2500 Aufrufe * 31 Tage / 32 Tage = 2422 Aufrufe)! Sollte sich das Ergebnis nicht eigentlich halbieren (also 2500 Aufrufe / 2 Tage Laufzeit = 1250 Aufrufe pro Tag)? Habe im Stochastik-Unterricht zwar leider nicht sehr gut aufgepasst, aber mir erscheint das mit der Gesamttageverrechnung etwas seltsam. Bemerkung zum Schluss: Die Seite Benutzer:LeonWeber habe nicht ich auf Platz 2 gedrückt, das war wohl jemand der zwar manipuliert, aber eben nicht helfen will (naja, vielleicht ist's "stumme Hilfe").
4. Da bei den WikiCharts ja die Seitenbetrachtungen gezählt werden und nicht die Anzahl der individuellen Besucher, muss im JavaScript der Browsercache von Besuchern umgangen werden, um jeden Seitenaufruf eines Besuchers zu zählen (ohne in der Statistik dabei die gleiche Seiten mehrmals betrachten zu haben). Dazu wäre ein Parameter "id" gut ("http://...&id="+wgArticleId;)! wgArticleId ist eine JS-Variable unserer Entwickler, welche die Nummer jeder angelegten Seite ausspuckt. Mit dieser Variablen wird sich die Besucherzahl in der Auswertung drastisch erhöhen (um über 50%, je nachdem wieviele Seiten jeder Besucher halt betrachtet und wie stark der Browsercache-Effekt insgesamt bisher wirksam war). Eventuell muss halt der Faktor hochgesetzt werden, aber nur so wird z.B. die zweite Seite, die ein Besucher liest, überhaupt gezählt; momentan bringt das die Statistik durcheinander ((fast/meist) nur Erstseitenaufrufe werden gezählt; das Ganze ist im Top-100-Bereich wohl statistisch/ranglistentechnisch nicht eklatant, aber die Zahlen stimmen dann halt nicht wirklich und im Top-1000-Bereich änderte sich wohl einiges). (hatte hier mein abgeändertes Skript im Kopf)
5. Da ca. 5% (eventuell mehr) der Besucher kein JavaScript (an) haben, werden diese bei der Auswertung nicht berücksichtigt (statistisch/ranglistentechnisch nicht schlimm, aber die Zahlen stimmen dann halt nicht wirklich). Um alle Besucher zu erwischen (und evtl. JavaScript-Aussetzer und -Probleme zu vermeiden) könnte man die bit-sparende Zeile <img src="http://pgcount.wikimedia.de/index.png?title={{FULLPAGENAMEE}}&factor=600&wiki=dewiki&stamp={{CURRENTTIMESTAMP}}" /> z.B. bei MediaWiki:Lastmodified einbauen (eventuell mit style="display:none"). Das &stamp= ist übrigens das HTML-Pendant zum obigen &id=. Hinweis: Wenn in MediaWiki:Lastmodified, dann werden allerdings keine Spezial:-Seiten gezählt, wohingegen bei jedem Versionsvergleich einer Seite mit der aktuellen Version der Aufruf sehr wohl gezählt wird, was wiederum für eine gewisse Verfälschung der Ergebnisse sorgen würde. [nachträgliche Ergänzung: Dieser Vorschlag wäre nur was für kleine Wikis mit relativ wenigen Seitenaufrufen pro Sekunde/Minute]
6. Falls ihr übrigens über weitere Filter nachdenken solltet, eine Bemerkung vorne weg: Bitte nicht die vom Browser übermittelten Referrer in die Filterung miteinbeziehen (obwohl natürlich sehr verleitend), da es bei allen brauchbaren Browsern (z.B. Firefox und Opera) möglich ist den Referrer nicht übertragen zu lassen. All diese Besuche würden nicht gezählt werden. Wenn dann lieber document.URL verwenden (aber im SQL/PHP-Skript, da das JS-Skript ja vom Vandalen (also solchen wie mir, wobei mein Fehltritt nicht wirklich beabsichtig war, und ja auch einige Erkenntnisse dabei herauskamen) angepasst werden kann wie er/sie es gerne möchte.

Mit den besten Absichten, Melancholie 11:23, 17. Aug 2006 (CEST)

Da Leon in Urlaub ist, versuche ich das mal zu beantworten.

1. Auswertung für einzelen Wikis ist natürlich geplant. Die aktuelle Version funktioniert nur für dewiki. Etwas Geduld bitte.
2. Der Faktor im JavaScript muss immer der selbe sein wie der der im Parameter steht. Faktoren unter 100 können für kleine Wikis sinnvoll sein, ja. Wird dann gegebenenfalls eingebaut.
3. Eine "absolute" Rangzuordnung ist natürlich nicht sinnvoll - geplant sind monatliche Snapschots. Kleinere Zeitrahmen sind nicht möglich: da es sich um eine Stichprobenerhebung handelt, dauert es eine weile, bis selbst für die "top 100" ausreichend Stichproben vorliegen um mit einiger Sicherheit eine aussage treffen zu können. Nach 30 Tagen sind wir jetzt bei einem Fehler von etwa +/- 10% in den top 10, das ist langsam vertretbar. Nach nur einem Tag läge die Fehlerquote nach nahe bei 90%.
4. In der URL des Pseudo-Bildes steht der Titel des besuchten Seite mit drin - das ist genauso gut wie die Artikel-ID. Der Cache wäre nur dann ein Problem, wenn der sebe Benutzer zwei mal hintereinander die selbe Seite aufruft, und beide male zufällig der Zähler ausgelöst wird. Selbst wenn der Titel nicht mit in der URL stünde, wäre es sehr unwahrscheinlich, dass der Cache Probleme macht: das würde ja nur passieren, wenn zweimal hintereinander die Zufallsbedingung wahr wird (bei zwei Seitenaufrufen ist die Wahrscheinlichkeit 1/(750*750) = 0.00018%).

   Hoppla, hatte meine als.wp-Version im Kopf (Zählung der Gesamtseitenaufrufe). Der Titel ist in der URL natürlich völlig ausreichend! --Melancholie 15:37, 17. Aug 2006 (CEST)

5. Der Zähler-Aufruf muß per JavaScript erfolgen, da sonst bei jedem Seitenaufruf eine Anfrage an den Toolserver gehen würde. Das sind für dewiki bis zu ca 1000 pro Sekunde. Das verkraftet er nicht. Das "Zufallsfiltern" muß also im Browser geschehen.

   Hoppla, hatte an dieser Stelle nicht die vielbesuchte de.WP im Kopf, da wäre das natürlich tödlich, ja. --Melancholie 15:37, 17. Aug 2006 (CEST)

6. Der Zähler-Aufruf kommt immer vom Browser des Benutzers, und kann damit auch immer gefälscht sein (und es wird in der tat dacument.URL verwendet - die steht aber nur im Browser zur Verfügung. Woher soll der Toolserver das wissen?). Das ließe sich nur umgehen, wenn auf den Wikimedia Servern selbst gezählt würde (undzwar nicht in MediaWiki, sondern in den Squid-Proxies). Das wiederum dürfte bei 12- bis 16tausend Anfragen pro Sekunde zu massiven Problemen führen. Es wurde mal über eine Lösung mit UDP-Packets nachgedacht, das ist aber Vaporware.

Ich hoffe, ich konnte etwas klarheit schaffen. Ich werde mal gucken ob ich eine kleine Warnung auf die Seite baue, dass dei Werte nicht so ernst genommen werden sollten. -- D. Dÿsentrieb ⇌ 13:29, 17. Aug 2006 (CEST)

Ich möchte noch hinzufügen, dass es bereits Überlegungen gab, die Manipulationsfähigkeit zu verkleinern. Momentan ist Leon jedoch im Urlaub, könnt ihm doch mal die Auszeit. Wenn es Leute gibt, die meinen, die wären "ein echt krasser Hacker" wenn sie den Chart manipulieren, bitte sehr. Das ist so einfach, wie einem Baby den Schnuller klauen. Leon selbst hatte vor der Veröffendlichung seine Benutzerseite auf Platz 2 hochgerankt, die Idee ist also nicht gerade neu...

Der Chart ist eine nette Idee und ich finde ihn toll. Aber er ist nicht so wichtig für unser Projekt, dass sich eine Manipulation lohnt :). --DaB. 15:21, 17. Aug 2006 (CEST)

@Duesentrieb: Der dortige Hinweis gefällt mir, danke! @DaB.: Ich habe mich nicht als "ein echt krasser Hacker" bezeichnet, sondern habe in diesem Zusammenhang lediglich von "hackerhaftem Verhalten" geschrieben. --- MfG, Melancholie 15:37, 17. Aug 2006 (CEST)

Ich meinte sicher nicht dich :). --DaB. 22:46, 18. Aug 2006 (CEST)

1. Die Steuung ließe sich bei gleicher Hardwareauslastung reduzieren, wenn für jeden Artikel ein eigener Faktor festgelegt werden könnte und dieser aus den Wikicharts des Vormonats bestimmt würde. Somit würden oft aufgerufene Artikel einen hohen Faktor bekommen, andere einen niedrigen. Ich weiß allerdings nicht, ob das umsetzbar ist.
2. Es könnte sich die spätere Auswertung über Monate, Wochen oder Tage vereinfachen wenn in der Datenbank nicht die Summe der Zugriffe stehen würde sondern jeder Zugriff mit Datum einzeln. Die Aufsummierung würde dann bei dem Aufruf der Statistik über SQL erfolgen. (Noch so ein Vorschlag.) Kolossos 20:02, 21. Aug 2006 (CEST)

[Bearbeiten] Zeitschrift

Hi, in der Zeitschrift www.tomorrow.de (11/2006, S46/47) ist eine Doppelseite mit dem Titel "Top 10 der meistgesuchten Wikipedia-Begriffe" zwischen 1.9. und 14.9. Das kann doch nur durch dein Tool kommen? -- Cherubino 06:53, 16. Okt. 2006 (CEST)