臨時アカウントの指標をリアルタイムで更新する 10月の導入の前に、臨時アカウントがコミュニティに与える影響を示すダッシュボードを構築する。 例えばリバート数、ブロック数、臨時アカウントのIPアドレスプレビュー ("IP Reveal")、成功した編集と断念された編集、などを表すいろいなグラフが示されます。 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.
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)
: 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.
古い更新情報
: 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.
As promised, here's an update about how IP Masking would work.It will cover the changes for both unregistered and registered editors.We want to acknowledge at the outset that we still have lots of open questions and things we have not decided upon.This is our initial plan and does not cover everything we aim to do during this project.As we are proceeding we are discovering new pieces of previously unforeseen work.Your feedback will help us understand what more we can do to make IP Masking easier on our communities.
This update is an FAQ format as that makes the upcoming changes clear and understandable.
What does IP Masking change from the perspective of a non-logged-in editor?
Currently, before a non-logged-in user completes an edit, they are informed that their edits will be attributed to their IP address.In the future, before a non-logged-in user completes an edit, they will be informed that their edits will be attributed to a temporary account.Its name will be a number, incrementing for each new account.The account will be tied to a cookie that lives in the user's browser.As long as that cookie exists, the user will keep the same temporary account, and all their edits will be attributed to that account.The IP addresses of the user may change, but the temporary account will not change as long as the cookie exists.A temporary account generated on one wiki will also work on other wikis that the user may contribute to.
臨時利用者名はどのような見た目になりますか？
まだわかりません。
Our initial mockups considered using an asterisk as a prefix followed by an auto-incrementing number.(Example: *12345.)You will find these mockups below.But as some volunteers pointed out, the asterisk is not a good choice because of an outstanding MediaWiki bug.
We are discussing different prefix options and will be conducting user tests with these.Our current top candidates (in no particular order) are:
Do any of these strike you as a great or a terrible choice?Please add your comments either on the talk page or Phabricator.
↑(While the question mark is a great sign for something unknown and is widely understood, there are details we're still figuring out.For example, it'll need to be encoded into the URL using %3F.This URL encoding shouldn't be a problem, but would be a hiccup for users who are used to typing in URLs by hand.)
臨時利用者名はどのくらい持続しますか？
Some time after the first edit (tentatively one year) or as a result of clearing the user's cache, the cookie will automatically expire.Existing edits will still be attributed to it, though.After the old username expires, if the user edits again in the future, they will be granted a new temporary account.
What does IP Masking change from the perspective of a patroller?
Limited IP address exposure
The biggest change is that IP addresses will no longer be visible to the general public.Anyone who does not have an account or does not meet the required thresholds for IP address access (see Legal's update) will not be able to see IP addresses.To mitigate the impact on patrolling, we will be releasing improvements to IP Info feature.This will include data from the Spur service.
Obtaining access to IP addresses
Together with the Foundation's Legal department, we have developed new guidelines.These define who will be able to access IP addresses and how.Users who meet the requirements will be able to opt-in to reveal IP addresses through Special:Preferences.See how the reveal functionality will work in detail.This access and reveal will be logged and will be available to a limited group of users (CheckUsers, stewards, Trust & Safety).
Better communication channels with temporary editors
Temporary accounts will be linked to a browser cookie.As long as the cookie persists, the user's edits will be attributed to the same temporary account.Temporary account holders will also be able to receive talk page notifications just like registered users.We hope this will allow for better communication with temporary users.It may also resolve some long-standing issues raised by the communities (see T278838).
Documenting IP addresses for vandals
It will be possible to document IP addresses for bad actors publicly through long-term abuse pages, as currently.However, care should be taken to not expose IP addresses for other temporary users.When discussing possible bad actors, tools like suppression should be used if the user is not found to be a vandal as suspected.More details about this can be found in the guidelines.
We are developing guidelines for Cloud tools and bots to access IPs for patrolling.We will have an update for this soon.
サイト上の既存のIPアドレスはどうなる？
Existing IP addresses that are already recorded on our wikis will remain untouched.Edits that come in after IP Masking will be attributed to temporary usernames.Since we will roll out IP Masking gradually, this will mean that this change will happen on different wikis at different times.
How will the IP address reveal functionality work?
Users who can access IP addresses will be able to expose IP addresses for temporary accounts.Mockups for how this functionality would work:
What will happen to tools and bots that rely on IP addresses to function?
We are working to understand the impact to volunteer-maintained tools.This is a task for our team as well as the Research and Engineering teams.Next, we will work with Legal to understand which tools may continue to access IP addresses and the guidelines for how they can operate.We will provide an update on this page once we have a plan of action.
ロールアウト計画
We plan to test IP Masking slowly, to include ample time for communities' feedback and testing.We want our rollouts not to hinder communities' processes.Our another priority is to avoid undesirable outcomes for the health of the communities.We have implemented metrics that we plan to watch as we roll out the changes.
We are looking for communities that would be candidates for testing launch (piloting) of IP Masking.We are considering criteria such as number of IP edits the communities receive, urgency of anti-vandalism work, size of the project, and potential for disruption.We will have another update on this page about our chosen candidates closer to the launch of IP Masking.If you'd like your community to test the launch of IP Masking, please make a decision as a community and let us know on the talk page.
: Refocusing work on IP Masking
Hi all. We’re officially refocusing our work on the core IP Masking project, now that we have completed the first phase on IP Info feature and other related projects. We are moving forward with technical planning to understand what will need to change when IP Masking goes into effect. We will be reaching out to our technical volunteers to help evaluate changes and migrate tools, as needed. Some of this planning work has already started on Phabricator, and you may reach out to us there if you have questions about specific tasks.
I will follow this up with another post shortly to share an outline of the MVP (Minimum Viable Product) we have landed on. This MVP is based on the conversations we have had with the community in the past, through this page and other mediums. Please feel free to peruse those previous conversations and read through the past updates on this page. If you have questions or concerns, you can reach out to us on the talk page.
小規模ウィキの場合、IP 基準の取り組みの方が向いていて、別人の利用者ふたりが同一の IP を使うとは考えにくく、IP アドレスを操作する荒らしでクッキーを除去したなら最も対処が難しい。
セッション単位のシステムの方が有効に思えるし、匿名編集者との連絡には使いやすいです。私個人は英語版ウィキペディアの管理者として、IP 編集者とのやりとりの中心は荒らしの巻き戻しと警告をしています。最近のいくつかの事案では、受信者が果たして当該の人物かどうか疑わしかったため、わざわざ警告することすら留意しませんでした。別の一件ですと、特定の変更の提案について協議をしようとしたところ、複数の IP アドレス利用者との対話になり、対話の相手にそのことを確認したものの、同一の人物を相手にしているのかさえ不明のままで終始しました。
ドイツ語版ウィキペディアの管理者をしているのですが、ここに示された2案（IP アドレスを基準とする識別 VS セッション単位の識別）について、明確に前者を支持します。ブラウザのプライベートモードを使ったりクッキーを除去したりするのは簡単ですから（私自身、いつもそうやっています。）IP アドレスの変更には、少なくとももう少し手間がかかるし、すでにオープンプロキシの利用禁止は方針に決めてあります。Beland はセッション単位の検証方法の方が、善意の匿名利用者との連絡がしやすいと言っており、その点は賛成しますが、それだけでは論拠として十分ではないです。
セッション単位の方法がよいです。匿名利用者で規定を守っている人（legitimate）を特定して連絡を取るのに役に立つからです。それでも、これは同時に荒らしフィルタにオプションを作って、単一の IP アドレスから発信した複数の新規セッションを検出できるようになりませんか。それらは規定を守ったかもしれないけれど（例えば発信地が学校）、ほぼ荒らしまたはボットの活動でしょう。もう一つ、誰も言及していなさそうな機能について述べておきます。特定のセッション利用者がアカウント登録を希望するとき、新規に選んだ利用者名は、既定としてそれまでのセッション ID の改名手続によって付けるべきだという点です。新しく利用者名付きになっても、それまでのセッションの活動を閲覧し、そして／またはその利用者と関連づけることが私たちには必要だからです。
A：現状では、アカウント未登録の編集者の識別は IP アドレスを基準にしています。この方式はこれまで、私たちのプロジェクト群で長年、有効でした。IP アドレスに精通した利用者の皆さんは、単一の IP アドレスの帯域幅に制限されるものの、複数の異なる利用者が使うことを理解しています。この条件は IPv6 に関して、IPv4 よりもさらに当てはまります。
Hi everyone. It has been a few months since our last update on this project. We have taken this time to talk to a lot of people — across the editing community and within the Foundation. We have put careful consideration towards weighing all the concerns raised in our discussions with experienced community members about the impact this will have on anti-vandalism efforts across our projects. We have also heard from a significant number of people who support this proposal as a step towards improving privacy of unregistered editors and reducing the legal threat that exposing IPs to the world poses to our projects.
When we talked about this project in the past, we did not have a clear idea of the shape this project will take. Our intention was to understand how IP addresses are helpful to our communities. We have since received a lot of feedback on this front from a number of conversations in different languages and in different communities. We are very grateful to all the community members who took the time to educate us about how moderation works on their wikis or in their specific cross-wiki environment.
We now have a more concrete proposal for this project that we hope will allow for most of the anti-vandalism work to happen undeterred while also restricting access to IP addresses from people who don’t need to see them.I want to emphasize the word “proposal” because it is in no way, shape or form a final verdict on what will happen. Our intention is to seek your feedback about this idea – What do you think will work? What do you think won’t work? What other ideas can make this better?
Checkusers, stewards and admins should be able to see complete IP addresses by opting-in to a preference where they agree not to share it with others who don't have access to this information.
Editors who partake in anti-vandalism activities, as vetted by the community, can be granted a right to see IP addresses to continue their work. This could be handled in a similar manner as adminship on our projects. The community approval is important to ensure that only editors who truly need this access can get it. The editors will need to have an account that meets some threshold of time since registration (threshold is yet to be decided) and number of edits (number is yet to be decided).
All users with accounts that meet some threshold of time since registration (threshold is yet to be decided) and number of edits (number is yet to be decided) will be able to access partially unmasked IPs without permission. This means an IP address will appear with its tail octet(s) – the last part(s) – hidden. This will be accessible via a preference where they agree not to share it with others who don't have access to this information.
All other users will not be able to access IP addresses for unregistered users.
IP address access will be logged so that due scrutiny can be performed if and when needed. This is similar to the log we maintain for checkuser access to private data. This is how we hope to balance the need for privacy with the communities’ need to access information to fight spam, vandalism and harassment. We want to give the information to those who need it, but we need a process, we need it to be opt-in so that only those with an actual need will see it and we need the accesses to be logged.
We would like to hear your thoughts about this proposed approach. Please give us your feedback on the talk page.
IPアドレス基準の識別の画面キャプチャ
セッション基準の識別の画面キャプチャ
.png)