הגברת הפרטיות ומניעת שימוש לרעה בכתובות IP

This page is a translated version of the page IP Editing: Privacy Enhancement and Abuse Mitigation and the translation is 25% complete.
Outdated translations are marked like this.


IP masking hides the IP addresses of unregistered editors on Wikimedia projects, fully or partially, from everyone except those who need access to fight spam, vandalism, harassment and disinformation.

Currently, anyone can edit Wikimedia wikis without a Wikimedia account or without logging in. MediaWiki, the software behind Wikimedia projects, will record and publish your IP address in its public log. Anyone seeking your IP address will find it.

Wikimedia projects have a good reason for storing and publishing IP addresses: they play a critical role in keeping vandalism and harassment off our wikis.

However, your IP address can tell where you are editing from and can be used to identify you or your device. This is of particular concern if you are editing from a territory where our wikis are deemed controversial. Publishing your IP address may allow others to locate you.

With changes to privacy laws and standards (e.g., the General Data Protection Regulation and the global conversation about privacy that it started), the Wikimedia Foundation Legal team has decided to protect user privacy by hiding IPs from the general public. However, we will continue to give access to users who need to see the addresses to protect the wikis.

We're aware that this change will impact current anti-abuse workflows. We are committed to developing tools or maintaining access to tools that can identify and block vandals, sock puppets, editors with conflicts of interest and other bad actors after IPs are masked.

עדכונים

Implementation Strategy and next steps (25 February 2022)

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

9 December 2021 Update
We discussed the two different approaches for IP masking that we are considering. As a follow-up to that, we have come up with a few different workflows and how they will change with the two different implementations.

Note that in both alternatives admins, stewards, checkusers and users with the IPViewer role will be able to unmask IPs on pages like Recent changes and History for anti-vandalism purposes.

Editing experience for unregistered editors

Current behavior: At present, unregistered editors can edit without being logged in (on most wikis). Before making the edit, they see a banner that tells them that their IP address will be publicly recorded and published in perpetuity.

IP-based identity: Unregistered editors will be able to edit as currently. Before making the edit, they will see a message which tells them that their edits will be attributed to an encrypted version of their IP address. The IP address itself will be visible to administrators and patrollers. It will be retained for a limited period of time.

Session-based identity: This is similar to above with the exception that editors will be told that their edits will be attributed to an auto-generated username.

Communicating about unregistered editors

Current behavior: Unregistered editors are referred to by their IP addresses or if they are a known long-term abuser, they are often given a name based on their behavior.

IP-based identity: Patrollers and admins will not be able to refer to IP addresses publicly but will be able to refer to their encrypted IP address or the long-term abuser name. They can share the IP with others who have access to it.

Session-based identity: Patrollers and admins will not be able to refer to IP addresses publicly but will be able to refer to their auto-generated usernames. They can share the IP with others who have access to it. This can help identify a specific actor, but it can also be confusing if there are multiple IPs behind the username, similar to how many persons can be behind an IP today. To ease this concern, we are building a tool that will be able to surface information about all the different IP addresses an editor is active from.

Talk page experience for unregistered editors

Current behavior: An unregistered editor can receive messages on the talk page for their IP. Once the editor’s IP address changes, they receive messages on the new IP address talk page. This splinters conversations and makes it difficult to keep in contact with a certain unregistered editor.

IP-based identity: In this implementation, the behavior remains the same as current. Unregistered editors will receive messages on their encrypted IP talk pages and once their IP changes, their associated talk page changes as well.

Session-based identity: In this implementation, unregistered editors receive messages on a talk page that is associated with a cookie on their browser. Even if their IP changes, that still allows them to receive messages on their talk page. If their browser cookie is cleared, they no longer retain their session identity and will receive a new cookie and a new talk page associated with that. Since IPs change more frequently than cookies, it is likely that many users will end up with a semi-permanent talk page unless they specifically try not to. Another advantage to note is that talk page messages will no longer end up with the wrong recipient in any scenario.

 
Talk page notification

Blocking unregistered editors

Current behavior: An admin can block an IP address or an IP range directly. Additionally, they can turn it into an autoblock which can retain a cookie on the end user’s browser which prevents them from editing even if they change IP addresses. This functionality was introduced a few years ago.

IP-based identity: The behavior remains the same as current. IPs are masked by default, but admins and patrollers with the right privileges can access them.

Session-based identity: This implementation allows us to retain the current behavior of blocking by IP addresses. It also allows us to perform only cookie-based blocks as well. This can be helpful in scenarios where people share devices (like a library or cybercafé) and blocking the IP address or IP address range can cause unnecessary collateral. I want to point out that this will not work in cases where vandals are experienced editors and can evade cookie blocks.

