信任與安全產品/臨時帳號/進展更新

概览

更新

法務

常見問題

Basic updates about the project · Updates from the Wikimedia Foundation Legal department · Updates about changes adjusting the software to temporary accounts

2024年10月: Deployments on the first pilots

Deployment schedule

We have a finalized list of small-to-medium sized projects where we will be deploying temporary accounts over the next couple of weeks. The goal is to ensure all critical functionality (patroller workflows, tools etc.) for temporary accounts works as expected. We decided to split this phase into two batches. This way, we will have more control over the key functionality and more confidence before temporary accounts are introduced on the largest of the first pilots.

• On October 29, we will deploy Temporary Accounts to: Czech Wikiversity, Igbo Wikipedia, Italian Wikiquote, Swahili Wikipedia, and Serbo-Croatian Wikipedia.
• On November 5 (subject to change based on above rollout), we will deploy to: Persian Wiktionary, Japanese Wikibooks, Cantonese Wikipedia, Danish Wikipedia, Serbian Wikipedia, Romanian Wikipedia, and Norwegian Bokmål Wikipedia

Progress on key features

• We are developing a public dashboard for monitoring metrics for our pilot projects. We will have a documentation page in place shortly to explain which metrics we are focusing on and why.
• Special:GlobalContributions is now ready for looking up cross-wiki contributions from an IP address. This page will only be accessible to users who qualify to see IP addresses associated with a temporary account. We are still ironing out permissions for this page access. We will have a documentation page up about it over the next week.
• We have updated IP Info to support information for multiple IP addresses that may be associated with a temporary account. Special:IPInfo should be available on all projects where temporary accounts will be deployed.
• We have completed building the required workflows for gaining access to IP Reveal as outlined in the Wikimedia Access to Temporary Account IP Addresses Policy.
• We are updating IP Info access policy to be at par with the IP Reveal policy. You can follow along with this task for further information.
• Temporary accounts can now be globally blocked. Global autoblocks work is in progress and should be implemented over the next couple of weeks.
• Temporary accounts are now available on all beta cluster projects except for en-rtl for testing.

We are looking forward to your comments on the talk page.

2024年9月: Deployment plan is ready!

We are happy to announce our timeline and strategy for the temporary accounts deployments across all wikis. The plan was co-created by the Product and Technology, Legal, and Communications departments at the Foundation. We also consulted stewards and informed CheckUsers. All the date below are subject to change based on the extent of pending work. We will be informing you if anything changes.

• In late October 2024, we will roll out on approximately 10 small and medium-sized wikis. This phase is called the minor pilot deployment. We have pre-selected potential good pilots based on different factors. These include: the numbers of active admins and IP edits per month, lack of blockers related to the configuration of a given wiki, availability of potential ambassadors and technical members of the respective communities, and more. After we deploy there, we will be monitoring the impact of this project on collaboration on wikis. We will also be contacting community members of these wikis. Some time later, we will monitor what will happen when the initial IP addresses of temporary accounts are not available to patrollers.
• If the first deployments are successful and we don't have a ton of unexpected work, then in February 2025, we will roll out on larger wikis. We call this major pilot deployment. It may include some top10 wikis, but not English Wikipedia.
• Next, in May 2025, we will deploy on all remaining wikis in one carefully coordinated step. After that, we will be providing support, monitoring metrics, and solving issues as they arise.
• We will do our best to inform everyone impacted ahead of time. Information about temporary accounts will be available on Tech News, Diff, other blogs, different wikipages, banners, and other forms. At conferences, for example regional and national ones, we or our colleagues on our behalf will be inviting talk about this project with attendees. We will also try to have presentations there. In addition, we will be contacting affiliates running programs of support for editors with advanced permissions. Subscribe to our new newsletter to stay close in touch.

2024年9月: Progress on our technical work

