維貓報第7期

這是本期《維貓報》的全文，您可以在此查看簡報。

中華人民共和國再次阻止基金會加入WIPO

2021年10月7日，世界知識產權組織（World Intellectual Property Organization，WIPO）第62屆會議上，中華人民共和國指控維基百科違反「一中原則」，並暗示維基媒體基金會透過台灣維基媒體協會涉及政治問題，散布虛假信息為由，反對接納維基媒體基金會成為WIPO觀察員。這是該國第二次成為唯一一個反對WMF成為WIPO觀察員的國家。

WMF在隨後發出的聲明中表示，他們2022年仍會提出申請，但他們成功通過的前提是中華人民共和國不再阻止。世界知識產權組織以共識制度運行，只要有一個國家反對，申請也不會成功。在10月14日的公聽會上，瑪吉·丹尼斯回答了相關問題。她認為，與WIPO觀察員的位子相比，WMTW更為重要，但這並不意味着WMF不在乎WIPO。

根據美國之音的報道，User:Walter Grassroot 在QQ群中以「【喜訊·求聞】」為引子報告了此事。

基金會行動後續報道

2021年10月14日，維基媒體基金會社群修復與持續發展（CR&S）團隊舉行了一場交流會（一般稱作「公聽會」），副主席瑪吉·丹尼斯主持了本次會議。其中回答了多個與中維基金會行動有關的問題。瑪姬表示，調查的重點並不是要排除有問題的用戶和中華人民共和國政府有關聯的可能，而重點是他們對維基媒體計劃的其他用戶的行為。或問，基金會如何確保其他想控制中文維基百科的團體不藉機將維基百科的內容帶偏到另一個方向。瑪吉回答說，這種團體的存在這一點上並不使她意外，一個維基媒體計劃的社群內會存在不同觀點，這是計劃本身設計使然。她希望中文社群成員會覺得安全，協助監視相關問題的發展。她說：「我的目標是我們可以在不需要動用封禁的情況之前就提供協助，取而代之的是我們或許可以幫助提出新的流程，新的方法。」

9月14日，User:維基百科最忠誠的反對者（簡稱WMLO）提出了「移除WMC於站內所有相關鏈接、網址」的動議。截至9月22日，共收到了46張有效票，其中36票(＋)支持，10票(－)反對。他擬定「決議」，請求行政員確認其有效性。行政員Jimmy Xu表示：「『決議』沒有討論過就憑空出現，且範圍遠超動議。怎麼可能這樣結案。」於是WMLO開啟了第二輪投票，投票期為11月1日00:00至11月14日23:59，通過門檻為25張有效票、20票支持且支持率過半，投票者資格參照人事任免投票資格。在獲得11票(＋)支持、10票(－)反對、9票(＝)中立和3票(≠)不中立不支持不反對後，11月12日16:20，User:12З4567以「有效性爭議」為由中止投票，之後投票幾無人問津。以下是第二輪投票的表決內容：

表決內容

1. 基於基金會公文報告及元維基方針指引要求「不得為全域封鎖者代爲宣傳」等條文，在未證實Walter Grassroot、Techyan、尤里的1994、遊魂、城市酸儒文人挖坑、ArthurLau1997等維基全域封鎖用戶被WMC徹底罷權/驅逐前:
2. 移除並禁止加入WMC首頁及其子頁面以外的任何WMC內鏈及站外鏈接（例外情況及具體定義見下）。
   1. 站外鏈接包括：包括求聞、求聞百科等WMC關聯網站。
   2. 移除WMC任何形式的社交媒體之鏈接及其界面，如：由WMC聲稱管理的維基百科、維基百科 (新)、維基百科 (2018)、維基百科 (2020)以及是次事件的維基媒體計劃編輯部則應在確認上述用戶被確認驅逐之前將其移除。至於[資] 維基百科和上海維基百科均非WMC直接管轄之群組，可不移除。
   3. 唯其首頁、子頁面中的被動聯絡方式（如郵箱等）可不移除。
   4. WMC相關的內部連結（包括但不限於鏈接到Wikipedia:中國大陸維基人用戶組以及對應的元維基頁面）：如果頁面的主題直接和WMC相關（包括但不限於WMC舉辦的聚會、編輯松、直接和WMC有關的事件和相關討論頁、{{中華人民共和國境內維基媒體運動地方自治體}}），不應移除，仍然活躍的頁面應有{{Global ban affiliates}}聲明；其他可用戶可選擇是否移除，如果不移除則目標頁面應有{{Global ban affiliates}}聲明（不包括求聞的往期存檔）。