== גישות יישומיות להסוואת כתובות IP (שאלות ותשובות) ==

October 2021 Update
השאלות והתשובות שמוצגות פה עונות על השאלות שצפינו שיהיו לחברי הקהילה לגבי הגישות השונות שאנחנו יכולים ליישם בנוגע להסוואת כתובות IP ולגבי איך כל אחת מהן תשפיע על הקהילה.

ש: בעקבות יישום ההסוואה של כתובות IP, למי תהיה גישה לתצוגה של כתובות אלה?

ת: בודקים, דיילים ומפעילים יוכלו לראות כתובות IP מלאות על ידי בחירה באפשרות זו והסכמה לא לשתף את המידע עם אחרים שלהם אין גישה למידע זה.

לעורכים שמשתתפים בפעילות נגד השחתות, כפי שיקבע על ידי הקהילה, תהיה אפשרות לראות כתובות IP כדי להמשיך בעבודתם. הרשאות משתמש אלה יטופלו על ידי הקהילה, כפי שמטופלות הרשאות אחרות, ותהיה דרישה למינימום של עריכות ומספר ימים מינימלי כעורכים.

כל המתשתמשים עם חשבון משתמש שפעיל יותר מזמן מסוים ועם מעל מספר מסוים של עריכות (יוחלט בהמשך) יהיו יכולים לגשת לכתובות IP מוסוות חלקית ללא הרשאה מיוחדת. המשמעות היא שכתובות IP יופיעו כשה"זנבות" שלהן - החלק האחרון בכתובת - מוחבאים. גישה כזו תהיה זמינה על ידי בחירה באפשרות מתאימה והסכמה לא לחלוק את המידע עם אחרים שאין להם גישה למידע הזה.

לכל המשתמשים האחרים לא תהיה גישה לכתובות IP של משתמשים לא רשומים.

ש: מהן האפשרויות הטכניות השונות ליישום?

ת: בשבועות האחרונים ניהלנו מספר דיונים על האפשרויות הטכניות להשגת היעד של הסוואת כתובות IP תוך מזעור ההשפעה על העורכים והקוראים. אספנו משובים מצוותים שונים והתוודענו לנקודות מבט שונות בנושא. למטה תוכלו לקרוא על שתי הדרכים המרכזיות שעלו בדיונים.

  • זהות מבוססת-IP: אם נבחר בגישה זו, הכל ישאר אותו הדבר, אבל תצוגת כתובות ה-IP המלאה תוחלף בתצוגה של גרסה מקוצצת של הכתובות. אפשרות זו שומרת על תהליך העבודה הקיים, אבל היא לא מציעה אפשרויות מועילות חדשות.
  • זהות מבוססת-סשן (session): אם נבחר בגישה זו, תיווצר זהות למשתמשים לא רשומים המבוססת על קוקית בדפדפן האינטרנט, שמאפשרת לזהות את המשתמש. הקוקית תישמר גם כשכתובת ה-IP מתחלפת, כך שהזהות של המשתמש תישמר.

ש: איך עובדת זהות מבוססת-IP?

ת: כרגע, משתמשים לא רשומים מזוהים באמצעות כתובות ה-IP שלהם. דרך פעולה זו עבדה היטב במיזמים שלנו במשך שנים רבות. משתמשים בעלי ידע לגבי כתובות IP מבינים שכתובת IP יחידה יכולה להיות בשימוש על ידי מספר משתמשים, כתלות במידת הדינמיות של הכתובת. טענה זו נכונה לכתובות IP מסוג IPv6 יותר מאשר כתובות מסוג IPv4.

משתמש לא רשום יכול גם לשנות את כתובת ה-IP שלו אם הוא בתנועה או עורך ממיקום שונה.

אם נבחר בגישה של זהות מבוססת-IP לצורך הסוואת כתובות ה-IP, אנחנו נשמור על רוב הפונקציונליות שקיימת כיום. אנחנו פשוט נשתמש במזהה מוצפן לצורך ההסוואה של הכתובת. האפשרות הזו שומרת על הייחודיות של כתובות IP, תוך שמירה על הפרטיות של המשתמש. למשל, משתמש לא רשום כמו "משתמש:192.168.1.2" עשוי להופיע כ"משתמש:ca1f46". יתרונות של גישה זו: שומרת על מהלך העבודה הקיים תוך מזעור ההפרעות.

חסרונות של גישה זו: לא מציע יתרונות כלשהם בעולם שעובר במהירות לכתובות IP דינמיות יותר ושימושיות פחות.

ש: איך עובדת זהות מבוססת-סשן?