• Before we deploy temporary accounts to any non-test wiki, we need to complete our work on a few remaining tasks. These include:
  • Live-updated metrics on temporary accounts. Before the October deployments, we will build a dashboard presenting the impact of temporary accounts on communities. There will be different graphs showing, for example, numbers of reverts, blocks, temp accounts' IP address previews ("IP Reveal"), successful and abandoned edits, and more. All these will be updated very frequently, for instance, every day, to give everyone a good visibility of the actual work of temporary accounts on wikis. (T357763)
  • Allowing global autoblocks for temporary accounts (T368949), building a mechanism automatically giving the eligible users the right to reveal IP addresses of temporary accounts (T327913), and some other tasks.
  • You can also check the blockers for the major pilot deployments and the blockers for the full deployment.
  • Relatedly, we wanted to share a kind request to the maintainers of community-owned code like tools, bots, gadgets etc. We want to avoid any unnecessary disruptions to your software. If it uses data about IP addresses or is available for not logged-in users, please read our documentation , and in particular, the section on how your code might need to be updated . We will gladly help you out, and we're waiting for your questions.
• Graduating IP Info out of beta features. IP Info provides reliable information about IP addresses to some logged-in users. According to a dedicated policy, this tool may only be used for the investigation or prevention of violations of policies. Users can access it if they select a checkbox in their preferences, agreeing to use this tool in accordance with these terms. Then, they can see a button ⓘ displayed next to the IP address on pages like Recent Changes, Watchlist, and page history. The feature is also available for them at the top of the Special:Contributions page when contributions of a specific IP address are listed. Soon, we will make this a regular feature and remove it from the list of beta features. We will also make some changes to its functionality. For more information about IP Info, watch its project page or subscribe to our new newsletter. (T375084)

2024年7月: Global blocks are here. Temporary accounts on testwiki

• Deployment on testwiki. We have rolled out temporary accounts to testwiki. Anyone who edits testwiki without an account will see their edits being attributed to a temporary account. We would like to emphasize that this is an early release, and things may break. This deployment makes it possible for some teams (like Data Platform Engineering or Apps) to start adjusting their code to temporary accounts. We aren't planning on introducing temporary accounts on any other wiki just yet. Instead, we will invite patrollers from different communities to testwiki and ask them to familiarize themselves with the new experience and share opinions with us. Currently, only testwiki admins can see the implemented patroller workflows (such as revealing IPs and view IP contributions) for temporary accounts. Over the next few weeks we will broaden the access to allow more users to test temporary accounts related workflows on testwiki.

• 

  Global blocking. We are really glad to announce that we launched global account blocks on all wikis (T17294). A request for this feature was first documented in 2008. It was also the top6 feature in the stewards' wishlist from 2015. Now, stewards can globally block regular and temporary account users. Read our previous update to learn more about the expected impact of global blocks.
• Wikimania. We will be hosting sessions "Temporary Accounts are coming" (add to your favorite sessions) and "Getting better at blocking bad activity on the wikis" (add to your favorite sessions). Register to Wikimania to add sessions to favorites. Please join us in-person or virtually, and don't hesitate to get in touch with our team members during the event!
• AbuseFilter. Some existing edit/abuse filters set up by community members on different wikis will need to be updated to work with temporary accounts. (See our instructions for developers on how to do this.) After the deployment of temporary accounts on a given wiki, abuse filters using data about IP together with related logs will be hidden from general view. It will be possible for admins to view and edit these filters. Later, we may change the group of users with access to the impacted filters, to potentially include technical editors who don't have any other advanced permissions.

之前的进展更新

2024年6月: Priority for functionary and patroller tools

• Team changes. In our update from September 2023, we wrote that changes to the team may have an effect on the timeline of this project. Indeed, they had, as we wrote on the talk page earlier this year. Briefly, the Anti-Harassment Tools and Trust and Safety Tools teams were merged into one to work according to a unified plan. Now, we encourage you to look at our refreshed team page and our part of the 2024–2025 annual plan: key results WE4.1, WE4.2, and WE4.4. Temporary accounts are documented as WE4.4.
• Documentation. We invite you to read the new FAQ, visit the main project page, and click around. We have migrated pages from Meta-Wiki, and restructured and updated them. Hopefully, the new structure makes it easier to learn about the future changes, how temporary accounts will work, and why this change will happen.
• Wikimania. Our team members will hold two sessions at Wikimania 2024: about temporary accounts and about getting better at blocking bad activity on wikis. Whether you're going to be in Katowice or connecting online, join us!
• Projected timeline for deployments:
  • We have reviewed our previous plans and prioritized support for patroller tools and anti-abuse workflows. The most important part of our work is ensuring that wiki functionaries and patrollers are comfortable with the rollout of temporary accounts. We can't estimate how much time this part of work will take. As a result, we can't announce the dates of deployments yet.
  • In April, we asked volunteer developers to update the code they maintain. This was an early call to give them time to prepare. Some tools may need to be updated before the test wiki deployment.
  • We are discussing our strategy for content wiki deployments. We're weighing different factors, including consistency of functionaries' workflows across wikis, and availability of functionaries and frequency of abuse on different wikis.