3. 移除並禁止在維基首頁、公告顯現任何WMC及其相關鏈接；
   1. 涉及討論公告等站內事宜例外。
   2. 關於在全域封鎖用戶在尚未被WMC確認被驅逐之前提下，WMC申請舉辦編輯松之類活動是否為本站允許，基金會QA回應表示此應由社群決定。關於編輯松的問題將不在本次移除鏈接案的涵括之內；編輯松之問題應另開議題探討。
4. 以任何方式試圖繞過上述禁止令，如：以原成員以人數優勢、轉移其他用戶組在內的任何方式，試圖「成立」WMC現行規則並接納全域封鎖用戶之組織；或以短網址方式宣傳WMC以繞過禁制令；上述行爲皆應視作違反本案規例及基金會公告條文，管理員可視作wikipedia:擾亂或游戲予以站內警告、封禁等處理。
5. 上述鏈接相關事宜，應由管理員以「主題禁止」將上述WMC全域封禁用戶提至編輯禁止公告，直至WMC確認驅逐或重組管理層。
6. 本案宜存檔或部分存檔至WMC討論頁。
7. 在已證實WMC驅逐並罷免上述全域封禁者之時，關於重新恢復其相關鏈接、網址之議案宜擇日重啓。

9月14日，被除權的文言文維基百科臨時管理員兼臨時界面管理員WAN233在本地申請復職，獲得5票支持。10月17日，WAN233在元維基申請復任，但被監管員擱置。11月16日，監管員通過申請，恢復了WAN233原有權限，到期時間不變。

被全域禁制的前管理員Techyan曾向媒體表示將建立中國大陸版本的維基百科，該平台將代表北京觀點及接受中華人民共和國政府審查，它將會使用中文維基百科的全部內容。「人們會有一個更好的平台來撰寫百科全書的條目。」他說。。該百科目前似乎已上線，名曰「求聞百科」，但只有首頁開放給未註冊用戶。求聞百科採用 CC BY-SA 4.0 協議，意味着它可以導入維基百科條目，而維基百科不能反向操作。

WIPO拒絕基金會成為其觀察員之後，Walter Grassroot 在QQ群中透露，WMC「通過傳媒等多渠道，向我駐聯合國日內瓦大使團提交了情況文件」。此外，知情者透露，WMC也有在做自己的調查，並搜集到了一些「有趣的信息」。

管理人員制度改革

2021年9月13日20:07(UTC)，User:1233就發起了「基金會行動的後續本地社群治理改善方案」的討論，認為應當改革現有機制以應對現有的社群問題。討論中出現了不同的改革方案，例如進行秘密投票、投票使用選舉人票方案、解任案由臨時仲裁員裁決等。此後，社群對管理人員制度的改革進行的全面討論。

2021年，中文維基百科未選出一名管理員，但有15名管理員離任。最近一位通過RfA的管理員是2020年12月31日上任的KirkLU，再往前一位是2019年9月21日上任、已被除權的瑞麗江的河水。2019年至2021年的三年間，社群選出管理員現在任的僅有三人。

安全投票

基金會聲明指出，基金會行動中被全域禁制的用戶涉及在維基媒體平台內外實行騷擾、拉票、人肉搜索等行為，且有編者因投票遭遇來自站外群組的威脅、甚至受到人身傷害。而安全投票（SecurePoll）機制可以在投票結束前隱藏支持率、投票用戶等信息進行不記名投票，有用戶認為其利於阻止拉票和人身威脅。

此方案在基金會行動當日就由1233提出，同年10月5日，User:BlackShadowG重提本案，並獲得多數贊同。11月，社群決定舉行一次使用SecurePoll的投票，以決定是否在管理人員選舉中使用SecurePoll，同時希望解決社群對SecurePoll投票的方式的疑問。

該投票的投票期為12月11日零時至25日零時(UTC)，只限12月1日或之前已擁有延伸確認用戶或管理員權限的用戶且投票首日並未被封禁（不包括部分封鎖）的用戶參加。

12月31日，行政員Jimmy Xu公布投票結果：