ת: אפשרות זו יוצרת זהות למשתמשים לא רשומים על בסיס קוקית (cookie) שמושתלת בדפדפן שלהם. על פי גישה זו, נוצר באופן אוטומטי שם משתמש, והעריכות והפעולות של המשתמש מיוחסות לשם משתמש זה. לדוגמה, ייתכן שמשתמש:192.168.1.2 יקבל את שם המשתמש "משתמש:Anon3406".

אם נבחר בגישה זו, הסשן של המשתמש יימשך כל עוד העוגייה קיימת בדפדפן שלו, אפילו אם הוא שינה את כתובת ה-IP שלו.

יתרונות של גישה זו:

  • קושרת את זהות-המשתמש לדפדפן במחשב, ומציע דרך יציבה יותר לתקשורת עם המשתמש.
  • זהות המשמש לא משתנה כשכתובת ה-IP משתנה.
  • הגישה הזו מאפשרת למשתמשים לא רשומים גישה להעדפות מסוימות שזמינות כעת רק למשתמשים רשומים.
  • הגישה הזו יכולה לאפשר למשתמשים לא רשומים להירשם מבלי לאבד את היסטוריית העריכה שלהם.

חסרונות של גישה זו:

  • שינוי משמעותי במודל הנוכחי של מה מייצג משתמש לא רשום.
  • הזהות של המשתמש שאינו רשום היא קבועה רק כל עוד נשמרת הקוקית בדפדפן.
  • משחיתים במצב גלישה בפרטיות או כאלה שמוחקים את הקוקיות יקבלו זהות חדשה מבלי לשנות את כתובת ה-IP שלהם.
  • גישה זו עשויה להצריך חשיבה מחדש על חלק מתהליכי העבודה והכלים הקיימים.

ש: האם לקרן יש העדפה לגבי אחת מהגישות?

ת: ההעדפה שלנו היא לזהות מבוססת-סשן, משום שגישה זו מציעה הזדמנויות חדשות רבות לעתיד. היא תאפשר טיפול בבעיות תקשורת שקיימות כבר עשרים שנה. משתמשים יוכלו אמנם למחוק את הקוקיות כדי לקבל זהות חדשה, אבל כתובות ה-IP עדיין יהיו גלויות למנטרים פעילים עם ההרשאה המתאימה. כמובן שאנחנו מכירים בזה שקל יותר למחוק קוקית מאשר לשנות כתובת IP ובהשפעות שתהיה לעובדה זו.

=== הצעה לשיתוף כתובות IP עם אלה שצריכים גישה ===

10 June 2021 Update

שלום לכולם. עברו מספר חודשים מאז העדכון האחרון שלנו על פרויקט זה. בזמן שחלף דיברנו עם הרבה אנשים בקהילת העורכים ובתוך הקרן. שקלנו ברצינות רבה את כל הדאגות שעלו בדיונים עם חברי קהילה מנוסים, לגבי ההשפעה שתהיה לשינויים על המאמצים למנוע השחתות במיזמים השונים. שמענו גם ממספר ניכר של אנשים שתומכים בהצעה הזו כצעד לשיפור הפרטיות של משתמשים לא רשומים והפחתה של איומים משפטיים שחשיפת כתובות IP מציבה בפני המיזמים שלנו.

כשדיברנו בעבר על הפרויקט הזה, לא היה לנו ברור לאן הוא מועד. הכוונה שלנו הייתה להבין איך כתובות IP מועילות לקהילות שלנו. מאז, קיבלנו הרבה פידבק ממספר דיונים בשפות שונות ובקהילות שונות. אנחנו מוקירים תודה לכל חברי הקהילה שלקחו את הזמן ללמד אותנו על האופן בו מבוקרת הפעילות באתרי הויקי שלהם או בסביבת הבין-ויקי הספציפית שלהם.

יש לנו עכשיו הצעה קונקרטית יותר לפרויקט זה, ואנחנו מקווים שהיא תאפשר לרוב הפעילות נגד משחיתים לעבוד ללא הפרעה, תוך הגבלת הגישה של אלו שלא צריכים לראות כתובות IP לכתובות אלה. אני רוצה להדגיש את המילה "הצעה", כי בשום צורה לא מדובר בהכרעה סופית לגבי מה שיקרה בעתיד. כוונתנו היא לקבל פידבק על הרעיון - מה אתם חושבים שיעבוד? מה לא יעבוד? איזה רעיונות יש לכם לשיפור?


