Уикипедия:Предложения за администратори/JSS 9

от Уикипедия, свободната енциклопедия
Направо към навигацията Направо към търсенето
Архив Това е архив на старо гласуване.
Моля не редактирайте съдържанието на страницата!

JSS 9 (беседа • приноси)

  • Начало на гласуването: 13:00, 26 октомври 2018 (UTC) / Край на гласуването: 13:00, 9 ноември 2018 (UTC)
  • Гласуването се провежда по мнозинство „В“, 6 или повече гласа „за“, формиращи поне 3/4 от общия брой валидни гласове.

Гласуването е приключило. JSS 9 е одобрен за администратор и интерфейсен администратор със 7 валидни гласа „за“, 1 валиден глас „против“ (87.5% „за“ при изискуеми 75%).

TL;DR: Моля да се дадат права на администратор и на интерфейсен администратор на бота JSS 9, за да може да извършва одобрените във Фабрикатор Фабрикатор промени по глобалните JavaScript и CSS страници.

Както повечето от вас вероятно знаят, администраторите вече нямат възможност да редактират JS и CSS кода, който не само управлява изгледа на страниците, но най-вече прави възможни множеството удобства – допълнителната лента с инструменти и бутони за въвеждане, падащите менюта с шаблони и елементи от статията, бързото патрулиране и бързата отмяна, и въобще всяка една от джаджите – които ползваме. Право да редактират тези страници вече има само специална група потребители, наречени „интерфейсни администратори“. Повече за причините може да прочетете в горната дискусия, но накратко: CSS и най-вече JS кодът може да бъде използван за извършване на зловредни действия, включително до пълно завладяване на компютъра на редактори, без те дори да разберат това. Макар избраните за администратори почти сигурно да не биха злоупотребили, винаги съществува рискът техните собствени сметки да бъдат хакнати.

В дискусията се оформиха две допълващи се виждания:

  1. права на интерфейсен администратор да се предоставят временно, колкото да се свърши някаква конкретна задача;
  2. по възможност промените по JS/CSS да бъдат обсъждани от повече администратори.

Втората точка е всъщност популярна в разработческите среди практика за т.нар. „code review“ (преглед, рецензиране на кода), която е доказала своята полза и ефективност. Съществуват специални софтуерни системи за улесняване на този процес, една от които е именно въпросният Фабрикатор (но той може и много повече: в него „можете да координирате със своите колеги работата си в Уикипедия и останалите български проекти на Фондация Уикимедия, [като имате възможност] да създавате задачи, събития в календари, гласувания, „въпроси и отговори“, блогове, микропейстове, да качвате файлове, да работите съвместно по ботове и друг програмен код и още много други неща.“) Концепцията е следната:

  1. предложенията за промени се слагат във Фабрикатор;
  2. след процеса на постъпково подобряване, предложението се утвърждава;
  3. ботът JSS 9 го прехвърля на съответната JS или CSS страница в Уикипедия.

Фабрикатор Ето пример за конкретно предложение за подравняване на таблици с над 9 колони. Освен с Фабрикатор JS и CSS, същото може да се прави и с друг код в Уикипедия: например Фабрикатор Lua модулите и Фабрикатор филтрите за спам и Фабрикатор заглавия.



Но нали сам казваш, че е опасно и нежелателно да се дават постоянни права...?
Това е вярно и самият аз не бих искал подобни права за своята собствена сметка. В същото време:
  1. JSS 9 сметката ще се използва единствено на един сървър, използван практически само за подобни скриптове. Това много силно ограничава преките вектори за атака, в сравнение с варианта, при който сметката се ползва на потребителски компютър през браузър. В последния случай бисквитката с токена може да бъде както атакувана при посещения с браузъра на различни сайтове, така и през вероятно многото работещ софтуер върху компютъра.
  2. За логин на бота ще се използва OAuth токен, който ще бъде валиден само за IP адреса на сървъра. Това още повече намалява възможностите за атака, тъй като паролата въобще няма да бъде достъпна през който и да е компютър, а токенът, дори да бъде откраднат, ще бъде почти напълно безполезен (спуфинг на IP адреса теоретично е възможен, но на практика доста труден).
  3. Ако предложението бъде одобрено, сметката ще бъде също защитена с двуфакторна аутентикация, което означава, че дори ако паролата за нея по някакъв начин би изтекла, с нея няма да може да се влезе в сметката, без да се притежава и едно физическо устройство, което е постоянно с мен (двуфакторната аутентикация не може да се активира за обикновени потребители, затова говоря за нея условно и в бъдеще време).
  4. За разлика от останалите редактори, ботът ще прави много малко и съвсем специфични редакции. Ако сметката все пак бъде открадната, би било относително по-лесно да се забележи девиантно поведение. Освен това, при съмнения няма да има нужда от колебания и опити за комуникация („абе, ти ли си това?“), а направо може да се блокира.
  5. Воденият от бота дневник, макар и донякъде дублиращ наличната другаде информация, Попълваните от бота резюмета на редакциите също е са известна бариера за потенциални злодеи. Ако не искат редакциите им веднага да станат съмнителни, ще трябва да си направят труда да актуализират и този дневник създават и тези резюмета. Естествено, понеже кодът на бота е публичен, това не е безкрайно трудно, но все пак е допълнително усилие, а и човек трябва въобще да се сети за него.
  6. Не на последно място, макар и банално, без постоянни права за бота, цялата тази конструкция просто не би била възможна. :)