本次投票共收到830張有效票，結果如下：

	同意	反對	中立	同意-反對	同意票占比
您是否同意在未來一場管理員選舉使用SecurePoll？	559	73	198	486	88.45%
您是否同意使用SecurePoll的投票應當每年固定舉行兩次？（僅意見收集，不具實際效力）	373	121	336	252	75.51%
您是否支持維基娘成為管理員？（僅為測試，不具實際效力）	356	167	307	189	68.07%

以上，複查本次投票之JWong及在下。--Jimmy Xu 2021年12月31日 (五) 01:04 (UTC)

之後，社群在互助客棧方針版討論適用於安全投票的管理員選舉暫行規定，目前未有結果。

上任

2021年10月8日，Eric Liu（User:Ericliu1912）提出應進行管理人員選舉制度改革，指出「不改，新管理員就難產」，並提出了三項討論重點：

1. 人事任免投票資格門檻過低；
2. 參與者提問過多，候選人難以負荷；
3. 當選門檻過高。

10月13日，Eric Liu 針對二、三兩點提出了修改方案：

• 每人最多可提問二題，並允許就提問開展相關討論，禁止以多重問題或「小題」形式繞過限制。
• 通過門檻由80%下調至75%，而支持率在70%至75%之間者，由行政裁定是否通過。

目前該方案仍在討論中。

10月18日，User:Tazkeung獨立提出了調整人事任免投票資格的提案。在接下來兩個月的時間裡，不同用戶提出了十餘種不同的方案。方案中重點在收緊高編輯數用戶的投票權，要求他們要更加活躍才有任免資格；此外有人提出不計沙盒編輯數，也有關於避免新用戶迅速獲得投票權的提案。但未有一種方案能達成共識。目前該討論仍在進行中。

站務要求

這是一個與基金會行動無關聯的提案。2021年10月8日，BureibuNeko說他最近查看管理員列表，發現一些管理員只編輯而不活躍於站務。他認為這些管理員保留着權限，卻「不用權為社群做出只有管理員能做到的貢獻」，故希望「增加對管理員站務的要求，減少『摸魚管理』」。

由此社群衍生了數個提案，一般的格式是「最近一段時間所做的管理員操作少於若干次」。這些提案基本被援引Wikipedia:管理員不是什麼#不是職員而否決。

Eric Liu 指出，社群多次討論過管理員的不活躍標準，而「這些討論之中正反方的論點，與今日幾無差別，彷彿劇團每隔一段時間重複演出同樣的戲碼，或是直接從舊討論複製貼上一般」。

行政員AT提出了一個新的觀點：「[若]管理員長期沒有管理操作，[他]未必能夠及時掌握如何用權。方針指引每年多有變化，[...]如果是幾年都沒有管理操作的話，請問誰能擔保這些長期缺乏操作的管理員有足夠的能力去基於現行規定去解決問題？」而且，若有用戶求助於長期不活躍的管理員，很大可能得不到回應，或得到錯誤的指導。

行政員JWong（User:Wong128hk）則認為，社群信任管理員，「應該是建立於其處事方式[，]相信其會妥善運用權限。例如某人久未從事相關站務，那就會去複習一下方針指引[。]不應該用多久沒處理站務或編輯來判斷是否足信，而是其用權手法如何，與當初授信時相比，有沒有改變。」他認為，社群應解任的是行事方式已經改變而社群無法接受該改變之管理員。

AT則回應：「久未從事站務結果絕大多數就是繼續不做，更枉論去複習一下方針指引什麼的[。]這樣的學習精神是否存在於長期不活躍管理員之間，那倒是不得而知，至於用權手法如何尚且需要有實例才能驗證，長期不做的話連驗證的可能性也不存在。」

經過近兩個月的討論，相關方案仍未獲得共識，最終被存檔，成為收錄於Wikipedia:常年提案#收緊管理員的不活躍標準的第23次討論。

解任

2021年9月21日，Lt2818提出，管理員的解任與否應按其行為判斷，而現時的投票方法可能更多反映該管理員得罪或拉攏的人數。投票部分改為由全體行政員議決，並給出詳細判詞。次日，他擬出了相應提案。然而有用戶認為它帶來了行政員過大（以至於成為實際上的仲裁委員會），未能通過。