פיתחנו את הרעיונות האלה במהלך מספר דיונים עם חברי קהילה מנוסים, ושיפרנו אותם בשיתוף פעולה עם מחלקת המשפט שלנו. הנה קווי המתאר של ההצעה:

  • לבודקים, דיילים, ומפעילים צריכה להיות גישה מלאה לכתובות IP. הם יקבלו גישה זו אם הם יבחרו באפשרות הזו ויסכימו לא לשתף את המידע עם אחרים שאינם בעלי גישה.
  • למנטרים שמשתתפים במאמצים נגד השחתות, כפי שיקבע על ידי הקהילה, ניתן לתת גישה לכתובות IP לצורך המשך עבודתם. ניתן לטפל בכך בדומה לאופן שבו מטפלים בהרשאות מפעיל במיזמים שלנו. אישור הקהילה הוא חשוב על מנת שרק עורכים שבאמת צריכים גישה יקבלו אותה. העורכים יצטרכו להיות עם ותק של שנה לפחות ועם לפחות 500 עריכות בהיסטוריה של החשבון שלהם.
  • לכל העורכים עם חשבון משתמש שנפתח לפני שנה לפחות ועם לפחות 500 עריכות תהיה גישה לכתובות IP מוסוות חלקית, גם ללא הרשאה מיוחדת. המשמעות היא שכתובות IP יופיעו כשהזנבות שלהן - החלק האחרון בכתובת - אינם גלויים. גישה זו תהיה זמינה על ידי בחירה באפשרות זו והסכמה לא לחלוק את המידע עם עורכים שלהם אין גישה למידע זה.
  • לכל המשמשים האחרים לא תהיה גישה לכתובות IP של משתמשים לא רשומים.
  • 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 תתועד ביומן, כך שניתן יהיה לבצע בדיקה במידת הצורך. רעיון זה דומה לאופן שבו אנחנו מתעדים גישה של בוקים למידע פרטי. באופן זה, אנחנו מקווים לאזן את הדרישה לפרטיות עם הצורך של הקהילה לגשת למידע כדי להילחם בספאם, השחתות והטרדות. אנחנו רוצים לאפשר גישה למידע לאלה שצריכים אותו, אבל אנחנו צריכים ליצור תהליך מסודר, ואנחנו צריכים שגישה למידע תינתן רק למי שיבחר בהרשאה זו ויתן הכסמתו לתנאים הכרוכים בה (opt-in), כך שרק אלו שבאמת צריכים את המידע יהיו יכולים לראות אותו. בנוסף, אנחנו צריכים שהגישה למידע תתועד.

אנחנו רוצים לשמוע מה אתם חושבים על גישה מוצעת זו. אנא ספקו לנו פידבק בדף השיחה.

  • מה אתם חושבים שיעבוד?
  • מה אתם חושבים שלא יעבוד?
  • אלו רעיונות נוספים יכולים לשפר את ההצעה?

נתונים לגבי מניעת עריכה ממשתמשים לא רשומים בויקיפדיה הפורטוגזית

Portuguese Wikipedia’s metrics following restriction

30 August 2021 Update

שלום. זהו עדכון קצר לגבי המדדים שנאספו מוויקיפדיה הפורטוגזית מאז שהם החלו לדרוש הרשמה לשם עריכה. יש לנו דוח מקיף בעמוד זה. הדוח כולל מדדים שנאספו באמצעות נתונים, וכן סקר שנעשה בקרב משתמשים שתורמים לוויקיפדיה הפורטוגזית. באופן כללי, הדוח מציג את השינויים באור חיובי. לא ראינו בעיות משמעותיות במהלך הזמן שמדדים אלו נאספו. אנחנו מוצאים בכך עידוד לעריכת ניסויים בשני מיזמים נוספים, כדי לראות אם ההשפעה על מיזמים אלו זהה. כל מיזם של ויקימדיה הוא מיוחד בדרכו ומה שנכון לגבי ויקיפדיה הפורטוגזית עשוי לא להיות נכון למיזמים אחרים. אנחנו רוצים לערוך ניסוי לזמן מוגבל על שני מיזמים שבהם תידרש הרשמה לצורך עריכה. אנחנו מעריכים שיקח בערך 8 חודשים לאסוף לאסוף מספיק נתונים ולראות שינויים משמעותיים. אחרי תקופה זו, נפסיק לדרוש הרשמה לצורך עריכה, בזמן שאנחנו מנתחים את הנתונים. ברגע שהנתונים יפורסמו, חברי הקהילות יהיו יכולים להחליט בעצמם אם הם רוצים להמשיך לא לאפשר למשתמשים שאינם רשומים לערוך או לא.

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.

אנחנו קוראים לזה ניסוי חובת הרשמה. אתם יכולים למצוא פרטים נוספים וכן לוח זמנים בדף של הניסוי. אנא השתמשו בדף זה ובדף השיחה שלו כדי להמשיך את הדיון.