Хубаво, сметката е защитена. А какво гарантира, че ботът няма сам да направи глупости?
Фабрикатор Кодът на бота е публично достъпен и може също да бъде преглеждан за проблеми. Нещо повече, много бих се радвал, ако и други хора помагат за него. :) В някакъв момент също определени колеги може да получат достъп и до самата система, на която той работи, така че да не бъде всичката поддръжка съсредоточена единствено в мен (демек, да не бъда „single point of failure“, ако утре нещо или някой ме откъсне от Уикипедия :).


Но нали вече има PSS 9 – защо е нужен още един бот администратор?
Заради точка 4 по-горе: PSS 9 прави много редакции, сред които евентуална зловредна би могла по-лесно да се прикрие. А JSS 9 може и въобще да не получава бот-флаг, т.е. редакциите му ще бъдат постоянно контролирани.
NB: Фабрикатор Кодът на PSS 9 също е качен във Фабрикатор, но е достъпен само за регистрирани потребители, които познавам от Уикипедия.


Не ми харесва този Фабрикатор – защо трябва да го налагаме?
Фабрикатор е само допълнително удобство за тези, които биха намерили в него нещо полезно. Той обаче по никакъв начин не ограничава редактирането на JS/CSS и останалия код да става, както и досега, директно в Уикипедия. Точно това беше една от причините да се забавя с подготовката на бота, тъй като трябваше да бъде премислен алгоритъмът при възникване на конфликти. В крайна сметка, ако се случи да бъде направена промяна едновременно във Фабрикатор и в Уикипедия, предимство ще има именно редакцията в Уикипедия. С други думи, за тези които не се интересуват от каквото и да е дотук, видима промяна в работата в Уикипедия няма да има.


И как така в него се влиза със сметката от Уикипедия...?
Използва се OAuth, утвърдена технология за делегиран контрол на достъпа. Когато се логвате във Фабрикатор, реално се случва следното:
  1. Фабрикатор ви препраща към Метауики.
  2. Ако не сте логнати в Уикипедия, се логвате – това е логване в сървърите на Фондацията, които проверяват паролата ви.
  3. Метауики ви пита (само първия път) дали разрешавате да бъде потвърдено вашето потребителско име пред Фабрикатор.
  4. Ако дадете разрешението си, Фабрикатор получава потвърждение от сървърите на Фондацията, че вие сте именно потребителят Х.
Фабрикатор не получава никаква друга информация за вас. Паролата ви остава известна единствено на сървърите на Фондацията (реално, дори там тя практически сигурно се съхранява само като криптографски хеш, а не директно). Съзнателно беше направен избор дори имейл адресът на сметката да не бъде получаван – с цел да се минимизират рисковете от изтичане на лична информация. Неудобството е, че при регистрация се изисква сами да въведете някакъв имейл адрес, но не е нужно да бъде валиден – може например да въведете kflkhogrnlsrnlbn@wikimedia.bg. Ако въведете свой валиден адрес обаче, ще можете да получавате уведомления и по пощата, а не само в сайта.


Всичко това е ужасно сложно!!! Нужно ли е въобще?!
PSS 9 реално беше доста по-сложен и амбициозен (за мен) проект, и макар това понякога да ме учудва, явно се оказа не съвсем безполезен. Впрочем, идеята за Фабрикатор възникна именно тогава, като се надявах (и все още се надявам), че това ще позволи на повече хора да помагат за разработването му – особено на втората му, принципно нова версия, с която планирам да се заема идната година. А може би ще има идеи и за съвсем нови ботове.