9月23日，前行政員菲菇（User:PhiLiP）提出了陪審團制度，陪審團從具有人事任免投票資格的活躍用戶中通過算法隨機抽籤挑選產生。後來為了保護陪審員的安全，提出了使用SecurePoll投票的變體。

與管理員解任有關的改革在10月份漸趨不活躍。

復任

2021年9月25日，Eric Liu 重提管理員復任制度。他認為，解任不活躍管理員考慮的是帳號安全問題，自行辭職有可能因為現實生活充實啊、暫時想休息：這兩種離任方式並不涉及能力問題，而只要其恢復活躍，就應重新賦予其管理員權限，使其儘速恢復投入站務工作，避免進行費時費力的選舉。10月25日。他擬出提案。11月25日，提案通過。

方針內容

Wikipedia:管理員#復任

無論管理員為何離任，皆可以上方提及之一般程序重新申請成為管理人員。

而在自願辭職或因不活躍而離任的情況下，當事人可提出管理員復任申請，由行政員審核。基本上，復任申請除有以下情事外應可獲通過：

• 牽涉爭議而辭職：若當事人過往是在牽涉重大爭議（例如被提起解任投票）之情況下自行辭職，則應循一般管理人員申請程序重新上任，或至少先經社群廣泛討論，直至對於當事人之地位達成共識為止。
• 長期不活躍而滿足以下其中一項條件，此時行政員應當否決復任申請，而當事人應循一般管理人員申請程序重新上任：
  • 自願辭職後二年、不活躍離任後一年未有編輯：當事人在自願辭職後已至少二年沒有編輯，或因不活躍而離任後至少一年沒有編輯；
  • 申請復任前五年未有管理操作：在因不活躍而離任之情況下，當事人申請復任前已至少五年未進行管理操作。
• 無法保障當事人帳號之安全性：有合理根據，可認為當事人帳號之安全性不受保障，以至於不適合直接取回重大權限。相關證據應當向行政員提出，並附詳細說明。

管理員復任申請應在行政員布告板提出，由行政員依據權限恢復程序操作。授權前，行政員應確信當事人已恢復活躍或將恢復活躍，並至少待申請提出達七日。若過程中他人有所疑慮，行政員應推遲授權，並進行充分討論，直至達成共識為止。

本制度不適用於介面管理員、行政員、用戶查核員與監督員。從這些職務上離任者應循一般管理人員申請程序重新上任。

Wikipedia:行政員#恢復權限

若有管理員復任申請在行政員布告板提出，行政員應當遵循以下程序操作：

1. 確認當事人是否曾是管理員；
2. 確認當事人離任原因為自願辭職或不活躍；
3. 檢查當事人之使用者討論頁面、相關布告板、互助客棧和其他討論，確認當事人是否因牽涉爭議而辭職；
4. 為充分確認申請之合理性，行政員在授權前應至少待申請提出達七日，以讓其他行政員和編者發表意見。若有足以影響情況之新資訊出現，行政員可適當推遲授權時間；
5. 若當事人在自願辭職後已至少二年沒有編輯，或因不活躍而離任後已至少一年沒有編輯，行政員應當否決申請，或轉介一般管理人員申請程序；
6. 若當事人申請復任前已至少五年未進行管理操作，行政員應當否決申請，或轉介一般管理人員申請程序；
7. 在恢復管理員權限前，行政員應確信當事人已恢復活躍或將恢復活躍；
8. 若在復任申請之審核過程中他人有所疑慮，行政員應推遲授權，並進行充分討論，直至達成共識為止。

其它

2021年11月13日，User:桐生ここ提出，「增加管理員站務要求」的討論反應出「管理員」的頭銜會使普通人對這些用戶產生誤解，而管理員應該是「一名受到社區信任，被解除一些限制的用戶」，故建議更名為「系統操作員」。後來社群還提出了其它用戶組的更名方案，但均未達成修改的共識。

2021年11月21日，User:Assifbus提出了與地域相關的管理員任免和避嫌的建議。

可靠來源佈告板改革

本部分主體由User:Ghrenghren撰寫，有較大改動。

來源可靠嗎？這一向是中文維基百科一個高度爭議的問題。之前有多名用戶因為對來源可靠性意見不同而起爭執。