Portuguese Wikipedia IP editing restriction

Update
בשנה שעברה, ויקיפדיה הפורטוגזית מנעה עריכות של משתמשים לא רשומים. בחודשים האחרונים, הצוות שלנו אסף נתונים על התוצאות של הצעד הזה בהתייחס לבריאות הכללית של המיזם. כמו כן, שוחחנו עם מספר חברי קהילה לגבי הניסיון שלהם עם המצב החדש. אנחנו עובדים על הדברים האחרונים שדרושים כדי להציג את כל הנתונים שמאפשרים הצגה של תמונת מצב מדויקת של הפרויקט. אנחנו מקווים שיהיה עדכון לגבי זה ולגבי נושאים אחרים בעתיד הקרוב.

כלים

Tool development

Update 02
כפי שאתם אולי יודעים, אנחנו עובדים על פיתוח מספר כלים חדשים. חלק מכלים אלו נועדו לרכך את ההשפעה של הסוואת כתובות IP, אבל חלקם מיועדים פשוט לשפר פעולות נגד משחיתים. אין זה סוד שמצב כלי הבקרה במיזמים שלנו אינו מספק. יש הרבה מקום לשיפור. אנחנו רוצים לבנות כלים שעוזרים לאלו שנלחמים בהשחתות לעבוד בצורה יותר אפקטיבית. אנחנו רוצים גם להפחית את מחזומי הכניסה לתפקידים אלו, עבור תורמים שאינם בעלי ידע טכני.

דיברנו על כלים אלו בעבר, ואני אספק למטה עדכון קצר לגביהם. שימו לב שההתקדמות בפיתוח כלים אלו הייתה איטית בחודשים האחרונים, כי הצוותים שלנו היו עסוקים בשדרוג של SecurePoll כדי להתאים אותו לצרכים של הבחירות למועצת הקרן.

כלי למידע על IP

 
Mockup for IP Info

אנחנו בונים כלי שיאפשר הצגה של מידע חשוב על כתובת ה-IP, שבמקרים רבים יש בו צורך במהלך חקירה. בדרך כלל, מפעילים, מנטרים ובודקים מסתמכים על אתרים חיצוניים כדי לספק את המידע הזה. אנחנו מקווים להקל על עבודתם על ידי אינטגרציה של מידע מספקי IP אמינים בתוך האתרים שלנו. לאחרונה בנינו אב טיפוס וערכנו סבב של בדיקות על ידי משתמשים כדי לתקף את גישתנו. רוב העורכים שרואיינו חשבו שהכלי סייע להם וציינו שהם יהיו מעוניינים להשתמש בו בעתיד. אנחנו רוצים להסב את תשומת לבכם לעדכון בדף הפרויקט. שאלות מפתח שלגביהן אנחנו רוצים את הפידבק שלכם בדף השיחה:

  • כשאתם חוקרים IP איזה סוג של מידע אתם מחפשים? באיזה דף אתם בדרך כלל משתמשים כשאתם מחפשים את המידע הזה?
  • אלו סוגים של מידע על IP הוא הכי שימושי עבורכם?
  • אלו סוגים של מידע על IP עשוי להעמיד את העורכים האנונימים בסכנה כאשר משתפים אותו?

כלי להתאמת עורכים

כלי זה כונה בשיחות קודמות גם "עורכים קרובים" ו"איתור בובות קש". אנחנו מנסים למצוא שם מתאים שיהיה מובן גם לאנשים שלא מבינים את הביטויים "בובת קש" או "בובת גרב".

אנחנו נמצאים בשלב מוקדם של המיזם הזה. לקרן ויקימדיה יש מיזם שיכול לעזור בזיהוי שני עורכים בעלי התנהגות דומה. מיזם זה יכול לעזור בקישור בין שני משתמשים לא רשומים, כאשר הם עורכים תחת שני שמות משתמש שנוצרים באופן אוטומטי. המיזם קיבל הרבה תמיכה כשהתחלנו לדבר עליו לפני שנים. שמענו גם על הסיכונים שכרוכים בפיתוח כלי כזה. אנחנו מתכננים לבנות אב טיפוס בזמן הקרוב ולשתף אותו עם הקהילה. יש למיזם הזה דף שלא זוכה לתשומת לב מספקת. אנחנו מקווים שהוא יעודכן בקרוב. נשמח לשמוע את המחשבות שלכם לגבי המיזם הזה בדף השיחה של המיזם.

