Wikipedia Diskussion:Benutzeroberflächenadministratoren

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Das aktuelle Archiv befindet sich unter Archiv/1.

Rechteabgabe

Wir haben die meisten BOAs aller Wikipedia-Projekte – und demnächst wohl einen zusätzlichen –, aber keine Regelung, wie die Rechte wieder abgegeben werden. Einige Sprachversionen, darunter fast alle großen Projekte, sind da weiter und wir sollten, denke ich, auch eine Regelung finden, bevor sie uns womöglich von der Foundation aufgenötigt wird (zumal wir uns eh schon nicht ganz an die Regeln auf Meta halten). Neben der freiwilligen Rückgabe der BOA-Rechte oder der Rückgabe der Admin-Rechte werden bei den Kollegen in en:wp, it:wp oder pl:wp u.a. Missbrauch, ein SG-Entscheid oder eine bestimmte Aktivität genannt (in en:wp ab 2 Monate komplette Inaktivität bzw. 6 Monate Nicht-Nutzung der BOA-Rechte, in pl:wp ab 6 Monate Inaktivität, in es:wp ab 1 Jahr nach Nicht-Nutzung der BOA-Rechte). In da:wp hingegen gelten lediglich die Regeln wie für Admin-Rechte. NNW 11:39, 3. Apr. 2020 (CEST)

Ich gehöre zwar nicht dazu, senfe aber trotzdem mal:

• Bei Missbrauch und allgemeiner Inaktivität sind auch die normalen futsch.
• Es müssten nur immer bei allen Aktionen konkret, präzise und zweifelsfrei die BOA mit dazugenannt werden, damit keine unklaren Zustände entstehen.
• Heißt: Allgemeine Admin-Inaktivität, Missbrauch und SG müssten präzise zusätzlich die BOA benennen.
• In der gerade laufenden AK sind im ersten Satz die BOA mitgenannt und verlinkt, so ist das okay.
• Schlecht sind Wiederwahlen eines Admin+BOA, bei denen nur als Admin wieder kandidiert wird; in diesem Fall wird die Community nicht auf Wiedererteilung der BOA befragt und damit sind nach einer solchen WW die BOA eigentlich futsch und bedürften einer separaten Kandidatur.

Es gibt eine Sicherheitsproblematik, die ich aber mangels globaler Angriffe zurzeit nicht als relevant einschätze: Wer längere Zeit inaktiv war, könnte unbemerkt gekapert werden. Ähnliche Hintergründe hat unter anderen auch die Inaktivitätsregelung bei normalen Admins. Darauf gründen sich die en- und pl-Regelungen, die dann nach zwei Monaten eine erneute Kandidatur erfordern würden????

• Wenn irgendwann Angriffe interessanter würden, könnte man bei totaler Nichtaktivität über x Monate die BOA sicherheitshalber einfrieren, also nicht entziehen, die dann bei formlosem glaubhaftem Wiedereinstieg wieder freigegeben werden können, es sei denn, die Admin-Rechte wären insgesamt futsch und BOA würde sich auf denselben Wahlvorgang begründen.

Heißt: Ich sehe wenig aktiven Regelungsbedarf, finde aber die umseitigen Regeln zu unpräzise und lückenhaft interpretationsfähig dargestellt und sehe keine Vorkehrungen für vorstellbare Situationen explizit vorgegeben.

• Hat man Monate vorher ohne konkreten Anlass eine sinnvolle allgemeine Regelung getroffen, dann kann man die irgendwann neutral anwenden. Wartet man ab, bis eine absehbare Situation eintritt, und fängt dann bezogen auf den aktuellen Fall mit Entscheidungen an, dann wird das sofort zur Lex XY, und das ist ja nur so gemacht worden weil XY gut Freund mit YZ ist, und es verbleibt auf ewig ein Geschmäckle.

VG --PerfektesChaos 14:43, 3. Apr. 2020 (CEST)

Genau darum geht: eine Regelung zu finden, bevor ein Kind in den Brunnen gefallen ist, daher auch unabhängig von der aktuellen Situation. Dass die Rechte bei Abgabe der Admin-Rechte auch abgegeben werden, ist vermutlich klar. (Zumindest solange, wie wir keine Nicht-Admins als BOAs akzeptieren, was bislang aber auch nicht geklärt ist.) Dito Missbrauch und vermutlich auch SG-Entscheid. Die Abgabe der OS-Rechte führt ebenfalls zur Abgabe der BOA-Rechte. Eine Abgabe bei totaler Inaktivität scheint mir am einfachsten zu überprüfen, wobei es natürlich wenig bringt, wenn jemand jahrelang die Rechte ungenutzt hat. Vielleicht reicht hier eine Selbstverpflichtung, die Rechtevergabe regelmäßig selbst zu hinterfragen. Wer die Rechte verliert oder freiwillig abgibt, könnte ja die Rechte einfach zurückerhalten, falls keine schwerwiegenden Gründe dagegen sprechen. Das zu entscheiden liegt allein bei uns. NNW 10:56, 4. Apr. 2020 (CEST)