• Changes to features and tools. As we mentioned, we are prioritizing support for patrollers and functionaries. Below are examples of our recent work:
  • Global blocking. Currently, there is no tool that allows stewards to globally block an account – there is only global lock, which logs the person out of their account. Without our changes, a temporary account holder blocked this way would lose their account and create a new one with their next edit attempt. After our changes, they will not be logged out, and they will see a block notice on their next edit attempt (T17294). Doing this also means that stewards will be able to globally block registered users, which implements a long-requested feature and provides better tools to combat cross-wiki abuse.
  • Autoblocks. To make the above effective, we will also support autoblocks, limiting temporary account creations (T355286). This will limit the avenues for abuse if a person using a temporary account that is globally blocked exits their session and tries to make an edit again.
  • Global User Contributions. The Global User Contributions tool allows patrollers to track a logged-out user's edits on all wikis and track cross-wiki abuse. It depends on IP addresses being public, though. As a result of our deployments, it will stop working. We are building a new tool with the same name which will provide the same functionality (T337089).
  • Special page for IP contributions. Currently, functionaries check contributions made by logged-out users from IPs, using the page Special:Contributions. After our deployments, only regular and temporary account holders' contributions will be listed on this special page. We are building a new page, Special:IPContributions, to keep the functionality (T358852).
  • We are also updating other tools like AbuseFilter, CheckUser tools, action API, and more.

<span id="2023年9月:_New_features,_new_names,_and_Wikimania">

2023年9月：新功能、新用户名和维基媒体国际会议

维基媒体国际会议幻灯片

项目的最新进展

• 临时用户名格式 临时用户名的格式为~YYYY-nnnnn-nnn。 YYYY表示临时账户的创建时间。 用“n”表示的字符串是临时账户的唯一标识符。 例如，某个2023年创建的临时账户可能是这样的：~2023-27459-041。 以年份作为前缀可便于判断临时账户创建了多久。 如此设计也便于需要与该编者沟通的巡查者和其他人了解情况。 我们是在讨论页和Phabricator (T337103)上讨论过后决定采用这一方案。 感谢各位参与讨论！
• 团队变更和部署时间表：反骚扰工具团队已与信任与安全工具团队合并。 合并后团队称为信任与安全产品团队。 它将扩大范围。 结构的变化可能会对该项目的时间表产生影响。 在为新团队制定路线图时，我们将分享更多最新信息。 我们目前预计的项目时间表如下：
  • 部署到testwiki -- 2024年1月
  • 部署到首批试点维基--2024年3月开始
• 常见问题页面。我们创建了常见问题（FAQ）页面。 我们将在未来几周和几个月内对其进行扩充和更新。
• 维基國際會議最新消息和项目更名。 在新加坡举办的维基國際會議上，我们介绍了该项目的最新情况。 您可以访问演示的幻灯片。 YouTube上也有完整演讲的录音。 在维基媒体國際會議上，我们是使用以前的项目名称"IP屏蔽"。 之后，我们决定将其改为"未注册编辑者临时账户"，或简称為临时账户。 它以通俗易懂的语言介绍了我们的变化，没有任何技术性的隐喻。

新功能

• 全域封禁。我们將著手於全域封禁注册用户和临时用户的工作。 目前，全域封禁功能仅适用于IP地址和范围。 长期以来，人们一直要求延展此一功能，以便也能阻止封禁用户。 我们将在未来几个月内定义并开发这一功能。 您可以关注Phabricator任务 (T17294) 的更新。
• 全域用户贡献。我们将引入全域用户贡献功能到MediaWiki。 该功能目前已在GUC工具裏实现。 我们的更改将使用户更容易查看账户的各個项目的贡献。 这将通过一个特殊页面来实现。 当临时账户生效时，这将特别有用。 有关技术细节，请参见T337089。