Update 01
כאמור, המטרה המרכזית שלנו היא לספק כלים טובים יותר לטיפול בהשחתות עבור הקהילות שלנו, שיסייעו ללוחמים בשחיתות ובאותו הזמן יפחיתו את הצורך בגישה לכתובות IP. סיבה חשובה נוספת לעשות את זה היא שכתובות IP הן קשות להבנה ובאופן מעשי הן שימושיות במיוחד רק למשתמשים עם יכולות טכניות טובות. מצב זה יוצר מחסום למשתמשים חדשים ללא רקע טכני, שרוצים לקבל תפקידים מערכתיים, וזאת משום שיש להם עקומת למידה תלולה יותר בהבנת העבודה עם כתובות IP. אנחנו מקווים להגיע למצב שיש לנו כלי בקרה שימושיים לכולם, בלי צורך בידע מוקדם.

הדבר הראשון שבו החלטנו להתמקד היה יצירה של כלי לבודקים שיהיה גמיש יותר, רב-עוצמה וקל לשימוש. זה כלי חשוב שעונה על הצורך לאתר ולחסום פעילות שאינה על פי הכללים (במיוחד, שימוש ארוך טווח לרעה) ברבים מהמיזמים שלנו. כתוצאה מתחזוקה לא מספקת במשך שנים רבות, כלי הבדיקה היה מיושן וחסרו בו מרכיבים חיוניים.

צפינו גם שעם המעבר להסוואה של כתובות IP, תהיה עלייה במספר המשתמשים שמבקשים להיכנס לתפקיד של בודקים במיזמים השונים. ציפייה זו חיזקה את הצורך בכלי טוב יותר, קל יותר לבודקים. בהתחשב בזה, הצוות שמפתח כלים למניעת הטרדות הקדיש את השנה האחרונה לשיפור כלי הבדיקה - להפוך אותו להרבה יותר ידידותי למשתמש ויעיל. העבודה הזו כללה תשומת לב לבקשות נוספות לכלי שהגיעו מהקהילה. אנחנו התייעצנו באופן רציף עם בודקים ודיילים במהלך הפרויקט הזה וניסינו ככל יכולתנו לענות על הציפיות שלהם. הכלי החדש אמור להיכנס לשימוש בכל המיזמים באוקטובר 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 masking impact report

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.

 
A Wikimedia Foundation-supported report on the impact that IP masking will have on our community.

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.

CheckUser workflow

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.

Patroller use of IP addresses

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.

Statements from the Wikimedia Foundation Legal department

Updates

יולי 2021

First of all, we’d like to thank everyone for participating in these discussions. We appreciate the attention to detail, the careful consideration, and the time that has gone into engaging in this conversation, raising questions and concerns, and suggesting ways that the introduction of masked IPs can be successful. Today, we’d like to explain in a bit more detail how this project came about and the risks that inspired this work, answer some of the questions that have been raised so far, and briefly talk about next steps.

Background

To explain how we arrived here, we’d like to briefly look backwards. Wikipedia and its sibling projects were built to last. Sharing the sum of all knowledge isn’t something that can be done in a year, or ten years, or any of our lifetimes. But while the mission of the communities and Foundation was created for the long term, the technical and governance structures that enable that mission were very much of the time they were designed. Many of these features have endured, and thrived, as the context in which they operate has changed. Over the last 20 years, a lot has evolved: the way societies use and relate to the internet, the regulations and policies that impact how online platforms run as well as the expectations that users have for how a website will handle their data.

In the past five years in particular, users and governments have become more and more concerned about online privacy and the collection, storage, handling, and sharing of personal data. In many ways, the projects were ahead of the rest of the internet: privacy and anonymity are key to users’ ability to share and consume free knowledge. The Foundation has long collected little information about users, not required an email address for registration, and recognized that IP addresses are personal data (see, for example, the 2014–2018 version of our Privacy policy). More recently, the conversation about privacy has begun to shift, inspiring new laws and best practices: the European Union’s General Data Protection Regulation, which went into effect in May 2018, has set the tone for a global dialogue about personal data and what rights individuals should have to understand and control its use. In the last few years, data protection laws around the world have been changing—look at the range of conversations, draft bills, and new laws in, for example, Brazil, India, Japan, or the United States.

Legal risks

The Foundation’s Privacy team is consistently monitoring this conversation, assessing our practices, and planning for the future. It is our job to look at the projects of today, and evaluate how we can help prepare them to operate within the legal and societal frameworks of tomorrow. A few years ago, as part of this work, we assessed that the current system of publishing IP addresses of non-logged-in contributors should change. We believe it creates risk to users whose information is published in this way. Many do not expect it—even with the notices explaining how attribution works on the projects, the Privacy team often hears from users who have made an edit and are surprised to see their IP address on the history page. Some of them are in locations where the projects are controversial, and they worry that the exposure of their IP address may allow their government to target them. The legal frameworks that we foresaw are in operation, and the publication of these IP addresses pose real risks to the projects and users today.