За

  1. Symbol support vote.svg За --Спасимир (беседа) 13:24, 26 октомври 2018 (UTC)
  2. Symbol support vote.svg За --Nikki070 (беседа) 13:46, 26 октомври 2018 (UTC)
  3. Symbol support vote.svg За --Спас Колев (беседа) 07:34, 27 октомври 2018 (UTC)
  4. Symbol support vote.svg За --Quickfingers (беседа) 07:41, 27 октомври 2018 (UTC)
  5. Symbol support vote.svg За --Поздрави, Петър Петров 16:25, 27 октомври 2018 (UTC)
  6. Symbol support vote.svg За --Vodnokon4e (беседа) 02:25, 28 октомври 2018 (UTC)
  7. Symbol support vote.svg ЗаБорислав 16:08, 28 октомври 2018 (UTC)
  8. {{за}} —--Sim (беседа) 08:49, 10 ноември 2018 (UTC)
    След срока за подаване на гласове. — Luchesar • Б/П 11:03, 10 ноември 2018 (UTC)

Против

  1. Symbol oppose vote.svg Против Имайки предвид, че редакторите последните 9 години са почти константни като брой, а обема работа, която трябва да се свърши постоянно нараства, една такава процедура, която увеличава десетки пъти времето, което трябва да се инвестира в тривиални промени по CSS и JS кода, няма как да е от особен полза. Прецедентът направен от нас с PSS 9, беше във връзка с екстремното вандалство по статии и спести много време на администратори. Тази процедура, на върха на която ще бъде друг административен акаунт ще губи време на администратори, особено при тривиалните редакции и ще доведе до значително закъснение при прилагането на промени. Това е и причината да взема решение повече да не се занимавам с CSS/JS код в Уикипедия. Тази процедура вече ми изгуби време да подавам заявка за интерфейсен администратор (без да знам, че на базата на мнение на един редактор вече е взето решение правата да са за определен период и без да правя никакви промени по CSS/JS кода), както и да пиша всичко това. Трябва да се цени времето на опитните редактори, а не да се губи. --Стан (беседа) 14:09, 26 октомври 2018 (UTC)
Мисля, че трябва да разделим проблема на три относително независими един от друг въпроса:
  1. Дали използвани за всекидневно редактиране сметки да получават безсрочни права на интерфейсен администратор.
  2. Дали промени по JS/CSS кода да се правят по лично усмотрение или предварително да се обсъждат и с други редактори.
  3. Ако има предложения, за които е поискано обсъждане, как точно то да бъде технически осъществявано.