2023年4月：隐藏IP的计划

如此前所承诺的一样，这里是隐藏IP功能如何工作的更新。 本次更新的内容是，对未注册用户和注册用户，各自会看到怎样的变化。 首先，我们需要承认，我们仍有许多问题尚未决定。 这是我们最初的计划，而且不会涵盖本计划中我们所有的目标。 在推进的过程中，我们也发现一些之前没有预见的新工作。 你的反馈会帮助我们，以便了解我们在隐藏IP地址计划中，还需要怎样帮助社群。

此次更新以常见问题解答的形式，以清晰且易于理解的方式介绍最近的变动。

从未注册编者的角度，隐藏IP地址会改变什么？

目前，未注册编者完成一次编辑之前会被告知其编辑将记录于其IP地址名下。 未来，未注册编者完成编辑前会被告知其编辑将记录于一个临时账户名下。 账户的名字是一个数字，每次有新账户创建时数字都会增加。 该账户会与cookie关联，存于用户的浏览器中。 只要cookie存在，该用户就会持续使用同一个临时账户，其所有编辑都将记作该账户的编辑。 用户的IP地址可能会改变，但只要cookie存在，临时账户就不会改变。 一个wiki上产生的临时账户也会用在其他该用户可能编辑的wiki上。

临时用户名看起来是什么样的？

我们也不知道。 我们最初的方案是用星号作为前缀，其后跟随一串自动递增的数字。 （例如：*12345） 下面列出了其他的一些方案。 但是一些志愿者指出，星号不算是好的方案，因为一个MediaWiki中尚未解决的Bug与之有关。

我们正讨论各种前缀方案，并且将会对它们进行测试。 目前我们的最佳备选有（顺序不代表实际排序）：

• 脱字符（^）- User:^12345
• 连接符（-）- User:-12345
• 波浪线（~）- User:~12345
• 感叹号（!）- User:!12345
• 问号（?） – User:?12345
• 年份 - User:2023-12345

这些方案之中，有没有你觉得特别好或特别差的选项？ 请在讨论页或Phabricator上留言。

临时用户名会持续使用多久？

首次编辑后的一段时间（暂且设计为一年），或清除该用户的缓存之后，cookies会自动过期。 已作出的编辑仍会记在之前使用的账户下。 旧用户名过期后，如果该编者又再次编辑，则将获得新的临时账户。

从巡查员的角度来看，隐藏IP地址会造成什么变化？

IP地址暴露将受到限制

最大的变化是IP地址不再对公众可见。 所有没有账户，以及不满足获取IP地址所需要求者（见法律更新）将无法看见IP地址。 为了减轻对巡查工作的影响，我们会改进IP信息功能。 这会包括Spur服务的数据。

获取查看IP地址的权限

我们和基金会的法务部门一起制定了新的指引。 该指引规定了谁可以取得IP地址，以及如何取得。 达到要求的用户可以在Special:Preferences中选择加入，以显示IP地址。 查看显示功能工作的详细信息。 显示并取得IP地址的操作会被日志记录，该日志只对很有限的一部分用户可见（用户查核员、监管员、信任与安全团队）。

与临时编者沟通的更好渠道 临时账户与浏览器cookie关联。 只要cookie存在，用户的编辑就会一直记录于同一个临时账户名下。 临时账户的持有者也能和注册用户一样收到讨论页通知。 我们希望这样可以使得与临时用户的沟通过程变得更好。 这也能解决一些社群提出的长期存在的问题（见T278838）。

记录用于破坏的IP地址

隐藏IP地址之后，和目前的做法一样，在持续出没的破坏者页面公开记录破坏者的IP地址仍是可能的。 然而，我们需要小心行事，避免暴露其他临时用户的IP地址。 讨论可能的破坏者时，如果发现被怀疑的用户并不是破坏者，应当使用监督隐藏之类的工具来隐藏IP地址。 更多细节详见指引。

巡查工具

与IP用户类似，可以通过Special:Block、Special:Checkuser及Special:Investigate对临时用户作出相应操作。 另外，使用IP信息功能可以获得相应修订版本对应的IP地址。