We’ve heard from several of you that you want to understand more deeply what the legal risks are that inspired this project, whether the Foundation is currently facing legal action, what consequences we think might result if we do not mask IP addresses, etc. (many of these questions have been collected in the expanded list at the end of this section). We’re sorry that we can’t provide more information, since we need to keep some details of the risks privileged. “Privileged” means that a lawyer must keep something confidential, because revealing it could cause harm to their client. That’s why privilege is rarely waived; it’s a formal concept in the legal systems of multiple countries, and it exists for very practical reasons—to protect the client. Here, waiving the privilege and revealing this information could harm the projects and the Foundation. Generally, the Legal Affairs team works to be as transparent as possible; however, an important part of our legal strategy is to approach each problem on a case by case basis. If we publicly discuss privileged information about what specific arguments might be made, or what risks we think are most likely to result in litigation, that could create a road map by which someone could seek to harm the projects and the communities.

That said, we have examined this risk from several angles, taking into account the legal and policy situation in various countries around the world, as well as concerns and oversight requests from users whose IP addresses have been published, and we concluded that IP addresses of non-logged-in users should no longer be publicly visible, largely because they can be associated with a single user or device, and therefore could be used to identify and locate non-logged-in users and link them with their on-wiki activity.

Despite these concerns, we also understood that IP addresses play a major part in the protection of the projects, allowing users to fight vandalism and abuse. We knew that this was a question we’d need to tackle holistically. That’s why a working group from different parts of the Wikimedia Foundation was assembled to examine this question and make a recommendation to senior leadership. When the decision was taken to proceed with IP masking, we all understood that we needed to do this with the communities—that only by taking your observations and ideas into account would we be able to successfully move through this transition.

I want to emphasize that even when IP addresses are masked and new tools are in place to support your anti-vandalism work, this project will not simply end. It’s going to be an iterative process—we will want feedback from you as to what works and what doesn’t, so that the new tools can be improved and adapted to fit your needs.

Questions

Over the past months, you’ve had questions, and often, we’ve been unable to provide the level of detail you’re hoping for in our answers, particularly around legal issues.

Q: What specific legal risks are you worried about?

A: We cannot provide details about the individual legal risks that we are evaluating. We realize it’s frustrating to ask why and simply get, “that’s privileged” as an answer. And we’re sorry that we cannot provide more specifics, but as explained above, we do need to keep the details of our risk assessment, and the potential legal issues we see on the horizon, confidential, because providing those details could help someone figure out how to harm the projects, communities, and Foundation.

There are settled answers to some questions.

Q: Is this project proceeding?

A: Yes, we are moving forward with finding and executing on the best way to hide IP addresses of non-logged-in contributors, while preserving the communities’ ability to protect the projects.

Q: Can this change be rolled out differently by location?

A: No. We strive to protect the privacy of all users to the same standard; this will change across the Wikimedia projects.

Q: If other information about non-logged-in contributors is revealed (such as location, or ISP), then it doesn’t matter if the IP address is also published, right?

A: That’s not quite the case. In the new system, the information we make available will be general information that is not linked to an individual person or device—for example, providing a city-level location, or noting that an edit was made by someone at a particular university. While this is still information about the user, it’s less specific and individual than an IP address. So even though we are making some information available in order to assist with abuse prevention, we are doing a better job of protecting the privacy of that specific contributor.

Q: If we tell someone their IP address will be published, isn’t that enough?

A: No. As mentioned above, many people have been confused to see their IP address published. Additionally, even when someone does see the notice, the Foundation has legal responsibilities to properly handle their personal data. We have concluded that we should not publish the IP addresses of non-logged-in contributors because it falls short of current privacy best practices, and because of the risks it creates, including risks to those users.

Q: How will masking impact CC-BY-SA attribution?

A: IP masking will not affect CC license attribution on Wikipedia. The 3.0 license for text on the Wikimedia projects already states that attribution should include “​​the name of the Original Author (or pseudonym, if applicable)” (see the license at section 4c) and use of an IP masking structure rather than an IP address functions equally well as a pseudonym. IP addresses already may vary or be assigned to different people over time, so using that as a proxy for un-registered editors is not different in quality from an IP masking structure and both satisfy the license pseudonym structure. In addition, our Terms of use section 7 specify that as part of contributing to Wikipedia, editors agree that links to articles (which include article history) are a sufficient method of attribution.

And sometimes, we don’t know the answer to a question yet, because we’d like to work with you to find the solution.

Q: What should the specific qualifications be for someone to apply for this new user right?