Zwei-Faktor-Authentifizierung

Zumindest gemäß m:Interface administrators sind Benutzeroberflächenadministratoren zur Verwendung der Zwei-Faktor-Authentifizierung verpflichtet. Trifft dies auch auf die deutschsprachige Wikipedia zu? --Zabe (Diskussion) 00:39, 25. Apr. 2021 (CEST)

Müsste es; deswegen ist auch der neuste Plan der WMF, dass nur noch Stewards die Rechte vergeben können sollen. --MF-W 19:20, 12. Mai 2021 (CEST)

Nein, das ist eine Soll-Bestimmung, die setzen wir nicht durch. Könnten wir auch gar nicht, da wir nicht sehen können, ob jemand 2FA nutzt oder nicht. —MBq ^Disk 21:03, 12. Mai 2021 (CEST)

Verhältnis zu Wikipedia:Superschutz

Ich habe trotz intensiver Lektüre nicht herausfinden können, was es mit den Benutzeroberflächenadministratoren eigentlich auf sich hat. Was ich nur verstanden habe: mit diesem Mechanismus können bestimmte Wiki-Seiten so geschützt werden, dass sie auch von Admins nicht mehr bearbeitet werden können. Das kann nur eine andere, kleinere Nutzergruppe. Aber dasselbe gab es doch unter dem Namen Superschutz schon einmal. Sind die BOA nun die Nachfolger des Superschutzes? -- Indoor-Fanatiker (Diskussion) 06:37, 15. Mai 2021 (CEST)

@Indoor-Fanatiker Nein, das ist nicht vergleichbar. Beim Superschutz hatte die WMF die Kontrolle der Bearbeitung einiger zentralen Konfigurationsseiten übernommen, weil es einen Wheel-War von WMF-Personal mit lokalen Admins gab. Mit der Benutzeroberflächenadministratoren hat die Community weiterhin die volle Kontrolle über alle Konfigurationsseiten. Durch die Aufteilung der Rechte zur Bearbeitung zentraler Konfigurationsseiten, wie eben der MediaWiki:Common.js, MediaWiki:Common.css u.a. wird das Risiko minimiert, dass Schadecode durch technisch nicht so versierte Admins in die zentralen Konfigurationsseiten eingeschleust wird. --Raymond ^Disk. 09:53, 15. Mai 2021 (CEST)

Okay, vielen Dank für die Antwort. Wenn ich das richtig verstanden habe, sind die BOA eine eigene, neu geschaffene Benutzergruppe, die von den Rechten (technischen Möglichkeiten) her gesehen irgendwo zwischen Admin und Bürokrat rangiert. -- Indoor-Fanatiker (Diskussion) 14:16, 15. Mai 2021 (CEST)

Nein. Sie sind Techniker, die spezielle Rechte haben, um technische Lösungen herbeizuführen. Dazu muss derjenige weder Admin, noch Bürokrat sein. Admins und Bürokraten haben dieses Recht im übrigen nicht automatisch, können es jedoch auf Wunsch bekommen. Gruß --Itti 14:18, 15. Mai 2021 (CEST)

Die Ereignisse von 2014 haben schon eine Rolle gespielt; das ist kein reines Sicherheitsfeature. WMF war unglücklich mit dem Shitstorm, aber auch damit, dass nach ihrem Rückzieher wieder alle Admins vollen Zugang zum Mediawiki-Namensraum hatten, und sie haben eine bessere, verträglichere Lösung gesucht [1]. Dass es nicht nur um Verteidigung gegen externe Hacker ging, sondern auch um internes Misstrauen gegenüber gelegentlich aufsässigen Freiwilligen, scheint mir kein Geheimnis zu sein. Die Reaktionen bei der Einführung erklären sich daher. - Rückblickend würde ich die BOA als akzeptablen Kompromiß einschätzen. Immerhin wird die neue Benutzergruppe von den Communities selbstverantwortlich besetzt und kontrolliert. —MBq ^Disk 18:58, 15. Mai 2021 (CEST)

Na ja: phab:T282624. NNW 19:19, 15. Mai 2021 (CEST)

mark Admins anpassen?