JSS 9 отговоря единствено на третия въпрос: ако някой редактор направи предложение, както например съм направил тук, да има удобна възможност то да бъде обсъдено. Поне принципен интерес към подобна възможност досега са изразявали Боби и Петър – естествено, не знам дали все още имат такъв. Но важното е, че тази възможност нито прави обсъждането задължително за всеки редактор (въпрос №2), нито, и още по-малко, ограничава други редактори да получават права (въпрос №1). Ключовата дума тук е именно възможност. Написал съм го, но ще повторя: най-многото време и сок от мозък ми отне именно нуждата ботът да се съобразява с това, че JS/CSS кодът ще продължава да бъде редактиран и без въпросната „процедура“. И не мисля, че е редно да бъда „наказван“ за мнение, което съм изказал. Не само, че в случая решението касае не само мен, но просто подобни неща е по-добре да се обсъждат.
Само обаче ще спомена защо се надявам тая възможност да не бъде отказвана: малко по-рано днес лично се убедих, колко е хубаво да мислят повече глави (леко неприятно, но полезно е също даването на сметка, че съвсем не съм толкова умен и знаещ, колкото ми се иска). А в случая дори не става дума за JS, а за далеч по-безобидните шаблони, които обаче пак засягат особено много хора.
В крайна сметка, „счастье для всех, даром, и пусть никто не уйдет обиженным.“ И мир да има. :-)
— Luchesar • Б/П 16:57, 26 октомври 2018 (UTC)
Конкретен пример: Имаме Специални:LintErrors/obsolete-tag, където в МедияУики:Gadget-Advisor.js е използван HTML таг, който не се поддържа в HTML5 и е редно да се замени с подходящ. Такъв например е kbd, който в случая визуално е един и същ (едни и същи стилове са приложени) т.е. това е тривиална промяна, която не влияе на външния вид. Преди можех това да го направя за 10 секунди. Без да съм злоупотребявал при редактирането на CSS/JS, при положение, че имам и дву-компонентно удостоверяване (по-голяма сигурност), сега нямам това право - защото някой предложи такъв статут да се дава след заявка и за определен период от време. Аз разбира се нямам намерение по 5 пъти на месец да пускам заявки и да чакам мнения, коментари и същинското даване на права, защото за това време мога да свърша 10 пъти повече работа. Би ли ми обяснил, стъпка по стъпка какво трябва да направя за да направя същата промяна и колко време ще ми отнеме сега (след „оптимизацията“)? Ако промяната е голяма или някой не е съгласен, винаги може да се дискутира и да се стигне до по-добро решение, какъвто пример си дал по-горе, но защо е необходимо да се усложнява процедурата при тривиални промени. Ако искам да коригирам правописна грешка в коментар на JS-код сигурно пак заявка трябва да пусна, да ме одобрят няколко редактора, да се съобщи на бюрократ за да ми даде права. Трябва да се мисли как да ни се пести време, а не да влизаме в задължителни процедури за незначителни неща. За това съм против и този бот и цялата процедура, свързана с него. Така значително се ограничават редакторите, които биха искали да допринесат и се удължава срока на прилагане на промени. Вместо да се възползваме от т.н. интерфейсен администратор и да дадем това право на не-администратори, които биха допринасяли за подобряване на CSS/JS кода, като по-този начин направим това по-отворен процес, ние го затваряме и усложняваме процедурата дори за администратори, които без да са злоупотребявали са им премахнати права, при положение, че изрично са ги заявили т.е. имат нужда от тях. Вместо да изпишем вежди, избождаме очи. Нововъведенията не трябва да се използват за да ни се губи излишно времето, а са предназначени точно за обратното. За това в Специални:LintErrors почистихме над 800 000 грешки за няколко месеца, а останаха само тези, които изискват „интерфейсен администратор“ + грешките в PSS 9, които също няма как да оправя, понеже бота-администратор го препокрива. Понеже стана твърде дълго, бих желал да получа поне отговор на въпроса по-горе за времето което ще ми отнеме операция, която преди би ми отнела 10 секунди. --Стан (беседа) 18:03, 26 октомври 2018 (UTC)
Стан, аз самият съм уморен и не по-малко ядосан. И на мен ми се налага през няколко месеца да се моля на стюардите за най-обикновени администраторски права, и то не в един, а в два проекта. А със стюардите дори не се познаваме – веднъж един почти ни обвини, че сме искали с измама да завземем проект. Съвсем не искам да мисля ако там потрябват права за JS/CSS. Но стюардите имат причини да са консервативни и ги разбирам.
Навремето дискусията замря, но нека наистина изясним някакво разумно компромисно решение, защото факт е, че сигурността и удобството са винаги в противоречие. Казвам да изясним, защото вече няколко пъти писах, че тоя бот с разните описани процедури въобще не е задължителен за използване, но явно това не е достатъчно да успокои притесненията, които ти имаш. Между другото, понеже питаш, поправката на кода е дори по-бърза през git, отколкото през напоследък тромавия интерфейс тук – за наистина тривиални промени би било глупаво да се прави рецензиране – но да кажем, че човек може въобще да не иска да използва или да се учи да използва git.
И така, съвсем сухо и ясно:
  1. Ти искаш да имаш възможност да редактираш JS/CSS кода по същия начин, по който можеше да се редактира преди да ни бъдат наложени (на всички) промените с правата.
  2. Безпокоиш се – и аз разбирам причините за безпокойството ти – че този бот може реално да наложи някаква тромава, времеотнемаща и мъчителна процедура.