2021年6月15日，User:葉又嘉在RSN提出立場新聞可靠性的討論。討論綿延至10月，雙方各提出了不同理由論証立場應屬第三級還是第四級，未能達成共識。10月9日，User:Cmsth11126a02依據「共識不強求一致同意」，以第四級結案。之後，User:和平至上在互助客棧其他版提出了RSN暴力結案的問題。社群意識到了RSN難以達到共識的弊端，並以此為契機，在當年11月，陸續通過了一些改革可靠來源布告板的方案。

1. 將達成結論的條件「一致認為」改為「達成共識」。
2. 將評級的數字描述（「第幾級」）更換成文字。
3. 停用「非常可靠」，即原「第五級」。
4. 拆分原「第三級」為「半可靠」和「無共識」。

其中，拆分第三級的原因是，它容納了「無共識」和「半可靠」兩種狀態。因此，即使某些討論中，主流意見偏向三、四其中一級，依然會因為少量不同意見而以第三級結案。故，分割第三級後，社群可以直接以無共識結案，解決雙方互相不能說服對方而冗長討論的問題。

原等級	改革後等級
第五級		廢除
第四級	通常可靠
第三級	半可靠
		無共識
第二級	不可靠
加入防濫用過濾器		應停用並加入防濫用過濾器
第一級	列入黑名單
陳舊討論

此外，還有一些來源的可靠性亦受爭議：

• 微信公眾號。微信公眾號也是社交平台的一種，但部份用戶認為公眾號帶有官方性質，與YouTube等有所不同，故有用戶提出把社交平台獨立一級處理，但後被否決。
• 大紀元。大紀元是法輪功的機關報，社群爭執於它究竟是第二級還是第三級來源。10月25日，管理員Antigng直接結案：

• 大紀元時報通常不是科學/技術領域的可靠來源，與生命科學/醫學、新冠病毒及疫情相關者尤為不可靠；
• 大紀元時報通常不是2016年以後美國國內政治相關主題的可靠來源，涉及2020年美國大選者尤為不可靠；
• 大紀元時報在其它領域和主題上的可靠性，本案未得出共識，暫維持現狀。

本結案與原有共識被一併寫入了RSP，但也有編者提出了不同意見。

User:Ghrenghren還建立了{{RSNG}}用於RSN的交流。

用戶查核員將回歸？

2022年1月13日20時38分(UTC)，維基媒體基金會在互助客棧方針版以中英雙語發布《重新引入中文維基百科用戶查核權限》的聲明。聲明中說，若中文維基百科能滿足下述兩個條件，基金會將會支持恢復本地社群之用戶查核權限。其一是「必須承諾維護所有擁有本地用戶查核權限之社群的通用認知」，其二是按照基金會定下的任免規則：用戶查核員任期為兩年，通過Extension:SecurePoll秘密投票，並由監管員支援監票，並經用戶查核員社群培訓後才能上任。另外，基金會將會定期稽核中文維基之用戶查核活動，為期至少一年。

雖然有支持的聲音，社群普遍不看好CU權的回歸。數名用戶擔憂CU員可能難產，有用戶認為中國大陸人士不能擔任CU員會造成歧視與不公平。此外，中文維基百科曾出現CU信息泄漏的事件，也有用戶擔憂本地用戶查核的安全性。

2018年3月29日，出於安全上的考量（security concerns），基金會移除了中文維基百科所有用戶查核員的權限，並且不再承認新的本地查核員選舉結果。2021年8月，基金會修訂了《非公開個人信息存取政策》，不再接受居住在中國大陸或其他封鎖維基媒體項目的國家或地區簽署《非公開信息保密協議》，且會撤銷已經簽署的協議。當年10月14日的公聽會上，瑪吉·丹尼斯回答了關於能否將用戶查核權限返還本地的問題。她說，按她的理解，《非公開個人信息存取政策》改變之後，中維查核員只要有資格簽署保密協議便可以重新運作，而三年前被除權的查核員需要重新通過社群甄選流程。

自動登出的罪魁禍首

中國大陸的新手在通過代理編輯中文維基百科時可能遇到自動登出的問題：發布編輯後，卻發現自己處於未登錄狀態，而由於代理的IP被封，這筆編輯沒有被發布。一般認為，這個漏洞只影響非自動確認用戶，但也有自確報告了此問題。該漏洞的原因也一直沒找到，甚至技術人員無法復現，中國大陸維基人用戶組在基金會行動相關的聲明中也提到了這個問題：