我们正在制定指引，以便规范巡查相关的云工具和机器人获取IP地址的行为。 我们很快会就此事发布更新。

站点上现存的IP地址会怎样？

已经存在的IP地址会保持不变。 隐藏IP地址之后的编辑会记录到临时用户名下。 由于我们是逐步实装这一计划，所以不同站点上这一变化不是同步发生的。

IP地址显示功能是如何运作的？

有权获取IP地址的用户可以显示临时账户的IP地址。 此功能的初步模型：

依赖IP地址的工具和机器人会怎样？

我们正在了解志愿者维护的工具所受的影响。 这是我们团队的任务，也是研究和工程团队的任务。 然后我们还需要与法律团队协作，了解哪些工具可以继续获取IP地址，以及它们需要遵守的指引。 我们有行动计划之后会在本页更新信息。

推出计划

我们计划缓慢测试隐藏IP计划，给予社群充足的时间来反馈和测试。 我们希望这个过程不会干扰社群流程。 我们的另一个工作重点是防止对社群健康造成不良后果。 我们已经开发了一些测量指标，当我们开始隐藏IP地址的时候就会用这些指标来观察对社群的影响。

我们正在寻找可以试点隐藏IP的社群。 我们目前考虑的因素有IP编辑数、反破坏工作的迫切程度、站点的大小以及被破坏的可能性等。 等到接近启动隐藏IP地址的时候，我们会在本页更新我们选择的试点社群。 如果你希望你的社群能参与试点，请在社群中达成共识，然后在讨论页上告诉我们。

<span id="2023年2月16日:_Refocusing_work_on_IP_Masking">

2023年2月16日: 重新关注隐藏IP地址计划

大家好。我们现在正式将工作重点重新调整到隐藏IP地址计划上，目前已经完成了第一阶段的IP信息功能和其他相关项目。我们正推进技术规划，了解隐藏IP地址实施之后需要作出哪些改变。我们会持续与技术志愿者联络，评估这些变动并迁移相关工具（如有需要）。Phabricator上已开展部分规划工作，如有关于特定任务的问题，可以在那里联系我们。

我很快会发布另一篇文章来跟进此事，分享我们已经实现的最简可行产品的大纲。这个最简可行产品基于我们过去在本页面和其他平台上与社群的对话。请详阅过往对话以及本页上过去的进展更新。如果你有任何问题和担忧，可以在讨论页上联络我们。

<span id="2022年2月25日:_Implementation_Strategy_and_next_steps">

2022年2月25日: 实施策略和下一步计划

大家好，我们有一项关于隐藏IP地址实施策略的更新。

我们首先感谢所有来到这里留下反馈的人。我们听到很多人抱怨这个页面不太容易阅读，这一问题我们正在努力解决。我们真诚地感谢您抽出时间阅读本页面和讨论页上的内容。在决定实施方案之前，我们阅读并考虑了讨论页上的每一条评论。

开始之前我们必须说目前依旧很多问题尚未解决，在这个项目上依然有很长的路要走。我们希望您可以在这些讨论上就这些问题发表您的意见。如果您还没有非常了解的话，在继续阅读前，请先阅读谁可以继续访问IP地址这段。

我们收到了来自社群对这两项提议的反馈，但很遗憾的是对这两种提议都没有达成共识。以下评论引自讨论页：

