维猫报第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期