: Successful deployment on minor pilots and progress on the features
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.
As planned, at the end of October and in the first days of November, we launched Temporary Accounts to 12 projects. We are happy to report that we did not encounter any issues that required us to roll back the deployment. There is a lot of activity from temporary accounts on these projects. We are currently collecting detailed data, and will publish a report with our findings about it in the coming weeks. We will also be running a survey to better understand the impact of this rollout on users with advanced rights. Many thanks to the communities of the pilot wikis, stewards, CheckUsers, and global sysops for their openness, good questions, and ideas for changes.
We are implementing an onboarding dialog box to help registered users understand temporary accounts and associated features. The dialog box will introduce the concept of temporary accounts, the IP Info tool with the IP reveal feature, and more. (T373818)
A mockup of AutorevealWe have decided to implement an "auto-reveal" feature. It will allow selected functionaries to view all IP addresses, for all temporary accounts in a defined period of time. This feature will help functionaries respond quickly to abuse, for example vandalism events that require checking a lot of IP addresses. We are currently defining the typical tasks and designs for this feature. We will be grateful if you share your thoughts about Autoreveal in this Phabricator task. The decision to build it was based on our discussions with stewards and other users with extended rights, and we would like to thank them again for their continued involvement and invaluable advice.
Special:GlobalContributions will be able to display information about cross-wiki contributions from registered users, IP addresses, IP ranges, and temporary accounts in the near future. (T375632)
: 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.
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 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.
: Deployment plan is ready!
: 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.
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.
Cập nhật cũ hơn
: 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.
: New features, new names, and Wikimania
Wikimania slide deck
Project updates
Temporary account names format.The format of the temporary account names will be ~YYYY-nnnnn-nnn.YYYY refers to the year when the temporary account was created.The n-sequence represents the unique identifier of the temporary username.For example, a temporary account created in 2023 may look like: ~2023-27459-041.The year prefix helps identify how old a temporary account may be.This provides information for patrollers or anyone looking to communicate with the editor.We took the decision after discussions on the wiki talk page and on Phabricator (T337103).Many thanks to everyone who took part in those conversations!
Team changes and projected timeline for first deployments. The Anti-Harassment Tools team has been merged with the Trust and Safety Tools team.The newly formed team is called Trust and Safety Product.It will have an expanded scope.This change to the structure may have an effect on the timeline of this project.We will have more updates to share as we develop a roadmap for the new team.Our current projected timeline for this project is as follows:
Deployment to testwiki – January 2024
Deployment to first pilot wikis – beginning March 2024
Frequently asked questions page. We have created the frequently asked questions (FAQ) page.We will expand and update it in the coming weeks and months.
Wikimania update and the project name change.At Wikimania in Singapore, we presented an update on the project.You can access the slide deck for the presentation.There's also a recording of the full presentation available on YouTube.At Wikimania, we were using the former project name, IP Masking.After that, we decided to change it into Temporary accounts for unregistered editors, or simply Temporary accounts.It presents our changes in a plain language, without a technical metaphor.
New features
Global blocking. We will work on global blocking for registered and temporary users.Currently, global blocking only works for IP addresses and ranges.There has been a long-standing request to expand this feature to allow blocking users, too.We will be defining this feature and developing it over the next couple of months.You may follow the Phabricator task (T17294) for updates.
Global User Contributions. We will bring the Global User Contributions feature to MediaWiki.This feature currently exists through the GUC tool.Our change will make it easier for users to view contributions from accounts across projects.It will be possible via a special page.This will be particularly useful when temporary accounts go into effect.For technical details, see T337089.
: Kế hoạch ẩn địa chỉ IP
Như đã được hứa, đây là một cập nhật về cách ẩn địa chỉ IP hoạt động.
Nó sẽ bao hàm thay đổi cho cả thành viên chưa đăng ký và đã đăng ký.
Chúng tôi cũng muốn thừa nhận về việc chúng tôi vẫn còn rất nhiều câu hỏi mở và những thứ mà chúng tôi vẫn chưa quyết định.
Đây là kế hoạch ban đầu của chúng tôi và không bao hàm tất cả mọi thứ chúng tôi định thực hiện trong dự án này.
Trong khi chúng tôi cũng đang thực hiện, chúng tôi vẫn đang tìm thấy khá nhiều thứ việc chưa được nhận ra.
Phản hồi của các bạn sẽ giúp chúng tôi hiểu được chúng tôi có thể làm được gì để khiến việc ẩn địa chỉ IP trở nên dễ dàng đến với cộng đồng của chúng ta.
Cập nhật này sẽ theo định dạng một FAQ để khiến cho những thay đổi sắp tới rõ ràng và dễ hiểu hơn.
Việc ẩn địa chỉ IP sẽ thay đổi thế nào dưới góc nhìn của thành viên chưa đăng nhập?
Hiện nay, trước khi một thành viên chưa đăng nhập thực hiện một sửa đổi, họ sẽ được thông báo là sửa đổi của họ sẽ được ghi cho địa chỉ IP của họ.
Trong tương lai, trước khi một thành viên chưa đăng nhập thực hiện sửa đổi, họ sẽ được thông báo là sửa đổi của họ sẽ được ghi cho một tài khoản tạm thời.
Tên của nó sẽ là một con số, tăng dần theo các tài khoản mới.
Tài khoản này sẽ được kéo theo dạng một cookie mà dựng ở trong trình duyệt thành viên đó.
Chỉ cần khi cookie còn tồn tại, thành viên này vẫn sẽ giữ tên tài khoản tạm thời, và các sửa đổi của họ sẽ được gán cho tài khoản đó.
Địa chỉ IP của thành viên này có thể thay đổi, nhưng tài khoản tạm thời này sẽ giữ nguyên chỉ cần khi cookie đó tồn tại.
Một tài khoản tạm thời được tạo ở một wiki có thể vẫn sẽ hoạt động ở các wiki khác mà thành viên này có thể đóng góp.
Tên người dùng tạm thời sẽ như thế nào?
Chúng tôi vẫn chưa biết.
Những thử nghiệm của ban đầu sử dụng một dấu hoa thị là một tiền tố tiếp tục với một số tăng tự động.
(Ví dụ: *12345.)
Bạn sẽ nhìn thấy những thử nghiệm ở dưới.
Nhưng khi một số các tình nguyện viên phát hiện ra, dấu hoa thị này không phải là một lựa chọn tốt bởi vì một lỗi phần mềm MediaWiki.
Chúng tôi vẫn đang thảo luận về những tuỳ chọn tiền tố và sẽ thực hiện thử nghiệm người dùng với chúng.
Những ứng viên hiện nay (với không có thứ tự nào) là:
Bạn có thấy những cái dấu này là một sự lựa chọn hợp lý hay tệ hại?
Hãy thêm bình luận của bạn hoặc ở trong trang thảo luận hoặc Phabricator.
↑(Trong khi dấu hỏi này là một dấu chỉ cho một thứ không biết mà vẫn đang được hiểu rõ, vẫn còn những dữ liệu mà chúng tôi vẫn đang suy nghĩ. Ví dụ, nó sẽ phải được mã hoá trong URL sử dụng %3F. Việc mã hoá URL này sẽ không phải là một vấn đề, nhưng nó cũng được coi là một thứ khó chịu với những ai quen với việc điền URL bằng tay.)
Các tên thành viên tạm thời sẽ tồn tại trong bao lâu?
Một khoảng thời gian sau sửa đổi đầu tiên (thông thường là một năm) hay là kết quả của việc xoá bộ nhớ đệm, cookie sẽ tự động hết hạn.
Tuy nhiên, các sửa đổi ban đầu vẫn sẽ được ghi vào nó.
Sau khi tên cũ hết hạn, nếu thành viên này sửa đổi lại lần nữa trong tương lai, họ sẽ được cấp một tài khoản tạm thời khác.
Việc ẩn địa chỉ IP sẽ thay đổi thế nào dưới góc nhìn của một tuần tra viên?
Giới hạn việc nhìn địa chỉ IP
Mức thay đổi lớn nhất chính là địa chỉ IP sẽ không còn được công khai trước công chúng nữa.
Bất kỳ ai mà chưa có tài khoản hoặc chưa có đủ những yêu cầu cần thiết cho việc nhìn thấy IP (xem Cập nhật Luật pháp) sẽ không thể nhìn thấy địa chỉ IP.
Để giảm ảnh hưởng của nó đến việc tuần tra, chúng tôi sẽ đưa ra những cải thiện cho Tính năng thông tin IP.
Nó cũng sẽ bao hàm dữ liệu từ dịch vụ Spur.
Cấp được quyền truy cập địa chỉ IP
Cùng với nhóm Lập pháp của Quỹ Wikimedia, chúng tôi cũng đã phát triển những hướng dẫn mới.
Chúng sẽ định ra ai có thể truy cập vào địa chỉ IP và làm thế nào.
Những người mà đạt được yêu cầu sẽ có thể được đồng ý để nhìn ra địa chỉ IP qua Đặc biệt:Tuỳ chọn.
Xem chi tiết thêm tính năng phát hiện địa chỉ IP sẽ hoạt động.
Quá trình truy cập và nhận dạng IP sẽ được ghi lại và chỉ được xem bởi một nhóm người nhất định (CheckUsers, tiếp viên, Trust & Safety).
Những kênh kết nối tốt hơn với biên tập viên tạm thời
Các tài khoản tạm thời sẽ được liên kết với một cookie trình duyệt.
Chỉ cần khi cookie này còn tồn tại, sửa đổi của người dùng cũng sẽ được gán cho cùng tài khoản tạm thời đó.
Những người có tài khoản tạm thời cũng có thể nhận được tin nhắn thảo luận như là thành viên thông thường.
Hy vọng nó sẽ cho phép kết nối tốt hơn đối với thành viên tạm thời.
Nó cũng có thể xử lý được một số vấn đề lâu dài được đưa ra bởi cộng đồng (xem T278838).
Ghi nhận địa chỉ IP cho kẻ phá hoại
Cũng sẽ có thể ghi chú các địa chỉ IP cho những kẻ xấu một cách công khai như trong các trang rối phá hoại dai dẳng, như hiện nay.
Tuy nhiên, những sự quan tâm đặc biệt vẫn cần được đưa ra để không lộ địa chỉ IP cho các thành viên thường khác.
Khi thảo luận về những thành viên xấu, những công cụ như triệt phiên bản nên được dùng nếu thành viên này không phải là một kẻ phá hoại như nghi ngờ.
Những chi tiết thêm về nó có thể được nhìn thấy tại hướng dẫn.
Chúng tôi vẫn đang xây dựng hướng dẫn cho các công cụ đám mây và robots để truy cập IP cho việc tuần tra.
Chúng tôi sẽ cập nhật thêm về vấn đề này trong thời gian sớm nhất.
Điều gì sẽ xảy ra với các địa chỉ IP còn tồn tại trong trang web của chúng tôi?
Những địa chỉ IP mà đã được ghi lại trên wiki của chúng tôi sẽ vẫn giữ y như thế.
Tuy nhiên, những sửa đổi xuất hiện sau việc ẩn địa chỉ IP sẽ được ghi cho tài khoản tạm thời.
Do chúng tôi sẽ đưa việc ẩn IP dần dần, điều đó có nghĩa là những thay đổi sẽ diễn ra ở các wiki khác nhau trong thời gian khác nhau.
Làm thế nào để tính năng lộ địa chỉ IP hoạt động?
Những thành viên mà có thể truy cập địa chỉ IP cũng sẽ có thể được nhìn thấy địa chỉ IP cho thành viên tạm thời.
Những cách mẫu mà tính năng này có thể hoạt động:
Điều gì xảy ra đối với những công cụ và bot phụ thuộc vào địa chỉ IP để hoạt động?
Chúng tôi vẫn đang nỗ lực tìm hiểu hệ quả tới những công cụ quản lý bởi các tình nguyện viên.
Đây là một công việc cho nhóm của chúng tôi cũng như là Nhóm nghiên cứu và chế tạo.
Sau đó, chúng tôi sẽ làm việc với Nhóm Pháp luật để có hiểu được những công cụ nào vẫn sẽ tiếp tục được truy cập địa chỉ IP và những hướng dẫn để nó hoạt động.
Chúng tôi sẽ đưa ra những cập nhật trong trang này sau khi chúng tôi có phương hướng hoạt động.
Kế hoạch triển khai
Chúng tôi sẽ thử nghiệm từ từ việc ẩn IP, để cho thời gian để cộng đồng có thể phản hồi và thử nghiệm.
Chúng tôi muốn việc triển khai này không làm chậm hoạt động của cộng đồng.
Một thứ ưu tiên khác là để có thể hạn chế những kết quả không có lợi cho sức khoẻ cộng đồng.
Chúng tôi cũng đang cố gắng thực hiện những thước đo mà chúng tôi xem xét khi triển khai thay đổi.
Chúng tôi cũng đang tìm kiếm cộng đồng mà có thể là những ứng viên cho việc kiểm thử (dự án đầu tiên) của việc ẩn IP.
Chúng tôi cũng đang đánh giá những tiêu chí như số lượng sửa đổi IP mà cộng đồng này nhận được, sự cấp thiết của việc chống phá hoại, kích cỡ dự án và khả năng gây xung đột.
Chúng tôi cũng sẽ có một cập nhật trong trang này về các ứng viên gần với ngày triển khai việc ẩn IP.
Nếu bạn mong muốn cộng đồng của bạn tham gia thử nghiệm việc ẩn IP, hãy tạo ra một lựa chọn theo cộng đồng và hãy cho chúng tôi biết ở trang thảo luận.
<span id=":_Refocusing_work_on_IP_Masking">
: Tập trung lại công việc cho việc ẩn IP
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.
: Implementation Strategy and next steps
Hello all. We have an update on the IP Masking implementation strategy.
First off, thank you to everyone who arrived on this page and offered their feedback. We heard from a lot of you about how this page is not easy to read and we are working on fixing that. We genuinely want to thank you for taking the time to go through the information here and on the talk page. We took every comment on the talk page into consideration before the decision about the implementation plan was made.
We want to preface this also by saying that there are still a lot of open questions. There is a long road ahead of us on this project and we would like you to voice your opinion in more of these discussions as they come up. If you haven’t already, please go through this post about who will continue to have IP address access before reading further.
We received mixed feedback from the community about the two proposed implementation ideas without a clear consensus either way. Here are some quotes taken from the talk page:
For small wikis, I think the IP based approach is better because it is unlikely that two anonymous users will have the same IP, and for a vandal modifying its Ip is most difficult that erasing cookies.
The session-based system does seem better, and would make it easier to communicate with anonymous editors. I'm an admin on English Wikipedia, and my main interaction with IP editors is reverting and warning them against vandalism. In several cases recently I haven't even bothered posting a warning, since it seems unlikely the right person would receive it. In one case I was trying to have a conversation about some proposed change, and I was talking to several different IP addresses, and it was unclear that it was actually the same person, and I had to keep asking them about that.
As an admin in German-language Wikipedia, of the two paths described here (IP based identity vs. session-based identity) I clearly prefer the IP based approach. It's just too easy to use a browser's privacy mode or to clear the cookies (I'm doing it myself all the time); changing your IP address at least requires a bit more effort, and we have already a policy against using open proxies in place. I agree with Beland that the session-based identity approach could probably make communication with well-meaning unregistered editors easier, but it just doesn't seem robust enough.
I prefer the session-based approach. It provides more value in being able to identify and communicate with legitimate anonymous editors. However, at the same time, we need abuse filter options to be able to identify multiple new sessions from a single IP. These could be legitimate (from a school, for example), but will most likely represent abuse or bot activity. One feature I haven't seen mentioned yet. When a session user wants to create an account, it should default to renaming the existing session ID to the new name of their choice. We need to be able to see and/or associate the new named user with their previous session activity.
I am leaning towards the IP-based identities, even if encrypted, as cookies seem more complicated to deal with and very bothersome to keep shutting their annoying pop-ups (very standard in Europe). I have to mention that I prefer that till this day, one could use Wikipedia without cookies, unless he wants to log in to edit with his username.
The ability to perform purely session-based blocks in addition to the existing IP+session blocking would be an interesting upgrade. Being able to communicate with IPv6 users through their session instead of their repeatedly changing IP address would also be a benefit.
In summary, the main argument against the session-based approach was that cookies are easy to get rid of and the user may change their identity very easily.
And the main arguments against the IP-based approach were:
the encryption method can be compromised, hence compromising the IP addresses themselves
this approach does not provided the benefit of improved communication with the unregistered editors
does not allow for session-based blocking (in addition to IP based blocking)
In light of the above and the discussions with our technical team about the feasibility and wide-ranging implications of this implementation, we have decided to go with the session-based approach with some important additions to address the problem of users deleting their cookies and changing their identity. If a user repeatedly changes their username, it will be possible to link their identities by looking at additional information in the interface. We are still working out the details of how this will work – but it will be similar to how sockpuppet detection works (with some automation).
We are working out a lot of the technical details still and will have another update for you shortly with more specifics. This includes LTA documentation, communication about IPs, AbuseFilters, third-party wikis, gadgets, user-scripts, WMF cloud tools, restrictions for IP-viewer rights etc. We appreciate your input and welcome any feedback you may have for us on the talk page.
: IP Masking and changes to workflows
Chúng tôi đã thảo luận về hai cách tiếp cận khác nhau để ẩn đi IP mà chúng tôi đang xem xét. Sau đó, chúng tôi đã đưa ra một vài quy trình ẩn địa chỉ IP khác nhau và chúng sẽ thay đổi như thế nào với hai cách thực hiện khác nhau.
Lưu ý rằng trong cả hai cách lựa chọn khác nhau, bảo quản viên, tiếp viên, kiểm định viên và người dùng có quyền IPViewer sẽ có thể hiển thị IP trên các trang như Thay đổi gần đây và Lịch sử trang cho mục đích chống phá hoại.
Trải nghiệm sửa đổi cho các thành viên chưa đăng ký
Biểu hiện hiện tại: Hiện nay, các thành viên chưa đăng ký có thể sửa đổi mà không cần đăng nhập (trên hầu hết các wiki). Trước khi thực hiện sửa đổi, họ sẽ thấy một biểu ngữ cho họ biết rằng địa chỉ IP của họ sẽ được ghi lại công khai và được xuất hiện vĩnh viến.
Danh tính dựa trên địa chỉ IP: Những biên tập viên chưa đăng ký sẽ có thể chỉnh sửa như hiện tại. Trước khi thực hiện sửa đổi, họ sẽ thấy một thông báo cho họ biết rằng các sửa đổi của họ sẽ được quy cho một phiên bản địa chỉ IP được mã hóa của họ. Bản thân địa chỉ IP gốc sẽ chỉ được hiển thị cho quản trị viên và tuần tra viên. Nó sẽ chỉ được giữ lại trong một khoảng thời gian nhất định nào đó.
Danh tính dựa trên phiên sửa đổi: Điều này tương tự như trên, ngoại trừ người chỉnh sửa sẽ được thông báo rằng các chỉnh sửa của họ sẽ được quy cho một tên người dùng được tạo tự động.
Ảnh chụp màn hình xác định danh tính bằng IP
Ảnh chụp màn hình xác định danh tính bằng phiên
Liên lạc với thành viên chưa đăng ký
Biểu hiện hiện tại: Những biên tập chưa đăng ký được gọi bằng địa chỉ IP của họ hoặc nếu họ là kẻ phá hoại dai dẳng mà đã được biết, họ có thể được đặt tên dựa trên hành vi của họ.
Danh tính dựa trên địa chỉ IP: Tuần tra viên và bảo quản viên sẽ không thể đề cập đến địa chỉ IP một cách công khai nhưng sẽ có thể tham chiếu đến địa chỉ IP được mã hóa của họ hoặc tên kẻ phá hoại dai dẳng. Họ có thể chia sẻ địa chỉ IP cho những người khác có quyền truy cập vào nó.
Danh tính dựa trên phiên sửa đổi: Tuần tra viên và bảo quản viên sẽ không thể nhắc đến công khai địa chỉ IP nhưng sẽ có thể tham chiếu đến tên người dùng được tạo tự động của họ. Họ có thể chia sẻ địa chỉ IP với những người khác có quyền truy cập vào nó. Điều này có thể giúp xác định một thành viên, nhưng cũng có thể gây nhầm lẫn nếu có nhiều IP đứng sau một tên người dùng, tương tự như số người có thể sử dụng chung một IP ngày nay. Để giảm bớt mối lo ngại này, chúng tôi đang xây dựng một công cụ có thể đưa ra thêm thông tin về tất cả các địa chỉ IP khác nhau mà một biên tập viên đang hoạt động.
Trải nghiệm trang thảo luận cho các thành viên chưa đăng ký
Biểu hiện hiện tại: Một biên tập viên chưa đăng ký có thể nhận tin nhắn trên trang thảo luận về IP của họ. Sau khi địa chỉ IP của người biên tập thay đổi, họ sẽ nhận được thông báo trên trang thảo luận về địa chỉ IP mới. Điều này có thể làm chia nhỏ các cuộc trò chuyện và gây khó khăn cho việc liên lạc với các biên tập viên chưa đăng ký.
Danh tính dựa trên địa chỉ IP: Trong cách thực hiện này, biểu hiện vẫn giống như hiện tại. Các biên tập viên chưa đăng ký sẽ nhận được tin nhắn trên các trang thảo luận IP được mã hóa của họ và khi IP của họ thay đổi, trang thảo luận liên quan của họ cũng thay đổi theo.
Danh tính dựa trên phiên sửa đổi: Trong cách thực hiện này, các biên tập viên chưa đăng ký sẽ nhận được thông báo trên một trang thảo luận được liên kết với cookie trên trình duyệt của họ. Ngay cả khi địa chỉ IP của họ thay đổi, điều đó vẫn cho phép họ nhận tin nhắn trên trang thảo luận của họ. Nếu cookie trình duyệt của họ bị xóa, họ không còn giữ lại danh tính theo phiên sửa đổi của mình nữa và sẽ nhận được một cookie mới và một trang thảo luận mới được liên kết với nó. Vì IP thay đổi thường xuyên hơn cookie, có khả năng nhiều người dùng sẽ kết thúc với một trang thảo luận bán cố định trừ khi họ đặc biệt cố gắng không làm như vậy. Một ưu điểm khác cần lưu ý là các tin nhắn trên trang thảo luận sẽ không còn bị nhận nhầm trong bất kỳ trường hợp nào.
Thông báo trang thảo luận
Cấm thành viên chưa đăng ký
Biểu hiện hiện tại: Một bảo quản viên có thể cấm trực tiếp một địa chỉ IP hoặc dải IP. Ngoài ra, họ có thể biến nó thành một cấm tự động có thể giữ lại cookie trên trình duyệt của người dùng bị cấm, ngăn họ chỉnh sửa ngay cả khi họ thay đổi địa chỉ IP. Chức năng này đã được giới thiệu khoảng vài năm gần đây.
Danh tính dựa trên địa chỉ IP: Biểu hiện vẫn giữ nguyên như hiện nay. Các địa chỉ IP đều được ẩn đi theo mặc định, nhưng bảo quản viên hay tuần tra viên có quyền cho phép vẫn có thể truy cập chúng.
Danh tính dựa trên phiên sửa đổi: Việc triển khai này cho phép chúng tôi giữ lại việc cấm theo địa chỉ IP hiện tại. Nó cũng cho phép chúng tôi chỉ thực hiện các tác vụ cấm sửa đổi theo cookie. Điều này có thể hữu ích trong một số trường hợp khi mọi người chia sẻ thiết bị (như thư viện hoặc một quán cafe) và việc cấm một địa chỉ IP hoặc dải địa chỉ IP có thể gây ra những sự cản trở không cần thiết. Tôi muốn chỉ ra rằng điều này sẽ không hoạt động được trong trường hợp những kẻ phá hoại là những người biên tập viên có kinh nghiệm và có thể trốn tránh việc cấm bằng cookie.
: IP Masking Implementation Approaches FAQ
Danh sách các câu hỏi thường gặp này giúp trả lời một số câu hỏi có thể xảy ra mà cộng đồng sẽ có về các phương pháp triển khai khác nhau mà chúng tôi có thể thực hiện đối với việc ẩn địa chỉ IP và mỗi phương pháp hoạt động trên sẽ tác động đến cộng đồng như thế nào.
Q: Sau khi thực hiện việc ẩn đi địa chỉ IP, ai sẽ có thể nhìn thấy địa chỉ IP?
A: Kiểm định viên, tiếp viên và bảo quản viên sẽ có thể nhìn thấy đầy đủ các địa chỉ IP bằng cách đồng ý vào một tùy chọn mà họ đồng ý không chia sẻ nó với những người không có quyền truy cập vào thông tin này.
Các biên tập viên tham gia vào các hoạt động chống phá hoại, được cộng đồng tin cậy, vẫn có thể được cấp quyền xem địa chỉ IP để tiếp tục công việc của họ. Quyền người dùng này sẽ được cộng đồng xử lý giống như các quyền người dùng khác và yêu cầu số lần sửa đổi tối thiểu và số ngày tham gia.
Tất cả người dùng có tài khoản trên một thời gian nhất định và có số lần chỉnh sửa tối thiểu (sẽ được xác định) sẽ có thể truy cập vào các IP được hiển thị một phần mà không được cho phép. Điều này có nghĩa là một địa chỉ IP sẽ xuất hiện với những phần đuôi của nó bị ẩn. Địa chỉ này sẽ có thể được truy cập qua một tùy chọn mà họ đồng ý không chia sẻ nó với những người khác không có quyền truy cập vào thông tin này.
Tất cả các thành viên còn lại sẽ không thể truy cập địa chỉ IP cho thành viên chưa đăng ký.
Q: Đâu là những lựa chọn thực hiện về mặt kỹ thuật?
A: Trong vài tuần qua, chúng tôi đã tham gia vào nhiều cuộc thảo luận về các khả năng thực hiện kỹ thuật để đạt được mục tiêu của chúng tôi về việc ẩn đi địa chỉ IP đồng thời giảm thiểu tác động đến các biên tập viên và độc giả của chúng tôi. Chúng tôi đã thu thập được những phản hồi từ các nhóm khác nhau và thu được những quan điểm khác nhau. Dưới đây là hai hướng đi chính.
Danh tính dựa trên địa chỉ IP: Theo cách tiếp cận này, chúng tôi giữ nguyên mọi thứ nhưng thay thế các địa chỉ IP hiện có bằng một phiên bản IP được băm lại. Điều này bảo vệ rất nhiều các quy trình công việc hiện có của chúng tôi nhưng không cung cấp bất kỳ lợi ích mới nào.
Danh tính dựa trên phiên truy cập: Theo cách tiếp cận này, chúng tôi tạo một danh tính cho những biên tập viên chưa đăng ký dựa trên cookie trình duyệt mà xác định trình duyệt trên thiết bị của họ. Cookie vẫn tồn tại ngay cả khi địa chỉ IP của họ thay đổi do đó phiên của họ không kết thúc.
Q: Làm cách nào mà hướng đidanh tính dựa trên địa chỉ IP hoạt động?
A: Hiện nay, các biên tập viên chưa đăng ký được xác định bằng địa chỉ IP của họ. Mô hình này đã hoạt động thành công trong các dự án của chúng tôi trong nhiều năm qua. Những người dùng thông thạo về địa chỉ IP hiểu rằng một địa chỉ IP duy nhất có thể được dùng bởi nhiều người dùng khác nhau dựa trên mức độ di động của địa chỉ IP đó. Điều này đúng với địa chỉ IP IPv6 hơn IPv4.
Người dùng chưa đăng ký cũng có thể thay đổi địa chỉ IP của mình nếu họ đang đi lại hoặc sửa đổi từ một vị trí khác.
Nếu chúng tôi vẫn theo đuổi giải pháp nhận dạng dựa trên IP bằng cách ẩn địa chỉ IP, chúng tôi vẫn sẽ duy trì cách thức hoạt động của địa chỉ IP ngày nay bằng cách chỉ cần che chúng bằng một số nhận dạng đã được mã hóa. Giải pháp này sẽ giữ các IP trở nên riêng biệt trong khi vẫn duy trì các quyền riêng tư của người dùng. Ví dụ: người dùng chưa đăng ký như Thành viên:192.168.1.2 có thể được xuất hiện dưới dạng Thành viên:ca1f46.
Lợi ích của hướng đi này:
Duy trì các quy trình và mô hình công việc hiện nay với sự gián đoạn tối thiểu
Bất lợi của hướng đi này:
Không mang lại bất kỳ lợi ích nào trong một thế giới đang chuyển dịch nhanh chóng sang việc các địa chỉ IP trở nên chuyển dịch nhiều hơn/ít hữu ích hơn
Q: Làm cách nào mà hướng đidanh tính dựa trên phiên truy cập hoạt động?
A: Hướng đi là tạo một danh tính mới cho những người chỉnh sửa chưa đăng ký dựa trên một cookie được đặt trong trình duyệt của họ. Trong cách tiếp cận này, có một tên người dùng được tạo tự động mà các sửa đổi và hoạt động của họ được gán cho. Ví dụ: Thành viên:192.168.1.2 có thể được cấp tên người dùng: Thành viên:Anon3406.
Theo cách tiếp cận này, phiên của người dùng vẫn sẽ tồn tại miễn là họ có cookie truy cập, ngay cả khi họ thay đổi địa chỉ IP.
Lợi ích của hướng đi này:
Liên kết danh tính người dùng với một trình duyệt thiết bị, cung cấp một cách liên lạc lâu dài hơn với họ.
Danh tính người dùng không thay đổi khi chỉnh địa chỉ IP
Cách tiếp cận này có thể đưa cho ta một cách để những biên tập viên chưa đăng ký có quyền truy cập vào các tùy chọn nhất định mà hiện nay chỉ có sẵn cho người dùng đã đăng ký
This approach can offer a way for unregistered editors to convert to a permanent account while retaining their edit history
Drawbacks of this approach:
Significant change in the current model of what an unregistered editor represents
The identity for the unregistered editor only persists as long as the browser cookie does
Vandals in privacy mode or who delete their cookies would get a new identity without changing their IP
May require rethinking of some community workflows and tools
Q: Does the Foundation have a preferred path or approach?
A: Our preferred approach will be to go with the session-based identity as that will open up a lot of opportunities for the future. We could address communication issues we’ve had for twenty years. While someone could delete the cookie to get a new identity, the IP would still be visible to all active vandal fighters with the new user right. We do acknowledge that deleting a cookie is easier than switching an IP, of course, and do respect the effects it would have.
: Proposal for sharing IP addresses with those who need access
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?
We developed these ideas during several discussions with experienced community members, and we’ve refined them in collaboration with our Legal department. Here’s the outline:
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.
Ảnh chụp màn hình xác định danh tính bằng IP
Ảnh chụp màn hình xác định danh tính bằng phiên
.png)