• “对于小维基来说，我认为基于IP的方案更好，因为两个匿名用户不太可能使用相同的IP地址；而且对于破坏者来说，修改IP显然比清除cookies困难。”
• “基于会话的系统看起来更好，这有助于与匿名编者沟通。我是英文维基百科的管理员，我与IP用户的交集基本都是回退她们的编辑，警告她们不要继续破坏。就最近的几个案子来看，我甚至懒得给她们发警告，毕竟应该看到这些警告的人可能事实上根本看不到。有一次我在与一位提议一些变更的编者进行沟通，我发现事实上我在好几个IP地址（的讨论页上）留言；同时我也很难确定她们是不是同一个人，因此我不得不一直向她们确认（她们是不是同一位编者）。”
• “作为德语维基百科的管理员，对这里列出的两种隐藏IP的方式（基于IP和基于会话），我显然更喜欢基于IP的方式。将浏览器切换到隐私模式或是清除cookies简直不要太简单（我一直这么做）；相对的，修改IP地址至少需要花点功夫，况且我们已经有禁止使用开放代理的方针了。我同意Beland的观点，基于会话的身份验证方法可能有助于与善意匿名编者相沟通，但这种方法似乎还不够强大。”
• “我更倾向于基于会话的方案。该方案有助于识别并与行为良好的匿名用户沟通。然而同时，我们也需要在过滤器中识别多个来自同一IP的会话。这些用户可能是好人（例如来自学校），但很大概率会是破坏者或机器人。有一个功能目前我还没看到有人提出，就是当一个匿名用户创建账户时，创建账户的操作默认应是将现有的会话ID重命名为用户选择的用户名。我们需要查看先前的匿名用户ID与新注册用户之间的关联。”
• “即使是IP会变成加密后的形式，我也倾向于基于IP的方案，因为cookies似乎更加复杂，而且需要不断关闭与之相关的弹窗（在欧洲很常见）很烦人。我必须要说的一点就是，我很喜欢不需要cookies即可编辑维基百科这件事（除非要登陆账户）。”
• “在现有基于IP+会话的封禁基础上，新增纯粹基于会话的封禁会是很不错的改进。能够与IPv6用户基于会话进行交流，而非基于他们不断变化的IP地址也很不错。”

总之，对于基于会话的方案的主要反对意见在于清除cookies非常容易，使得用户可以轻易改变身份。

对于基于IP的方案的主要反对意见为：

• 对IP地址的加密方式可能被泄露，这意味着IP地址会被所有人看到
• 这一方法并没有改进与未注册编者的沟通方式
• 除对IP地址的封禁外，不支持基于会话的封禁

鉴于上方的描述和与技术团队就实施的可行性和带来的广泛影响进行的讨论，我们决定采用基于会话的方式，并增加了有关于解决用户删除cookies和改变身份问题的内容。如果用户频繁的修改她的用户名，我们可以采取某些手段——如查看界面中的额外信息——以关联这些用户名并确认她们的身份。我们仍在研究这方面的细节问题。这一流程将类似于目前检测傀儡的方式，只不过部分工作将自动完成。

我们仍在解决大量相关的技术问题，并会在下一次更新时提供更多的相关细节信息。这包括LTA文档、与IP用户的沟通、防滥用过滤器、第三方维基站点、小工具、用户脚本、WMF云工具、对IP查看者权限的限制等等。我们感谢您的意见，欢迎您在讨论页上提供反馈。

<span id="2021年12月9日:_IP_Masking_and_changes_to_workflows">

2021年12月9日: 隐藏IP地址以及工作流变更

我们考虑了两种隐藏IP地址的方式。作为跟进，我们分析了一些工作流在两种方式下的变化。 注意：在两种隐藏IP的方式中，管理员、监管员、用户查核员和具有IPViewer权限的用户若有反破坏的需要，可以在最近更改和页面历史之类的页面查看IP地址。

未注册用户的编辑体验

目前：目前在大多数维基站点上，未注册编者可以在不登入的情况下编辑页面。在编辑之前，会有一则讯息提醒他们的IP地址将被公开、永久地记录下来。

基于IP：未注册用户能和现在一样进行编辑。在编辑之前，会有一则讯息提示他们的IP地址会以加密的形式记录下来，而其真实IP则会在一段有限的时间内对管理员和巡查员可见。

基于会话：这与上面类似，区别在于编者会被告知，他们的编辑会以一个自动生成的用户名记录下来。

• 
  基于IP方案的截图
• 
  基于会话方案的截图

在交流中如何称呼未注册编者

目前：一般使用具体的IP地址来指称未注册编者；如果是持续出没的破坏者，则通常会根据其行为取一个名字。

基于 IP：巡查员和管理员不可公开提及IP地址，但可以公开提及加密的IP地址或长期破坏者的名字，或是与其他也具有相关权限的用户分享IP信息。

基于会话：巡查员和管理员不可公开提及IP地址，但可以提及自动生成的用户名，或与其他具有同等权限的用户分享IP信息。这将有助于识别特定的编者，但也会因为一个自动生成的用户名背后有多个IP地址而带来困扰——这与目前一个IP地址背后存在多个编者类似。为了缓解这种担忧，我们正在建立一个展现编者使用的所有活跃IP地址的工具。