Auf Meta wurde nach dieser Diskussion die Seite m:MediaWiki:Gadget-markAdmins-data.js nach m:MediaWiki:Gadget-markAdmins-data.json verschoben und angepasst [2]. In der Diskussion wurde empfohlen, das in anderen Projekten ähnlich zu handhaben. Ohne inhaltliche Bewertung (davon verstehe ich zu wenig) poste ich das hier zur Info, dann könnt ihr BOAs überlegen, ob sowas auch in deWP sinnvoll ist. --Johannnes89 (Diskussion) 15:11, 13. Mär. 2022 (CET)

Wir verwenden hier eine wesentlich ältere Version dieses Skripts, sodass diese Änderung für uns nicht relevant ist. Vielleicht wäre es aber an der Zeit, markAdmins mal auf den aktuellen Stand zu bringen. Gruß, -- hgzh 23:01, 14. Mär. 2022 (CET)

Sehe keinen Bedarf mark Admins anzupassen. Die "Pöstchenwirtschaft" ist eh schon groß genug. Wen es interessiert und ggf. betrifft der weiß die Information zu finden. BTW, solange nicht mal das Meinungsbild durch ist würde man sich kaum selbst einen Gefallen damit tun. --Ｔｏｍ (Diskussion) 13:18, 7. Sep. 2022 (CEST)

Moin @Ｔｏｍ, von welchem MB sprichst du? Ich sehe aktuell nichts in Vorbereitung, was mit markAdmins zu tun haben könnte, oder übersehe ich was? Und was hat ein Tool, das erweiterte Rechte bei Benutzernamen visuell hervorhebt, mit Pöstchenwirtschaft zu tun? --Johannnes89 (Diskussion) 21:36, 7. Sep. 2022 (CEST)

AWB/Huggle Login bei 2FA

Bei aktivierter 2FA ist es nur über Umwege möglich sich bei externen Tools, wie AWB oder Huggle einzuloggen. Meine Nachfrage im Rahmen des Reparatursommers ergab nun, dass mit einem Botpasswort die Verwendung mit dem Hauptaccount möglich ist:

• Wer eine zwei-Faktor-Authentifizierung verwendet, kann sich über diese Seite ein Bot-Passwort generieren lassen. Weitere Infos finden sich auf der En-Wiki-Hilfeseite.

Ich notiere das auch mal hier, da es sicher einige BOAs mit betrifft. --Wnme (Diskussion) 14:40, 14. Sep. 2023 (CEST)

Inhalt von Scripten

Es scheint, einige Interface admins haben Code hinzugefügt, der Javascript aus dem Benutzernamensraum lädt.

Ist dies zulässig oder sollten allfällige Skript bei phab: gemeldet werden? --Enhancing999 (Diskussion) 16:32, 16. Nov. 2023 (CET)

Worum geht es? Du sprichst, wie häufig, in Rätseln. -- hgzh 17:49, 16. Nov. 2023 (CET)

Gewisse Scripts im Interface laden Seiten wie z.B. User:Hgzh/improveOurWebsite.js ohne dass sich der User dessen bewusst ist. (nicht signierter Beitrag von Enhancing999 (Diskussion | Beiträge) 19:13, 16. Nov. 2023 (CET))

und die wären...? -- hgzh 19:59, 16. Nov. 2023 (CET)

Die Frage ist, ob es zulässig ist oder nicht dem Sicherheitskonzept der Wikimedia Foundation für js zuwiderläuft (das Beispiel oben und der Username ist zufällig gewählt). Wenn nein, dann sollte die Liste wohl nicht hier publiziert werden sondern direkt in phab:. --Enhancing999 (Diskussion) 20:10, 16. Nov. 2023 (CET)

Ich vermute, es ist die hier schon relativ deutlich offengelegte Lösung gemeint.

• Kann man auch gern noch einen expliziten Satz in die Doku schreiben.
• Ich hatte es seinerzeit den BOA freigestellt, die von mir gepflegte zentrale Fassung einzubinden, oder eine Kopie zu übernehmen, durchzulesen und auf Sicherheitsprobleme zu prüfen, und dann in unserem Gadget-Namensraum jeweils zu aktualisieren.

Es dürfte die einzige Stelle im Bereich der deWP sein, die mit dem abschnittseröffnenden dunklen Gerüchtegemunkel („Es scheint“) in Verbindung zu bringen wäre. Fällt mir zumindest grad keine andere ein.

Generell gilt bei einer Einbindung aus Wiki-Seiten (im Unterschied zu externen Servern), dass sie unter voller Kontrolle der WMF stehen, die Versionsgeschichten nicht manipulierbar und jede bösartige Aktion nachvollziehbar sind, und die sehr agile und kompetente BOA-Truppe der enWP bei einem qualifizierten Hinweis auf regelverletzende Codes diesen unverzüglich wirksam deaktivieren würde.