Ето какво мога да ти отговоря:
  1. Продължавам да не одобрявам безсрочното даване на права, особено масово. Ботът също ми е трън в очите, но вече писах как е защитен – и е един. Колкото повече редактори биха имали такива права в даден момент, толкова по-голям е рискът. Честно казано, аз самият дори съм по-спокоен като нямам такива права: който има желание, да се опитва да атакува бота – аз поне не съм интересна мишена.
  2. Разумният компромис за мен вероятно е това, което беше направил Спас: даване на права за достатъчно дълъг срок, така че да не се губи време в бюрократични процедури, но не и за много по-дълго, отколкото би било нужно. Изкушаващо е да се мисли, че щом в една къща никога не е имало пожар, значи няма нужда от пожарогасител, но тези неща стават веднъж. В моята област обичат лафа „better to be safe than to be sorry“.
  3. В крайна сметка обаче, ако наистина твърдо искаш да имаш безсрочни права, не бих правил драми. Навремето само напомних какво бяхме говорили, но нито бих могъл да заставя бюрократите да вземат едно или друго решение – избрани са да преценяват със собствените си глави – нито, ако можех, бих го направил. Ако не можем да намираме общ език, значи имаме много по-сериозни проблеми от сигурността.
  4. Не търгувам гласове. От тоя бот нема да стана богат (даже обратно). Влагам времето си в него с надеждата да бъде полезен. Но знам, че и ти правиш същото, и точно заради това не бих искал да се чувстваш неразбран, а още по-малко пък пренебрегнат. Всеки от нас е потънал в своите работи и понякога може би наистина забравяме за останалите и за техните борби, но истината е че повечето също можем да се разберем взаимно, точно защото минаваме през същите трудности. В тая връзка, признателен съм ти, че разчупи тягостното мълчание в гласуването в Уикиновини, където и без друго не ми беше кеф въобще да се захващам.
  5. Накратко, Стан, съжалявам, че може да съм дал повод да мислиш, че не ме е грижа. Явно имаме своите различия, но докато намираме общ език това е дори хубаво. Ако ботът все пак бъде одобрен, може някой ден дори ти самият да не искаш да излезеш от Фабрикатора. :) А може пък останалите сами да го заебем напълно. Хората, а не технологиите, сме най-важни – в това съм сигурен, че сме на едно мнение.
    — Luchesar • Б/П 23:20, 26 октомври 2018 (UTC)
Хората също казват „If it ain't broke, don't fix it“. Не казвам, че параноята е безполезна, но може да се прави разлика между проект с 1500 администратори и такъв с 5. --Спас Колев (беседа) 07:34, 27 октомври 2018 (UTC)
Харесвам! — Luchesar • Б/П 10:12, 27 октомври 2018 (UTC)
В точка 1. и 2. от „И така, съвсем сухо и ясно“ съвсем правилно си разбрал проблема и опасенията ми. Наложените промени, бяха просто да се премахнат права, които ние да преценим как да си дадем т.е. реално можем дори да запазим старата ситуация (което разбира се не е разумно, имайки предвид, че ни се дават по-добри възможности). Ние решаваме дали нещо ще е наложено или не. Никой отгоре не ни спуска ограничения. Ние сами си ги правим и си затрудняваме работата. Ето как са решили същият този въпрос в английската Уикипедия: en:Wikipedia:Interface administrators. Със съвсем леки сътресения свързани със заявка до бюрократите, след определен период, ако няма възражения дават безсрочно права, освен ако не са заявени временни такива. Премахват се при 2+ месеца без редакции (като цяло) или 6+ месеца без редакции свързани с правата на интерфейсния администратор. Простичко и без излишни процедури. Знае се кои са интерфейсните администратори и кой може да помогне за бързо решаване на проблем или правене на промени. Отделно се стимулират да са активни. Имат си и отделна страница за разговори, от която ние може би нямаме нужда. Нямам нищо против да има и бот, който да си работи независимо (прозрачно), и с него да работи който си иска, без да пречи на останалите (интерфейсни) администратори да си свършат работата бързо и лесно, но текущият е тясно свързан с определена излишна процедура, която мисля, че не е в интерес на проекта и за това гласувам против. --Стан (беседа) 23:17, 27 октомври 2018 (UTC)

Коментари

  • Symbol comment vote.svg Коментар: Съжалявам, че някой е останал с впечатление, че Luchesar прави нещо, което не се подкрепя. Лично аз заставам зад всяко негово действие, непрестанно възхищавайки се на енергията, която влага. Редакциите на статиите без проблем могат да бъдат смели, защото те променят текст, четящ се от хора със собствена преценка. За програми, които моментално биват изпълнявани безпрекословно на милиони компютри, важи точно обратното. „Малка промяна“ е разбираемо само за хора, за някои, и то субективно. Виждал съм строшен build след промяна на един ред коментар. Виждал съм достатъчно неща, за да имам категорично професионално мнение по въпроса. По-горе Luchesar вече аргументира нуждата изчерпателно, аз нямам какво да добавя. Подкрепям възможността за несанкционирани промени само, ако преди това те надлеждно са тествани на тестова система. И поради липсата на милиони морски свинчета с компютри по света, това не е възможно, поне за момента. Ако към подхода бъдат посочени конкретни недостатъци, то те могат да бъдат обсъдени конкретно. Дотук посоченото „по-бавно ми е“ всъщност е търсен ефект. След настоящето гласуване би станало „по-сигурен съм, че правя нещо добро и желано“. --Поздрави, Петър Петров 16:54, 27 октомври 2018 (UTC)