A: There will be an age limit; we have not made a definitive decision about the limit yet, but it’s likely they will need to be at least 16 years old. Additionally, they should be active, established community members in good standing. We’d like to work through what that means with you.

I see that the team preparing these changes is proposing to create a new userright for users to have access to the IP addresses behind a mask. Does Legal have an opinion on whether access to the full IP address associated with a particular username mask constitutes nonpublic personal information as defined by the Confidentiality agreement for nonpublic information, and will users seeking this new userright be required to sign the Access to nonpublic personal data policy or some version of it?
1 If yes, then will I as a checkuser be able to discuss relationships between registered accounts and their IP addresses with holders of this new userright, as I currently do with other signatories?
2 If no, then could someone try to explain why we are going to all this trouble for information that we don't consider nonpublic?
3 In either case, will a checkuser be permitted to disclose connections between registered accounts and unregistered username masks?

A: This is a great question. The answer is partially yes. First, yes, anyone who has access to the right will need to acknowledge in some way that they are accessing this information for the purposes of fighting vandalism and abuse on the projects. We are working on how this acknowledgement will be made; the process to gain access is likely to be something less complex than signing the access to non-public personal data agreement.

As to how this would impact CUs, right now, the access to non-public personal data policy allows users with access to non-public personal data to share that data with other users who are also able to view it. So a CU can share data with other CUs in order to carry out their work. Here, we are maintaining a distinction between logged-in and logged-out users, so a CU would not be able to share IP addresses of logged-in users with users who have this new right, because users with the new right would not have access to such information.

Presuming that the CU also opts in to see IP addresses of non-logged-in users, under the current scheme, that CU would be able to share IP address information demonstrating connections between logged-in users and non-logged-in users who had been masked with other CUs who had also opted in. They could also indicate to users with the new right that they detected connections between logged-in and non-logged-in users. However, the CU could not directly the share IP addresses of the logged-in users with non-CU users who only have the new right.

Please let us know if this sounds unworkable. As mentioned above, we are figuring out the details, and want to get your feedback to make sure it works.

Next steps

Over the next few months, we will be rolling out more detailed plans and prototypes for the tools we are building or planning to build. We’ll want to get your feedback on these new tools that will help protect the projects. We’ll continue to try to answer your questions when we can, and seek your thoughts when we should arrive at the answer together. With your feedback, we can create a plan that will allow us to better protect non-logged-in editors’ personal data, while not sacrificing the protection of Wikimedia users or sites. We appreciate your ideas, your questions, and your engagement with this project.

אוקטובר 2020

This statement from the Wikimedia Foundation Legal department was written on request for the talk page and comes from that context. For visibility, we wanted you to be able to read it here too.

Hello All. This is a note from the Legal Affairs team. First, we’d like to thank everyone for their thoughtful comments. Please understand that sometimes, as lawyers, we can’t publicly share all of the details of our thinking; but we read your comments and perspectives, and they’re very helpful for us in advising the Foundation.

On some occasions, we need to keep specifics of our work or our advice to the organization confidential, due to the rules of legal ethics and legal privilege that control how lawyers must handle information about the work they do. We realize that our inability to spell out precisely what we’re thinking and why we might or might not do something can be frustrating in some instances, including this one. Although we can’t always disclose the details, we can confirm that our overall goals are to do the best we can to protect the projects and the communities at the same time as we ensure that the Foundation follows applicable law.

Within the Legal Affairs team, the privacy group focuses on ensuring that the Foundation-hosted sites and our data collection and handling practices are in line with relevant law, with our own privacy-related policies, and with our privacy values. We believe that individual privacy for contributors and readers is necessary to enable the creation, sharing, and consumption of free knowledge worldwide. As part of that work, we look first at applicable law, further informed by a mosaic of user questions, concerns, and requests, public policy concerns, organizational policies, and industry best practices to help steer privacy-related work at the Foundation. We take these inputs, and we design a legal strategy for the Foundation that guides our approach to privacy and related issues. In this particular case, careful consideration of these factors has led us to this effort to mask IPs of non-logged-in editors from exposure to all visitors to the Wikimedia projects. We can’t spell out the precise details of our deliberations, or the internal discussions and analyses that lay behind this decision, for the reasons discussed above regarding legal ethics and privilege.

We want to emphasize that the specifics of how we do this are flexible; we are looking for the best way to achieve this goal in line with supporting community needs. There are several potential options on the table, and we want to make sure that we find the implementation in partnership with you. We realize that you may have more questions, and we want to be clear upfront that in this dialogue we may not be able to answer the ones that have legal aspects. Thank you to everyone who has taken the time to consider this work and provide your opinions, concerns, and ideas.

––
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 and cc Sandister Tei, Community Relations Specialist – stei 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.