我們猜測這個bug可能跟代理IP在跨項目封禁時的處理、跨站cookies有關。這個bug可以說能有五分之一的大陸新手會遇到。但是，即使這個bug在一年半之前就已經匯報給了[Phabricator]，基金會仍然不修這個影響五分之一大陸新手的bug。現在這個bug處在根本沒人管的程度，它連修bug第一步需要的分流都沒分。

——《丟掉幻想，準備鬥爭——一評基金會全域鎖定中文維基人及瑪吉·丹尼斯的「聲明」》

現在，事情似乎有了轉機。2021年11月4日，User:Q28在Phabricator報告在中文維基百科編輯頁面User:Q228時會自動登出。User:Andre Klapper (WMF) 表示他甚至無法按下編輯按鈕，但是他可以通過調試模式編輯，並認為MediaWiki:Common.js/edit.js可能出現問題。由於該漏洞與新用戶自動登出的漏洞十分相似，User:MilkyDefer推測二者相關。

11月10日，MilkyDefer宣布他「找到了導致自動登出的罪魁禍首」。他發現，只要關掉小工具RefToolBar，自動登出就不會發生；反之則會發生。而RefToolbar設定為註冊用戶默認啟用。他說：「這是在幾天前反饋稱使用safemode加載編輯頁面即可不受影響後，我開了個新號申請了臨時IPBE在瀏覽器裡頭一個腳本一個腳本的阻擋加載後發現的。我在阻擋en:MediaWiki:RefToolbar.js的請求後，session就不會再丟失了。一旦解除阻擋，session就會丟失。後來我去參數設置[...]關掉這個工具，session也不會丟失；打開就會丟失。」

次日11:17，他總結了觸發條件：

1. 你的賬號在中央認證中沒有英維本地賬號（可以解釋為什麼有人不會出現問題，畢竟英維附加賬號很少有人會沒有）
2. 你的IP地址在英維本地被封鎖（這樣你在訪問時不會被自動創建一個）
3. 你在中維擁有IP封鎖例外權限（僅保證你點擊編輯後會加載編輯框，如果你的IP在中維本地未封鎖而英維本地封鎖的話我猜一樣會發生這個問題）
4. 你使用的編輯器會加載RefToolbar插件（目前似乎僅2010 wikitext編輯器，可以解釋為什麼2017 wikitext編輯器沒有問題）
5. 你編輯的時候真的加載了上述插件（可以解釋為什麼你搶在加載前直接發布不會出現問題）

是否是自動確認跟這個問題基本無關。

19:02，他表示，這或許是CentralAuth的問題：由於英文維基百科的IP封禁，他無法通過CentralAuth創建英文維基百科本地帳戶。向沒有本地帳戶（也沒有創建帳戶）的站點發送請求會以某種方式導致CentralAuth相關的cookie被響應頭刪除。CentralAuth cookie 被刪除後，由於腳本加載，另一個沒有 CentralAuth cookie 的請求被發送到中文維基百科，導致中文維基百科的本地登錄cookie也被刪除，導致用戶被自動登出。

20:46，User:Xiplus更新了重現步驟：

重現步驟

