Wikiup:Benutzeroberflächenadministratoren/Anträge/Archiv/2019
aus Wikipedia, der freien Enzyklopädie
Doc Taxon
Doc Taxon (Diskussion | Beiträge) – L | S | B | M | I | WW
- Kommentar: habe mittlerweile gute js- und css-Kenntnisse und das Benutzerkonto ist mit einem superguten Passwort versehen. Ich brauche das Recht, um auch fremde .js- und css-Seiten bearbeiten zu können, da ich einige Bots ersetzt habe, die auf .js ihrer Benutzerseiten zurückgreifen und die ich ändern können muss, um ein reibungsloses Agieren der Bots weiterhin gewährleisten zu können. Benutzeroberflächen habe ich auch früher schon in anderen Wikis administriert, kenne mich insgesamt also ganz gut aus. Danke, – Doc Taxon • Disk. • Wikiliebe?! • 12:45, 5. Feb. 2019 (CET)
- Recht vergeben --Itti 14:25, 12. Feb. 2019 (CET)
- Archivierung dieses Abschnittes wurde gewünscht von: --Itti 14:25, 12. Feb. 2019 (CET)
xqt
Xqt (Diskussion | Beiträge) – L | S | B | M | I | WW
- Begründung: zur Pflege von Benutzerskripten, wie PDDs markAdmins.js, welches zum Aufgabenbereich der Bürokraten gehört. Von uns Bürokraten hat nur Itti ggw. dieses erweitere Recht. -- @xqt 15:57, 13. Feb. 2019 (CET)
- Recht vergeben --Itti 16:07, 13. Feb. 2019 (CET)
- Archivierung dieses Abschnittes wurde gewünscht von: --Itti 16:07, 13. Feb. 2019 (CET)
Benutzer:Septembermorgen
Septembermorgen (Diskussion | Beiträge) – L | S | B | M | I | WW
- Kommentar: Bitte Rechte verleihe, da sonst MarkAdmins.js nicht bearbeitbar (gehört ja doch auch zu den originären Bürokratenaufgaben, Kandidaturen vollständig abarbeiten zu können. --Septembermorgen (Diskussion) 19:26, 20. Mär. 2019 (CET)
- @Xqt:, @Itti:, @MBq:, da sieht man mal wer diese Seite auf der Beobachtungsliste hat;-) --Septembermorgen (Diskussion) 20:28, 10. Apr. 2019 (CEST)
- Done Viele Grüße --Itti 21:50, 10. Apr. 2019 (CEST)
- @Xqt:, @Itti:, @MBq:, da sieht man mal wer diese Seite auf der Beobachtungsliste hat;-) --Septembermorgen (Diskussion) 20:28, 10. Apr. 2019 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: --Itti 21:51, 10. Apr. 2019 (CEST)
Funkruf
Funkruf (Diskussion | Beiträge) – L | S | B | M | I | WW
- Kommentar: Erbitte ebenfalls die Rechte als Benutzeroberflächenadministrator damit ich durch die Wahl als Bürokrat ebenfalls die Pflege von Benutzerskripten, wie PDDs markAdmins.js durchführen kann. Diese Seite kenne ich schon aus früheren Zeiten, bevor der BOA-Schutz kam. JavaScript kenne ich, zumal ich es auch wegen meinem Monobook verwende. Mein Konto ist mit einem sicheren Passwort und zusätzlicher Zwei-Faktor-Authentifizierung ausgerüstet. Das Konto wird über meinen PC und über mein Notebook verwendet. Funkruf WP:CVU 22:36, 5. Jul. 2019 (CEST)
- Ist in der Tat notwendig und sinnvoll für Bürokraten. --AFBorchert 🍵 23:08, 5. Jul. 2019 (CEST)
- Sorry, aber das ist in dieser Form Murks.
- Funkruf wurde per 2015-05-06 Admin, und dies war anscheinend auch die letzte AK.
- Seinerzeit wurden durch die Community die BOA-Rechte mit verliehen, und das hatte ununterbrochen Bestand, auch wenn zwischenzeitlich technisch nicht freigeschaltet.
- Als „Admin von 2015“ kann ohne irgendwelche Begründung die technische Freischaltung der BOA-Rechte begehrt werden, und müsste in aller Regel auch erteilt werden.
- Der Status als Bürokrat ist derzeit völlig belanglos.
- Es gibt keine Grundlage dafür, dass Bürokraten nur durch Wahl als Bürokrat BOA-Rechte erhielten.
- Das muss derzeit bei jeder Kandidatur als Bürokrat explizit dem Wahlvolk mit zur Abstimmung gestellt werden (sofern noch nicht vorhanden gewesen).
- Bei jeder neuen Wahl oder Wiederwahl als Admin muss derzeit explizit der Community mit angegeben werden, dass auch BOA-Rechte beantragt werden.
- DaB. hatte vor einer Weile per Wiederwahl als Admin kandidiert, ohne explizit anzugeben, dass auch BOA-Rechte erteilt werden sollen. Wäre die Wahl erfolgreich gewesen, hätte das zwar einen erneuten Admin-Status ergeben, jedoch ohne BOA-Rechte.
- Weiterer Teil des Beitrags verlagert nach WD:Bürokraten#Neues Meinungsbild für die Aufgaben der B? --PerfektesChaos 15:03, 15. Jul. 2019 (CEST)
- VG --PerfektesChaos 16:51, 6. Jul. 2019 (CEST)
- Whow, so viele Gedanken zu einem Nichtproblem. --Krd 16:55, 6. Jul. 2019 (CEST)
- PerfektesChaos, mir scheinen diese Gedanken etwas fehlgeleitet. Hauptzweck der Einführung war eine Erhöhung der Sicherheit, nachdem gerade in der englischsprachigen Wikipedia zahlreiche Adminkonten wegen schwacher Passwörter bzw. solchen, die auch anderswo in Nutzung waren, gehackt worden sind. Da der Zugang zu den globalen Benutzeroberflächen-Skripten auch genutzt werden kann, um alle normalen Nutzer anzugreifen, war dies sehr beunruhigend. Die Trennung erfolgte also nicht, weil den normalen Admins ein verantwortungsvoller Umgang damit nicht zugetraut worden ist, sondern weil es keine gute Idee ist, dieses Recht pauschal allen Admins zu verleihen, obwohl viele diese Rechte nie einsetzen. Damit wird das entsprechende Sicherheitsrisiko begrenzt. Prinzipiell können somit diese Rechte jedem Admin zugestanden werden, der diese Rechte tatsächlich benötigt und auch glaubhaft versichern kann, dass der Zugang besonders abgesichert ist (Passwort nirgendwo anders verwendet, Zwei-Faktor-Authentifizierung). Beides wurde von Funkruf oben bestätigt. Am Ende geht es hier immer noch um die Erstellung einer Enzyklopädie und nicht um eine zunehmende Verbürokratisierung als Selbstzweck. Diese Seite ist hier doch ausreichend, da die Vergabe transparent erfolgt und jeder etwas Zeit hat, konkrete Bedenken zu äußern, falls welche vorliegen sollten. Wenn Du meinst, dass die Richtlinien für Bürokraten überarbeitungswürdig sind, dann initiiere doch bitte ein entsprechendes MB, bis dahin sollten wir hier wie gewohnt weiter verfahren. --AFBorchert 🍵 18:15, 6. Jul. 2019 (CEST)
- Wenn ich den länglichen Kommentar von PerfektesChaos richtig verstehe, hat er auch nichts dagegen, dass Funkruf die BOA-Rechte erhält, sondern stört sich an der Begründung "Wahl als Bürokrat". Funkruf könne, so Perfektes Chaos, die Rechte aber als "Admin von 2015" erhalten. Wenn Perfektes Chaos nun, wie er hier schreibt, "explizit per MB" regeln möchte, "was Bürokraten heutzutage eigentlich sollen und dürfen", dann kann er gerne ein solches MB anlegen, aber diese Seite scheint tatsächlich der falsche Ort zu sein, um darüber zu diskutieren. Gestumblindi 18:24, 6. Jul. 2019 (CEST)
- PerfektesChaos, mir scheinen diese Gedanken etwas fehlgeleitet. Hauptzweck der Einführung war eine Erhöhung der Sicherheit, nachdem gerade in der englischsprachigen Wikipedia zahlreiche Adminkonten wegen schwacher Passwörter bzw. solchen, die auch anderswo in Nutzung waren, gehackt worden sind. Da der Zugang zu den globalen Benutzeroberflächen-Skripten auch genutzt werden kann, um alle normalen Nutzer anzugreifen, war dies sehr beunruhigend. Die Trennung erfolgte also nicht, weil den normalen Admins ein verantwortungsvoller Umgang damit nicht zugetraut worden ist, sondern weil es keine gute Idee ist, dieses Recht pauschal allen Admins zu verleihen, obwohl viele diese Rechte nie einsetzen. Damit wird das entsprechende Sicherheitsrisiko begrenzt. Prinzipiell können somit diese Rechte jedem Admin zugestanden werden, der diese Rechte tatsächlich benötigt und auch glaubhaft versichern kann, dass der Zugang besonders abgesichert ist (Passwort nirgendwo anders verwendet, Zwei-Faktor-Authentifizierung). Beides wurde von Funkruf oben bestätigt. Am Ende geht es hier immer noch um die Erstellung einer Enzyklopädie und nicht um eine zunehmende Verbürokratisierung als Selbstzweck. Diese Seite ist hier doch ausreichend, da die Vergabe transparent erfolgt und jeder etwas Zeit hat, konkrete Bedenken zu äußern, falls welche vorliegen sollten. Wenn Du meinst, dass die Richtlinien für Bürokraten überarbeitungswürdig sind, dann initiiere doch bitte ein entsprechendes MB, bis dahin sollten wir hier wie gewohnt weiter verfahren. --AFBorchert 🍵 18:15, 6. Jul. 2019 (CEST)
- Whow, so viele Gedanken zu einem Nichtproblem. --Krd 16:55, 6. Jul. 2019 (CEST)
- Sorry, aber das ist in dieser Form Murks.
„Trennung erfolgte also nicht, weil den normalen Admins ein verantwortungsvoller Umgang damit nicht zugetraut worden ist“
- Das ist leider ein falscher Irrtum.
- Es gibt sehr maßgebliche Stimmen in der WMF, die der Auffassung waren und weiterhin sind, dass die lokalen JS (+CSS) ein erhebliches Sicherheitsrisiko sind und es ein Fehler gewesen war, das mal so eben blauäugig in den frühen Jahren einzurichten.
- Nur ein, zwei, drei Dutzend Wikis haben überhaupt einen oder mehrere lokale BOA.
- Über 900 Wikis haben keine eigenen BOA und müssen ggf. gewünschte Änderungen bereits bei globalen Betreuern beantragen.
- Zurzeit läuft eine Art mehrjähriges Experiment, bei dem die Entwicklung und sicherheitstechnische Verbesserung des projektweiten JS auf Wikis mit lokalen BOA sehr kritisch beäugt und ausgewertet wird.
- Die lokalen BOA sind eine Art Zwischenlösung, weil insbesondere bei den sehr großen und agilen Wikis, hier aber insbesondere der enWP, zunächst nicht genügend Ressourcen an globalen Betreuern vorhanden sind, um deren komplexe Architektur von außen zu managen.
- Wie der Endzustand aussehen wird, ist nicht abzusehen. Wenn es gut läuft, können bei großen Communities mit breiten Kapazitäten und tieferem Know-How die lokalen BOA verbleiben.
- Wenn die Wikis es versemmeln, werden die lokalen BOA nach und nach abgeknipst, und ausschließlich globale BOA dürfen noch projektweite JS-/CSS-Anpassungen bearbeiten, oder aber diese JS-/CSS-Veränderungen werden nach und nach eliminiert.
- Nach den Vorstellungen einiger WMF-Verantwortlicher soll projektweit allen Benutzern aufgenötigtes oder angebotenes JS (+CSS) nur noch durch (globales) freiwilliges oder hauptamtliches Personal verändert werden dürfen, dessen Qualifikation die WMF selbst überwacht.
- In diesem Fall darfst du dann für jede Veränderung an unserem JS/CSS eine Phabricator-Task anlegen, in der du die gewünschte Veränderung begründest, ggf. einen Programmiervorschlag beifügst, und einen Community Consensus nachweist, der belegt, dass diese Veränderung auf breiter Basis von der Community unterstützt wird.
- Dann kannst du gern auch über „zunehmende Verbürokratisierung“ räsonnieren; das wird jedoch nichts nutzen.
- Ob die WMF dann dem in der Phabricator-Task unterbreiteten Wunsch zustimmt oder ihn ablehnt oder keine Kapazitäten hätte, ihn zeitnah umzusetzen, bliebe dann im Einzelfall abzuwarten.
Das Recht „BOA“ ist bewusst von dem Recht „sysop“ abgekoppelt worden.
- Das bedeutet, es kann nach Entscheidung durch die lokale Community auch JS-sicherheitstechnisch versiertes Personal damit ausgestattet werden, ohne dass diese Admin sein müssen, und die ihre sicherheitstechnische Qualifikation darzulegen hätten.
- Zum Anforderungsprofil eines Admin auf einem Wiki gehört es hingegen in keiner Weise, kompetent im Aufspüren und Vermeiden von Sicherheitslecks bei der JavaScript-Programmierung zu sein. Den „sysop“ wurde deshalb im Bereich der gesamten WMF grundsätzlich die Befähigung zur Veränderung an projektweitem JavaScript entzogen.
VG --PerfektesChaos 22:40, 6. Jul. 2019 (CEST)
- Was ich oben beschriebe habe, entspricht ziemlich genau den Gründen, die in phabricator:T190015 und dieser Ausgangsdiskussion genannt worden sind. Dort wird eben auf die Sicherheitsrisiken hingewiesen, dass nicht jeder Admin diese Rechte benötigt und solche, die das Recht benötigen, ihr Konto besser absichern müssen, wobei die Zweifaktor-Authentifizierung explizit genannt wird. Es heißt in dem Phabricator-Ticket auch ausdrücklich: it is made clear that the power to assign Javascript editing capabilities is left with the local communities. Und auch ausdrücklich: current admins [..] could be grandfathered in if they want to. Es gibt keinen Grund in diese naheliegende und nachvollziehbare Sicherheitsüberlegung mehr hineinzuinterpretieren. --AFBorchert 🍵 00:05, 7. Jul. 2019 (CEST)
- Es gibt einen vieljährigen, über etliche Phab-Tasks und Flows und Meta-Seiten verteilten Diskussionsprozess dieser Angelegenheit.
- phab:T71445 2014–2018, ein unmittelbarer Vorläufer, der zur Definition gesonderter, von den sysop abgespaltener Rechte führte.
- phab:T165981 und phab:T171577 – zwei kürzere Betrachtungen aus 2017.
- Typisch ist die Forderung nach Peer review for code – heißt, ein BOA macht eine Veränderung, die jedoch erst (für alle) aktiv wird, nachdem sie von einem anderen in JavaScript-Sicherheitslücken und allgemeinem Fehlverhalten erfahrenen Programmierer erprobt und bestätigt wurde.
- Das langfristig absehbare Bild ist schon so wie von mir skizziert. Was da 2018 als BOA erstmal eingerichtet wurde, ist eine als medium-term solution bezeichnete Zwischenlösung – bis auf Weiteres. Die long term vision ist noch nicht erreicht; heißt, irgendwann kommt da auch noch mehr.
- VG --PerfektesChaos 02:15, 7. Jul. 2019 (CEST)
- Die Sache ist im Fluß, aber wir müssen ja jetzt mit den heutigen Gegebenheiten damit umgehen. Ausgehend von m:Creation of separate user group for editing sitewide CSS/JS#How you can help haben wir als Quasi-Vorgabe: please make sure your wiki has some documentation and election process for the new group past the migration period. Again, this could be as simple as asking newly elected administrators whether they also want to be interface administrators and whether they are familiar with Javascript and basic security practices. In any case, it is recommended to make the bar for interface admins at least as high as for admins (in terms of trust and user behavior), and maybe even higher (see the user group page for more advice. Für diesen Prozess ist diese Seite zuständig, die Rechte werden in Abstimmung unter den Bürokraten vergeben. Die hier vorgebrachte Kritik der Vergabe an den als Bürokrat neugewählten Funkruf ist eher grundsätzlicher als persönlicher Natur und ich würde das gerne auch als solches trennen.
- Zum Grundsätzlichen: Ich stimme zu, dass die Vergabe der Rechte deutlich restikiv zu sein hat. Wir haben gegenwärtig 20 BOAs[1], en-wiki dagegen lediglich 12, interessanterweise 1 Bot und lediglich 1 Bürokrat.[2]. Da sind wir hier im Vergleich vielleicht zu freigiebig. Mir persönlich ist der Automatismus, OS -> BOA zum Beispiel zu weitgehend. Die Foundation verlangt inzwischen obligatorisch 2FA für die Rechtevergabe, dies sollten wir hier ebenfalls voraussetzen und ggf. auch nachfordern. BOAR für Nicht-Admins haben wir Bürokraten nicht ohne Grund bislang abgelehnt, weil eben ein gewisses Grundvertrauen der Community dokumentiert sein sollte, wie bei einer Admin- oder Bürokratenwahl mit noch größeren Hürden zum Ausdruck kommt. Für Nicht-Admins wäre dann wohl ein entsprechendes Votum erforderlich, aber ein Durchwinken wird es nicht geben. Für die Nutzung der Rechte ist in der Tat der Peer-Review-Prozess noch unzureichend implementiert. Das wäre aber auch Aufgabe der mit der technischen Seite befassten Benutzer, dies einzufordern und ggf. die Rechte wieder entziehen zu lassen. Schließlich kann ich der WMF nicht in den Kopf kucken. Wenn man dort zum Ergebnis kommt, die Restriktionen höher zu schrauben, dann ist das einerseits Sache des Betreibers, andererseits vielleicht auch unnötige Gängelung; am Ende wird sicherlich ein gangbarer Weg herauskommen, denn nur ein Wiki im Read-Only-Modus ist einigermaßen sicher aber ganz sicher unbrauchbar. Zusammenfassend: Ich bin gerne dafür, die Rechtevergabe so restriktiv wie nötig zu regeln oder überhaupt Regeln zu schaffen, die über oben zitierten Satz hinausgehen. Andererseits billige ich der Gemeinschaft der Bürokraten hinreichendes Gespür zu, die Rechtevergabe in sinnvollem Ermessen, im Einklang mit den bislang vorgegebenen Empfehlungen und in dem Geist der zu Umsetzung dieser Rolle geführt hat, durchzuführen.
- Zum aktuellen Fall: Funkruf hat dargelegt, dass er die BOAR in Ausübung seiner Bürokratenfunktion benötigt, hat ein starkes Passwort und 2FA versichert und ist gerade mit sehr großer Zustimmung zum Bürokraten gewählt worden. Die formalen Kriterien sind erfüllt, persönliche Gründe stehen der Rechtevergabe nicht entgegen. Ich sehe also nicht, warum wir als Bürokraten hier abweichend entscheiden sollten.
- @xqt 11:04, 14. Jul. 2019 (CEST)
- Die Sache ist im Fluß, aber wir müssen ja jetzt mit den heutigen Gegebenheiten damit umgehen. Ausgehend von m:Creation of separate user group for editing sitewide CSS/JS#How you can help haben wir als Quasi-Vorgabe: please make sure your wiki has some documentation and election process for the new group past the migration period. Again, this could be as simple as asking newly elected administrators whether they also want to be interface administrators and whether they are familiar with Javascript and basic security practices. In any case, it is recommended to make the bar for interface admins at least as high as for admins (in terms of trust and user behavior), and maybe even higher (see the user group page for more advice. Für diesen Prozess ist diese Seite zuständig, die Rechte werden in Abstimmung unter den Bürokraten vergeben. Die hier vorgebrachte Kritik der Vergabe an den als Bürokrat neugewählten Funkruf ist eher grundsätzlicher als persönlicher Natur und ich würde das gerne auch als solches trennen.
- Es gibt einen vieljährigen, über etliche Phab-Tasks und Flows und Meta-Seiten verteilten Diskussionsprozess dieser Angelegenheit.
- Archivierung dieses Abschnittes wurde gewünscht von: Die Rechte werden vergeben. Funkruf erfüllt alle Anforderungen, die für Admins gelten, welche die BOA-Rechte beantragen. Ob irgendwelche Strukturen oder Aufgabengebiete angepasst werden sollten, ist in diesem Fall zunächst nicht wichtig, darüber darf man sich jedoch gerne Gedanken machen. Gruß --Itti 12:25, 14. Jul. 2019 (CEST)
- Weitere Disk verlagert nach WD:Bürokraten#Neues_Meinungsbild_für_die_Aufgaben_der_B? --MBq Disk 14:39, 15. Jul. 2019 (CEST)