: 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.
Older updates
: 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.
: 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:
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.
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.
: Refocusing work on IP Masking
Hi all. We’re officially refocusing our work on the core IP Masking project, now that we have completed the first phase on IP Info feature and other related projects. We are moving forward with technical planning to understand what will need to change when IP Masking goes into effect. We will be reaching out to our technical volunteers to help evaluate changes and migrate tools, as needed. Some of this planning work has already started on Phabricator, and you may reach out to us there if you have questions about specific tasks.
I will follow this up with another post shortly to share an outline of the MVP (Minimum Viable Product) we have landed on. This MVP is based on the conversations we have had with the community in the past, through this page and other mediums. Please feel free to peruse those previous conversations and read through the past updates on this page. If you have questions or concerns, you can reach out to us on the talk page.
: 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
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.
IP-based identity screenshot
Session-based identity screenshot
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 (שאלות ותשובות)
השאלות והתשובות שמוצגות פה עונות על השאלות שצפינו שיהיו לחברי הקהילה לגבי הגישות השונות שאנחנו יכולים ליישם בנוגע להסוואת כתובות 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 מציבה בפני המיזמים שלנו.
כשדיברנו בעבר על הפרויקט הזה, לא היה לנו ברור לאן הוא מועד. הכוונה שלנו הייתה להבין איך כתובות 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), כך שרק אלו שבאמת צריכים את המידע יהיו יכולים לראות אותו. בנוסף, אנחנו צריכים שהגישה למידע תתועד.
אנחנו רוצים לשמוע מה אתם חושבים על גישה מוצעת זו. אנא ספקו לנו פידבק בדף השיחה.
IP-based identity screenshot
Session-based identity screenshot
.png)