未注册用户使用用户讨论页的体验

目前：每个IP地址有一个讨论页，未注册的编者可以在其上接收留言。当编者的IP地址发生变化时，他们会在新的IP地址的讨论页上接收新的留言。这割裂了讨论，使其他用户难以与一位未注册的编者进行长期的交流。

基于IP：在这种方案中，未注册用户的讨论页与现行的相同。未注册编者会在其加密后IP地址对应的讨论页上收到留言。一旦IP地址变化，对应的讨论页也随之变化。

基于会话：在这种方案中，未注册编者的讨论页与其浏览器cookie关联。即便IP发生变化，讨论页也不会变动。如果清空浏览器cookie，则其会话身份将丢失，并获得新的cookie及相关联的新讨论页。由于IP相较cookies变化得更为频繁，大多数用户可能会获得一个半永久的讨论页，除非他们特意拒绝如此。另一个好处是，讨论页上的留言在任何情况下都可以发送至正确的目标。

讨论页通知

封禁未注册编者

目前：管理员可以直接封禁单个IP地址或一个IP段。另外，还可以使其变为自动封禁，也就是利用用户浏览器的cookie防止用户更换IP后封禁时效。该功能于几年前加入。

基于IP：与现行版本相同。IP地址默认隐藏，但是管理员和有权限的巡查员可以获取IP。

基于会话：这种方案中，我们仍可以像现在这样封禁IP地址，也可以基于cookie进行封禁。这对公共设备（例如图书馆或网咖）场景十分有用。相比之下，封禁IP或IP段可能导致不必要的误伤。我希望指出的是，这种方式对于阻止有经验的破坏者来说用处不大，他们会轻易绕过cookie封禁。

<span id="2021年10月:_IP_Masking_Implementation_Approaches_FAQ">

2021年10月: 关于隐藏IP的实现方法的常见问题

这次的常见问题主要是有关几种可能的实现方法及它们对社群的影响。

问：在IP地址被隐藏之后，谁可以查看IP地址？

答：用户查核员、监管员和管理员选择同意不与无权限者分享信息后，可以查看完整的IP地址。

参与反破坏活动的编者，经社群审核同意后，可被授予一个用来查看IP地址的权限，以便继续反破坏工作。该权限与其他权限类似，由社群决定授予，并有最小编辑数和编辑天数限制。

所有注册超过一定时间并编辑了一定次数（具体数值待定）的用户，无需权限即可查看隐去部分信息的IP地址。亦即，隐去末尾部分八字节的IP地址。这些用户需要在参数设置里同意不与无权限用户分享信息，然后就能使用此功能。

其他用户均无法获取未注册用户的IP地址。

问：有哪些可能的技术实现选项？

答：过去几周中我们参与了多个讨论，讨论了技术上实现隐藏IP且将对编者和读者的影响降到最低的可能性。我们从不同的团队获得了反馈和见解。下面是两条主要的实现路径。

• 基于IP的身份识别：在这种方案中，除了IP地址会变为加密的IP地址之外，其余均保持不变。这可以让现有的许多工作流保持不变，但也不提供任何新的好处。
• 基于会话的身份识别：在这种方式中，我们基于浏览器Cookie为未注册编辑者建立身份信息。即使IP地址发生变化，Cookie也不会变动，因此会话不会随IP地址变化而结束。

问：基于IP的方案是如何运作的？

答：目前，未注册编者通过IP地址区分彼此。这种身份识别模型在我们的项目中运行了多年。熟悉IP地址的用户都知道，IP地址可能被多人使用，取决于那个IP地址动态与否。相比IPv4地址，IPv6地址更是如此。

未注册用户也会因为通勤或在不同的地理位置编辑而更换IP地址。

如果选择基于IP的方案来完成隐藏IP的任务，我们会保留现在有关IP地址的功能，并简单的把它们替换成加密后的识别符。这种方案可以保持每个IP的独特性，同时保护用户的隐私。例如，使用192.168.1.2的未注册用户可能会显示为User:ca1f46。

优势： 现有工作流和模型所受影响最小