1. Make sure your account doesn't have a local account in en.wikipedia.org (Check it in https://meta.wikimedia.org/wiki/Special:CentralAuth)
2. Make sure your account have ipblock-exempt permission in zh.wikipedia.org
3. Visit wikis through a globally blocked IP (Make sure you cannot create accounts in https://en.wikipedia.org/wiki/Special:CreateAccount)
4. Visit https://zh.wikipedia.org/w/index.php?title=Wikipedia:%E6%B2%99%E7%9B%92&action=edit&safemode=1
5. You should able to edit this page because you have ipblock-exempt permission in zh.wikipedia.org.
6. Run following JavaScript in your browser console (You can load any js in en.wikipedia.org)

mw.loader.load('//en.wikipedia.org/w/index.php?title=User:Xiplus/emptyscript.js&action=raw&ctype=text/javascript&t=' + Date.now())

7. Check the request information in browser dev tools. Check the Response Headers. You can see

set-cookie: ss0-enwikiSession=SECRET1; path=/; secure; HttpOnly
set-cookie: enwikiSession=SECRET1; path=/; secure; HttpOnly; SameSite=None
set-cookie: centralauth_ss0-User=YOURUSERNAME; expires=Fri, 11-Nov-2022 12:13:44 GMT; Max-Age=31536000; path=/; domain=.wikipedia.org; secure; HttpOnly
set-cookie: centralauth_User=YOURUSERNAME; expires=Fri, 11-Nov-2022 12:13:44 GMT; Max-Age=31536000; path=/; domain=.wikipedia.org; secure; HttpOnly; SameSite=None
set-cookie: centralauth_ss0-Token=SECRET2; expires=Fri, 11-Nov-2022 12:13:44 GMT; Max-Age=31536000; path=/; domain=.wikipedia.org; secure; HttpOnly
set-cookie: centralauth_Token=SECRET2; expires=Fri, 11-Nov-2022 12:13:44 GMT; Max-Age=31536000; path=/; domain=.wikipedia.org; secure; HttpOnly; SameSite=None
set-cookie: ss0-centralauth_Session=SECRET3; path=/; domain=.wikipedia.org; secure; HttpOnly
set-cookie: centralauth_Session=SECRET3; path=/; domain=.wikipedia.org; secure; HttpOnly; SameSite=None

8. Run the script in step 6 again
9. Check the Response Headers again. You can see

set-cookie: ss0-enwikiSession=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; secure; HttpOnly
set-cookie: enwikiSession=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; secure; HttpOnly; SameSite=None
set-cookie: centralauth_ss0-User=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly
set-cookie: centralauth_User=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly; SameSite=None
set-cookie: centralauth_ss0-Token=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly
set-cookie: centralauth_Token=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly; SameSite=None
set-cookie: ss0-centralauth_Session=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly
set-cookie: centralauth_Session=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly; SameSite=None

10. Your cookies are deleted. Then reload the page.
11. You are logged out. You can't edit the page because your IP is blocked.
12. Wait a second. Then you can see "Central login" notification (You are centrally logged in as XXX. Reload the page to apply your user settings.).
13. Reload the page. You can edit the page now because you are logged in.

目前該問題尚未修復。User:Tranve說：「CentralAuth的維護者在IRC上回復我說，目前這個插件完全由志願者維護，而他們既沒有時間也沒有精力去修復這個bug。」本地也提出過兩點規避方案，一是把RefToolBar的代碼遷移到本地，定期更新；二是直接默認關閉RefToolBar。二方案均未實施。

受影響用戶可以通過關閉RefToolbar來規避此問題。

簡訊

• 【延伸確認用戶組部署後續】2021年8月16日，延伸確認用戶組部署至中文維基百科，但是保護圖標使用的是臨時的色盲不友好版本。11月1日，社群投票選出了延伸確認保護圖示：。此外，同期，社群對只允許「延伸確認用戶」編輯的保護類型的名稱「延伸確認保護」提出了修改意見，而後進行了修改各級保護用名的投票，投票結果是「維持原狀」。
• 【UPNOT#12應該怎麽執行？】2021年9月，User:蘇州宇文宙武和User:魚頭炮的用戶頁因違反WP:UPNOT#12被提刪，最終被刪除。有人提出了嚴格化UPNOT#12的建議，但社群未對此達成共識。
• 【可視化編輯器結束測試　Growth功能部署】2021年10月，中文維基百科成為唯一一個沒有部署Growth的維基百科站點，因為可視化編輯器（VE）尚未結束beta。28日，MilkyDefer提出VE結束beta的建議，獲得通過。12月，VE正式啟用，同月，Growth也在本站部署。
• 【HAM將改為SPI】1月12日，路西法人（User:LuciferianThomas）提議將WP:HAM功能擴展至所有傀儡調查，改革為用戶傀儡調查頁，接受但不再限於需要用戶查核的傀儡調查，以認真調查傀儡，進一步改善反破壞制度。提案獲一致贊同，相關改革正在進行。
• 【八年速刪】你提報的快速刪除等了多久？1月12日，管理員Xiplus以G14刪除了Wikipedia:元類別標準一覽，該頁面被掛上了{{NotMandarin}}，2013年11月2日即可刪除，共等待了2993天。推測因為頁面很少人瀏覽，導致頁面沒有被重新渲染。該頁面被列為等待刪除最久的快速刪除候選。

參考資料

---

2022年2月1日 第7期