VG --PerfektesChaos 10:20, 17. Nov. 2023 (CET)

Die Frage ist ob es zulässig ist oder nicht. --Enhancing999 (Diskussion) 23:49, 17. Nov. 2023 (CET)

Mir wäre keine Richtlinie bekannt, die das verbietet (betrifft auch MediaWiki:gadget-markAdmins.js). -- hgzh 18:13, 19. Nov. 2023 (CET)

Es scheint der Logik der Usergroup zu widersprechen. Denkbar, dass die Skripte älter sind als die Usergroup. --Enhancing999 (Diskussion) 13:45, 20. Nov. 2023 (CET)

Ist so, aber wie gesagt: wenn es eine Richtlinie gäbe, die einen solchen Import verbietet, wäre sie bekannt gemacht worden. Die Ausgangsfrage ist damit geklärt. -- hgzh 14:22, 20. Nov. 2023 (CET)

Hab mir die Erläuterungen angesehen, die bei der Einführung der Benutzergruppe gegeben wurde. Diese sind auch für Laien verständlich. Es scheint relativ klar, dass das Laden von Code aus nicht entsprechend geschützten Orten nicht vorgesehen ist, bzw. verhindert werden soll. --Enhancing999 (Diskussion) 11:56, 21. Nov. 2023 (CET)

Die „Benutzergruppe“ hat rein überhaupt nullkommanullgarnix damit zu tun, wie sicherheitstechnisch die konkrete Programmierung bestimmter Gadgets realisiert wird.

• Deine Behauptung, du wollest angeblich „Erläuterungen angesehen“ haben, die eine Einbindung aus einem Wiki-BNR verbieten würden, müsstest du jetzt mal konkret und präzise mit Angabe der textlichen Formulierung und der Fundstelle belegen.
• Bis du diesen Nachweis erbracht hast, gehe ich davon aus, dass du dies spontan frei erfunden hast.
• Die „Benutzergruppe“ hat etwas zu tun mit dem, was im Gadgets-Namensraum hinterlegt wird, hat Zugriff auf den Code, und ist der Community gegenüber dafür verantwortlich, dass keine realen Sicherheitsrisiken bestehen.

Nach einigem Nachdenken komme ich nunmehr auf drei Fälle, bei denen wir JS aus einem Wiki-BNR langjährig unmittelbar einbinden:

• wikEd@Cacycle
• markAdmins@PDD
• editMenusPREGO@PerfektesChaos

Unter Sicherheitsaspekten sind daran nachstehende Forderungen zu binden:

• Alle Quellcodes (direkt und indirekt) müssen mit ihrer Versionsgeschichte in einem Wiki unter Kontrolle der WMF hinterlegt sein. Auch nach einer allfälligen Seitenlöschung wäre jemals wirksamer Code zumindest durch die BOA des Wiki oder durch Stewards und WMF-Personal einsehbar und könnte auch öffentlich zur weltweiten Inspektion an passendem Ort wiederhergestellt werden.
• Das Benutzerkonto muss frei von jedem Verdacht sein, Schadcode (insbesondere irreversibler Abfluss von Privacy-Infos) in den Ressourcen zu verstecken. Programmierfehler sind kein „Schadcode“, sofern sie erkennbar unabsichtlich waren und nach Benachrichtigung schnellstmöglich eliminiert werden.
• Das Benutzerkonto muss allgemein einen guten Leumund betreffend robuster und fehlerminimierender Implementierung haben.
• Die Dokumentationen müssen für Software-Fachleute einen Pfad zu den wirksamen Quellcodes anbieten.

Die Einbindung von Ressourcen außerhalb des lokalen Gadget-Namensraums ist letztlich unvermeidlich.

• Basis-Software und global nutzbare Features werden global an einem Ort bereitgestellt und zentral gepflegt.
• Dies in jeder Version lokal zu kopieren ist zum einen ein übermäßiger Wartungsaufwand; falls in einem Code starre URL hinterlegt wären, müsste dann auch noch in jeder aktuellen Code-Version jede entsprechende URL umgeschrieben werden.
• Derartige Basis-Software liegt nicht nur in Gadget-Namensräumen, sondern ggf. auch in BNR, und ist dort nur dem jeweiligen Benutzerkonto sowie den lokalen BOA und globalem Personal zugänglich.
• Nebenbei verweist Benutzer:PerfektesChaos/js/editMenusPREGO schon seit 2018 auf die Möglichkeit der Hinterlegung einer Kopie im lokalen Gadget-Namensraum, wovon bislang aber niemand Gebrauch gemacht hatte.

VG --PerfektesChaos 12:46, 21. Nov. 2023 (CET)