劣势： 在这个IP地址变得更为动态、IP信息逐渐无用的世界，不能提供任何好处。

问：基于会话的方案是如何运作的？

答：这种方案是基于浏览器中的cookie来识别未注册编者。他们的编辑会被归入一个自动生成的用户名，例如User:192.168.1.2可能会被赋予用户名User:Anon3406。

在这种方案中，只要他们拥有那个cookie，会话就会一直持续，即使IP地址发生变化会话也不会中断。

优势：

• 将用户身份与设备浏览器联系起来，提供一种更持久的与他们交流的方式。
• 用户的身份不会随IP地址改变而改变。
• 这种方案使未注册编者能设定某些现在只有注册用户才能设置的偏好。
• 这种方案可向未注册编者提供将编辑历史转入永久账户的途径。

劣势：

• 目前未註冊編輯者所代表的模型將發生重大變化
• 未註冊編輯者的身分持續存在時長等同於瀏覽器cookie存在時間
• 處在隱私模式的破壞者或刪除他們cookie的人將在不改變IP的情況下獲得新的身分
• 可能需要重新考量一些社群工作流程和工具

问：基金会更倾向使用哪一种方案？

答：我们更倾向基于会话的方案，这种方案在未来会带来更多机遇。我们可以找到存在了20年的沟通问题的解决方案。用户可以删除Cookie以获得新的身份，但是其IP对持有新权限的反破坏人士仍然可见。当然，我们明白删除Cookie比更换IP简单很多，我们也了解其后果。

<span id="2021年6月10日:_Proposal_for_sharing_IP_addresses_with_those_who_need_access">

2021年6月10日: 仅向需要的人公示IP地址的提议

大家好，本项目从上次发布更新以来已经有几个月了。这期间我们与许多用户进行了对话，包括编者社群和基金会内的人。我们和资深社群成员就此项目对反破坏工作的影响进行了讨论，对于讨论中提出的各个忧虑，我们都仔细小心地加以考虑。另外还有许多人支持这项提议，认为它是改进未注册用户的隐私以及减少暴露IP带来的法律风险的一步。

我们曾经不清楚这个项目会是怎样的，当时我们的目的在于理解IP地址对于社群的意义。此后我们在对话中收到了很多关于这个问题的反馈，有许多不同的语言、不同的社群参与了讨论。我们非常感谢所有付出时间，让我们了解在他们的维基站点或跨维基环境中，反破坏工作是如何有效进行的。

关于这个计划，我们现在已经有一些较为具体提议，可以确保反破坏工作进行同时避免向无关的人披露IP地址。 请注意这只是「提议」，不是将要发生的事或者最终决定，我们只是想问问您的意见如何。——您认为哪一点比较好？哪一点不可行？有何其他方法？

我们同资深维基社群成员讨论之后，产生了一些想法；之后我们会与法律部门合作完善这些想法。概要如下：

• 用户查核员, 监管员和管理员可以查看完整的IP地址，前提是在他们在设置中选择同意不与未授权者共享。
• 参与反破坏活动的维基人，经社群批准后，可以获得查看IP地址的权限。权限的获得过程类似于我们项目上的管理员选举。为了保证只有真正需要本权限的维基人才可获取它，社群的批准至关重要。这些维基人应满足一定的注册时间（时间限制尚未确定）和编辑数标准（标准尚未确定）。
• 所有满足一定注册时间和编辑数标准（具体的注册时间和编辑数标准尚未确定）的用户都可以访问IP的一部分，IP地址的尾部八个字节会被隐藏（形如10.10.10.*）——前提是他们需要在偏好设置中同意不与未获授权者分享相关信息。
• 所有其他用户无法读取未注册贡献者的IP地址。

获取IP地址的操作将会被记录下来，以备需要时检查。这和现在记录用户查核操作的日志类似。我们希望藉此平衡用户的隐私需求和社群反破坏工作中获取信息的需求。我们希望能向有需要的人提供信息，但同时需要一个流程，使得只有真正需要的人才能获得这些信息，并且获取操作会被记录下来。

我们希望听取您对这个提议的意见。请在讨论页发表看法。

• 您认为有哪些是可行的？
• 您认为有哪些是不可行的？
• 还有什么其他更好的想法吗？