ویرایش با آی‌پی: بهبود حریم خصوصی و کاهش سوءاستفاده
آی‌پی ماسکینگ چیست و چرا بنیاد ویکی‌مدیا آدرس‌های آی‌پی‌ها را مخفی می‌کند؟
آی‌پی ماسکینگ باعث مخفی شدن آدرس آی‌پی کاربران غیرثبت‌نامی در پروژه‌های ویکی‌مدیا، به صورت کامل یا جزئی، از همه می‌شود؛ به جز افرادی که نیاز به دسترسی دارند تا در برابر هرزنامه، خرابکاری، آزاردهندگی و اطلاعات نادرست بجنگند.
در حال حاضر، هر کسی می‌تواند بدون داشتن حساب کاربری در ویکی‌های ویکی‌مدیا یا بدون ورود به سیستم، ویرایش‌هایی را انجام دهد. نرم‌افزار مدیاویکی که پشت پروژه‌های ویکی‌مدیا قرار دارد، آدرس آی‌پی شما را در سیاهه عمومی خود ثبت و منتشر می‌کند. هر کسی که به دنبال آدرس آی‌پی شماست، آن را پیدا خواهد کرد.
پروژه‌های ویکی‌مدیا دلیل قابل قبولی برای ذخیره و منتشر کردن آدرس‌های آی‌پی دارند: آن‌ها نقش بسیار مهمی در جلوگیری از خرابکاری و آزاردهی در ویکی‌های ما ایفا می‌کنند.
با این حال، آدرس آی‌پی شما می‌تواند مکان ویرایش شما را نشان دهد و می‌تواند برای شناسایی شما یا دستگاه شما استفاده شود. این مسئله به ویژه در صورت ویرایش در مناطقی که ویکی‌های ما به عنوان مسئله‌برانگیز تلقی می‌شوند، اهمیت دارد. انتشار آدرس آی‌پی شما ممکن است به دیگران اجازه دهد تا شما را پیدا کنند.
با تغییراتی که در قوانین و استانداردهای حریم خصوصی اتفاق افتاده‌است (مانند قوانین موجود در محدوده حمایت از داده‌های عمومی و گفتگو جهانی در مورد حریم خصوصی که آغاز شده‌است)، تیم حقوقی بنیاد ویکی‌مدیا تصمیم گرفته‌است که با پنهان کردن آدرس‌های آی‌پی از عموم مردم، حریم خصوصی کاربران را حفاظت کند. با این حال، ما به کاربرانی که نیاز به دیدن آدرس‌ها دارند تا ویکی‌ها را حفاظت کنند، همچنان دسترسی خواهیم داد.
ما آگاهیم که این تغییر بر روی جریان کنونی فرایندهای مبارزه با سوءاستفاده در ویکی‌مدیا تأثیر خواهد گذاشت. ما متعهدیم به توسعه ابزارها یا حفظ دسترسی به ابزارهایی که پس از پنهان کردن آدرس‌های آی‌پی، می‌توانند به شناسایی و مسدود کردن خرابکاری‌ها، حساب‌های زاپاس، ویرایشگران با تعارض منافع و سایر افراد بد بازشناختی شده، کمک کنند.
بیانیهٔ بخش حقوقی بنیاد ویکی‌مدیا
مارس ۲۰۲۳
Hello! Please review the new Access to temporary account IP addresses page for details about how users can gain access to IP addresses. The section on using IP addresses will be updated with details about how and where to access the IP addresses, as well as what is logged when IP addresses are accessed. Please also review a new related page with frequently asked questions. You will notice that both pages use the term "temporary user accounts," which comes from the MVP—more information about the MVP will be shared directly on this page soon. If you have questions or concerns, please reach out on the talk page.
به‌روزرسانی‌ها
April 2023: The Plan for IP Masking
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.
What will temporary usernames look like?
We don't know yet.
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:
- Caret (
^) –User:^12345 - Hyphen (
-) –User:-12345 - Tilde (
~) –User:~12345 - Exclamation mark (
!) –User:!12345 - Question mark (
?)[1] –User:?12345 - Year prefix –
User:2023-12345
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.)
How long do temporary usernames persist for?
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.
Tools available for patrolling
Like IP editors, temporary users can be checked and patrolled through Special:Block, Special:Checkuser and Special:Investigate.
Additionally, IP Info Feature can be used to access information about the underlying IP address for the given revision.
We are developing guidelines for Cloud tools and bots to access IPs for patrolling.
We will have an update for this soon.
What happens to existing IP addresses on our sites?
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.
Rollout plans
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.
داده‌های ویکی‌پدیای پرتغالی پیرامون غیرفعال کردن ویرایش آی‌پی‌ها
Portuguese Wikipedia’s metrics following restriction
All in all, the report presents the change in a positive light. We have not seen any significant disruption over the time period these metrics have been captured. In light of this, we are now encouraged to run an experiment on two more projects to see if we observe similar impact. All projects are unique in their own ways and what holds true for Portuguese Wikipedia might not hold true for another project. We want to run a limited-time experiment on two projects where registration will be required in order to edit. We estimate that it will take approximately 8 months for us to collect enough data to see significant changes. After that time period, we will return to not requiring registration to edit while we analyse the data. Once the data is published, the community will be able to decide for themselves whether or not they want to continue to disallow unregistered editing on the project.
We are calling this the Login Required Experiment. You will find more detail as well as a timeline on that page. Please use that page and its talk page to discuss this further.
Portuguese Wikipedia IP editing restriction
ویکی‌پدیای پرتغالی یک سال پیش ویرایش آی‌پی‌ها در پروژه را ممنوع کرد. در چند ماه گذشته، تیم ما در حال جمع‌آوری داده‌ها دربارهٔ عواقب این حرکت برای سلامت عمومی پروژه بوده‌است. ما همچنین با چندین عضو از پروژه دربارهٔ تجربهٔ آن‌ها گفتگو کرده‌ایم. ما در حال کار بر روی قدم‌های پایانی برای گردآوری همهٔ داده‌هایی هستیم که تصویری دقیق از وضعیت پروژه را ارائه می‌دهند. امیدواریم که اخبار جدیدی پیرامون این موضوع را در آینده منتشر کنیم.
ابزارها
Tool development
ما در گذشته پیرامون ایده‌هایی برای این ابزارها گفتگو کرده‌ایم که شرحی مختصر از آن‌ها را در پایین ذکر می‌کنم. دقت کنید که با توجه به این که تیم ما در حال کار بر روی تغییر اساسی SecurePoll جهت برآورده‌کردن نیازهای انتخابات پیش‌روی هیئت مدیرهٔ بنیاد بوده‌است، روند پیشرفت این ابزارها در چند ماه گذشته کند بوده‌است.
ویژگی اطلاعات آی‌پی
.png)
ما در حال ساخت ابزاری هستیم که اطلاعات مهم دربارهٔ یک نشانی آی‌پی که معمولاً در زمان تحقیقات مورد استفاده قرار می‌گیرند را نمایش خواهد داد. معمولاً گشت‌زنان، مدیران و بازرسان کاربر برای دریافت این اطلاعات بر وبگاه‌های خارجی متکی هستند. ما امیدواریم که به‌واسطهٔ ادغام اطلاعات از عرضه‌کنندگان آی‌پی معتبر در وبگاه‌های خود، بتوانیم این فرآیند را به فرآیندی آسان‌تر تبدیل کنیم. ما اخیراً پیش‌نمونه‌ای ساخته‌ایم و دوره‌ای از آزمون‌ها توسط کاربران را به‌منظور تأیید رویکرد خود به اجرا درآورده‌ایم. در این میان دریافته‌ایم که بخش عمده‌ای از ویرایشگران در گروه مصاحبه‌شوندگان این ابزار را مفید دانسته و اشاره کرده‌اند که مایل هستند در آینده از آن استفاده کنند. یک بروزرسانی در صفحهٔ پروژه موجود است که مایلم توجه شما را به آن جلب کنم. سؤالات کلیدی که ما می‌خواهیم بازخورد شما دربارهٔ آن‌ها را در صفحهٔ بحث پروژه بدانیم به شرح زیر است:
- در زمان تحقیق دربارهٔ یک نشانی آی‌پی، در جستجوd کدام انواع از اطلاعات هستید؟ در زمان جستجو برای این اطلاعات، احتمال دارد به کدام صفحه رجوع کنید؟
- کدام دسته از اطلاعات دربارهٔ آی‌پی‌ها را مفید می‌دانید؟
- فکر می‌کنید کدام انواع از اطلاعات آی‌پی‌ها اگر منتشر شوند، ویرایشگران ناشناس ما را تحت خطر قرار می‌دهند؟
ویژگی تطابق ویرایشگران
در گفتگوهای اولیه، به این پروژه با نام «ویرایشگران نزدیک» و «شناسایی زاپاس» نیز اشاره شده‌است. ما سعی داریم نامی مناسب برای این ویژگی بیابیم که حتی برای افرادی که درکی از واژهٔ زاپاس ندارند نیز قابل درک باشد.
ما در مراحل اولیهٔ این پروژه هستیم. واحد پژوهش بنیاد ویکی‌مدیا پروژه‌ای دارد که می‌تواند در شناسایی شباهت رفتار ویرایشی بین دو ویرایشگر کمک‌کننده باشد. این به کشف ارتباط کاربران ثبت‌نام‌نکردهٔ مختلف، در زمانی که تحت نام‌های کاربری تولیدشده به‌صورت خودکار به ویرایش می‌پردازند، کمک می‌کند. وقتی سال پیش صحبت‌ها دربارهٔ این پروژه را آغاز کردیم، با حمایت‌های زیادی روبرو شدیم. علاوه بر این، چیزهای زیادی هم دربارهٔ ریسک‌های توسعهٔ چنین ویژگی‌ای شنیدیم.
ما در حال برنامه‌ریزی برای ساخت یک پیش‌نمونه در آیندهٔ نزدیک، و به اشتراک گذاشتن آن با اجتماع هستیم. یک صفحهٔ پروژه برای این پروژه موجود است. امیدواریم که به‌زودی بتوانیم یک بروزرسانی برای آن منتشر کنیم. از دیدگاه‌های شما دربارهٔ این پروژه در صفحهٔ بحث پروژه بسیار استقبال می‌کنیم.
Like mentioned previously, our foremost goal is to provide better anti-vandalism tools for our communities which will provide a better moderation experience for our vandal fighters while also working towards making the IP address string less valuable for them. Another important reason to do this is that IP addresses are hard to understand and are really very useful only to tech-savvy users. This creates a barrier for new users without any technical background to enter into functionary roles as there is a higher learning curve for them to work with IP addresses. We hope to get to a place where we can have moderation tools that anyone can use without much prior knowledge.
The first thing we decided to focus on was to make the CheckUser tool more flexible, powerful and easy to use. It is an important tool that services the need to detect and block bad actors (especially long-term abusers) on a lot of our projects. The CheckUser tool was not very well maintained for many years and as a result it appeared quite dated and lacked necessary features.
We also anticipated an uptick in the number of users who opt-in to the role of becoming a CheckUser on our projects once IP Masking goes into effect. This reinforced the need for a better, easier CheckUser experience for our users. With that in mind, the Anti-Harassment Tools team spent the past year working on improving the CheckUser tool – making it much more efficient and user-friendly. This work has also taken into account a lot of outstanding feature requests by the community. We have continually consulted with CheckUsers and stewards over the course of this project and have tried our best to deliver on their expectations. The new feature is set to go live on all projects in October 2020.
The next feature that we are working on is IP info. We decided on this project after a round of consultation on six wikis which helped us narrow down the use cases for IP addresses on our projects. It became apparent early on that there are some critical pieces of information that IP addresses provide which need to be made available for patrollers to be able to do their roles effectively. The goal for IP Info, thus, is to quickly and easily surface significant information about an IP address. IP addresses provide important information such as location, organization, possibility of being a Tor/VPN node, rDNS, listed range, to mention a few examples. By being able to show this, quickly and easily without the need for external tools everyone can’t use, we hope to be able to make it easier for patrollers to do their job. The information provided is high-level enough that we can show it without endangering the anonymous user. At the same time, it is enough information for patrollers to be able to make quality judgements about an IP address.
After IP Info we will be focusing on a finding similar editors feature. We’ll be using a machine learning model, built in collaboration with CheckUsers and trained on historical CheckUser data to compare user behavior and flag when two or more users appear to be behaving very similarly. The model will take into account which pages users are active on, their writing styles, editing times etc. to make predictions about how similar two users are. We are doing our due diligence in making sure the model is as accurate as possible.
Once it’s ready, there is a lot of scope for what such a model can do. As a first step we will be launching it to help CheckUsers detect socks easily without having to perform a lot of manual labor. In the future, we can think about how we can expose this tool to more people and apply it to detect malicious sockpuppeting rings and disinformation campaigns.
You can read more and leave comments on our project page for tools.
Research
IP addresses are valuable as a semi-reliable partial identifier, which is not easily manipulated by their associated user. Depending on provider and device configuration, IP address information is not always accurate or precise, and deep technical knowledge and fluency is needed to make best use of IP address information, though administrators are not currently required to demonstrate such fluency to have access. This technical information is used to support additional information (referred to as “behavioural knowledge”) where possible, and the information taken from IP addresses significantly impact the course of administrative action taken.
On the social side, the issue of whether to allow unregistered users to edit has been a subject of extensive debate. So far, it has erred on the side of allowing unregistered users to edit. The debate is generally framed around a desire to halt vandalism, versus preserving the ability for pseudo-anonymous editing and lowering the barrier to edit. There is a perception of bias against unregistered users because of their association with vandalism, which also appears as algorithmic bias in tools such as ORES. Additionally, there are major communications issues when trying to talk to unregistered users, largely due to lack of notifications, and because there is no guarantee that the same person will be reading the messages sent to that IP talk page.
In terms of the potential impact of IP masking, it will significantly impact administrator workflows and may increase the burden on CheckUsers in the short term. If or when IP addresses are masked, we should expect our administrators' ability to manage vandalism to be greatly hindered. This can be mitigated by providing tools with equivalent or greater functionality, but we should expect a transitional period marked by reduced administrator efficacy. In order to provide proper tool support for our administrators’ work, we must be careful to preserve or provide alternatives to the following functions currently fulfilled by IP information:
- Block efficacy and collateral estimation
- Some way of surfacing similarities or patterns among unregistered users, such as geographic similarity, certain institutions (e.g. if edits are coming from a high school or university)
- The ability to target specific groups of unregistered users, such as vandals jumping IPs within a specific range
- Location or institution-specific actions (not necessarily blocks); for example, the ability to determine if edits are made from an open proxy, or public location like a school or public library.
Depending on how we handle temporary accounts or identifiers for unregistered users, we may be able to improve communication to unregistered users. Underlying discussions and concerns around unregistered editing, anonymous vandalism, and bias against unregistered users are unlikely to significantly change if we mask IPs, provided we maintain the ability to edit projects while logged out.
We interviewed CheckUsers on multiple projects throughout our process for designing the new Special:Investigate tool. Based on interviews and walkthroughs of real-life cases, we broke down the general CheckUser workflow into five sections:
- Triaging: assessing cases for feasibility and complexity.
- Profiling: creating a pattern of behaviour which will identify the user behind multiple accounts.
- Checking: examining IPs and useragents using the CheckUser tool.
- Judgement: matching this technical information against the behavioural information established in the Profiling step, in order to make a final decision about what kind of administrative action to take.
- Closing: reporting the outcome of the investigation on public and private platforms where necessary, and appropriately archiving information for future use.
We also worked with staff from Trust and Safety to get a sense for how the CheckUser tool factors into Wikimedia Foundation investigations and cases that are escalated to T&S.
The most common and obvious pain points all revolved around the CheckUser tool's unintuitive information presentation, and the need to open up every single link in a new tab. This caused massive confusion as tab proliferation quickly got out of hand. To make matters worse, the information that CheckUser surfaces is highly technical and not easy to understand at first glance, making the tabs difficult to track. All of our interviewees said that they resorted to separate software or physical pen and paper in order to keep track of information.
We also ran some basic analyses of English Wikipedia's Sockpuppet Investigations page to get some baseline metrics on how many cases they process, how many are rejected, and how many sockpuppets a given report contains.
Previous research on patrolling on our projects has generally focused on the workload or workflow of patrollers. Most recently, the Patrolling on Wikipedia study focuses on the workflows of patrollers and identifying potential threats to current anti-vandal practices. Older studies, such as the New Page Patrol survey and the Patroller work load study, focused on English Wikipedia. They also look solely at the workload of patrollers, and more specifically on how bot patrolling tools have affected patroller workloads.
Our study tried to recruit from five target wikis, which were
- Japanese Wikipedia
- Dutch Wikipedia
- German Wikipedia
- Chinese Wikipedia
- English Wikiquote
They were selected for known attitudes towards IP edits, percentage of monthly edits made by IPs, and any other unique or unusual circumstances faced by IP editors (namely, use of the Pending Changes feature and widespread use of proxies). Participants were recruited via open calls on Village Pumps or the local equivalent. Where possible, we also posted on Wiki Embassy pages. Unfortunately, while we had interpretation support for the interviews themselves, we did not extend translation support to the messages, which may have accounted for low response rates. All interviews were conducted via Zoom, with a note-taker in attendance.
Supporting the findings from previous studies, we did not find a systematic or unified use of IP information. Additionally, this information was only sought out after a certain threshold of suspicion. Most further investigation of suspicious user activity begins with publicly available on-wiki information, such as checking previous local edits, Global Contributions, or looking for previous bans.
Precision and accuracy were less important qualities for IP information: upon seeing that one chosen IP information site returned three different results for the geographical location of the same IP address, one of our interviewees mentioned that precision in location was not as important as consistency. That is to say, so long as an IP address was consistently exposed as being from one country, it mattered less if it was correct or precise. This fits with our understanding of how IP address information is used: as a semi-unique piece of information associated with a single device or person, that is relatively hard to spoof for the average person. The accuracy or precision of the information attached to the user is less important than the fact that it is attached and difficult to change.
Our findings highlight a few key design aspects for the IP info tool:
- Provide at-a-glance conclusions over raw data
- Cover key aspects of IP information:
- Geolocation (to a city or district level where possible)
- Registered organization
- Connection type (high-traffic, such as data center or mobile network versus low-traffic, such as residential broadband)
- Proxy status as binary yes or no
As an ethical point, it will be important to be able to explain how any conclusions are reached, and the inaccuracy or imprecisions inherent in pulling IP information. While this was not a major concern for the patrollers we talked to, if we are to create a tool that will be used to provide justifications for administrative action, we should be careful to make it clear what the limitations of our tools are.
––
Best regards,
Anti-Harassment Tools Team
Please use the talk page for discussions on the matter. For any issues concerning this release, please don't hesitate to contact Niharika Kohli, Product Manager – niharika
wikimedia.org or leave a message on the talk page.
For more information or documentation on IP editing, masking and an overview of what has been done so far including community discussions, please see the links below.
About IP Editing · About IP Addresses · IP Editing Restriction Study · Impact report for Login Required Experiment on Portuguese Wikipedia · Research:Value of IP Editing