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!
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.
: 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)
: المنع العام وصل. الحسابات المؤقتة على ويكي الاختبار
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.
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.
: خطة إخفاء عنوان الآي بي
كما وعدنا، إليكم تحديث في شأن كيفية عمل إخفاء عنوان الآي بي.
سيتناول هذا التحديث التغييرات التي طرأت على كلا من المحررين غير المسجلين والمسجلين.
نريد أن نعترف من البداية أنه لا يزال أمامنا الكثير من الأسئلة المطروحة دون إجابة وأمور لم نتخذ قرار في شأنها.
هذه هي خطتنا المبدئية وهي لا تتناول كل شيء نستهدف تحقيقه أثناء هذا المشروع.
وبينما نمضي قُدُمًا نكتشف أجزاء جديدة من أعمال لم نتوقعها في السابق.
آرائكم وملاحظاتكم ستساعدنا في استيعاب ما الذي يمكننا عمله أكثر كي نجعل من أعمال إخفاء عنوان الآي بي أسهل على مجتمعاتنا.
صمم هذا التحديث في صيغة أسئلة متكررة شائعة منذ أن هذه الصيغة تجعل من التغييرات القادمة واضحة وسهلة الاستيعاب.
ماذا يعني تغيير إخفاء عنوان الآي بي من منظور محرر غير مسجل الدخول؟
في الوقت الراهن، قبل أن ينتهي مستخدم غير مسجل الدخول من تعديل ما، سيبلغ المستخدم أن تعديلاته سوف توعز إلى عنوان الآي بي الذي يستخدمه.
في المستقبل، قبل أن ينتهي مستخدم غير مسجل الدخول من تعديل ما، سيبلغ المستخدم أن تعديلاته سوف توعز إلى حساب مؤقت.
سيكون اسم الحساب رقم، يزيد لكل حساب جديد.
سوف يربط الحساب بملف تعريف ارتباط يحفظ في متصفح المستخدم.
طالما أن ملف تعريف الارتباط هذا موجود، سيحتفظ المستخدم بذات الحساب المؤقت، وستوعز كافة تعديلاته إلى ذلك الحساب.
يجوز أن تتغير عناوين آي بي المستخدم، إلا أن الحساب المؤقت لن يتغير طالما أن ملف تعريف الارتباط موجود.
سيعمل أي حساب مؤقت ولّد على موقع ويكي على مواقع ويكي أخرى ربما يساهم فيها المستخدم.
ماذا سيكون شكل وصيغة أسماء المستخدمين المؤقتة؟
حتى الآن لا نعلم.
نماذجنا المبدئية نظرت بعين الاعتبار لاستخدام علامة النجمة في صفة بادئة يتبعها رقم يزيد آليًا.
(مثال: *12345.)
سوف تجد هذه النماذج تاليًا.
إلا أن بعض المتطوعين لفتوا انتباهنا لأمر ما وهو أن النجمة ليست خيار مناسب بسبب وجود عطل برمجي قائم في برمجيات ميدياويكي.
حاليًا نناقش خيارات بادئات مختلفة وسوف نجري اختبارات مستخدمين بها.
الخيارات الأولى التي نرشحها (بترتيب غير مقصود) هي كما يلي:
أي مما سلف تراه خيارًا رائعًا أو سيئًا؟
يرجى إضافة تعليقاتكم سواء على صفحة النقاش أو على فبريكاتور.
↑(ربما تكون علامة الاستفهام علامة رائعة على شيء مجهول ويعلمها الكثير، توجد تفاصيل لا زلنا نحاول استيعابها. على سبيل المثال، سيجب ترميزها في معرف المواقع الموحد باستخدام %3F. لا يجب أن يكون هذا الترميز مشكلةً، إلا أنه سيكون مبعث مشاكل للمستخدمين الذين اعتادوا طباعة معرفات المواقع الموحدة يدويًا.)
إلى أي مدة ستظل عناوين المستخدمين المؤقتة؟
لبرهة بعد التعديل الأول (ربما ستكون سنة واحدة) أو نتيجة لمسح الحفظ المؤقت لدى المستخدم، سوف تنتهي صلاحية ملف تعريف الارتباط تلقائيًا.
إلا أن التعديلات القائمة ستوعز إلى ذات حساب المستخدم.
بعد انتهاء صلاحية حساب المستخدم القديم، لو عدّل المستخدم مرة أخرى في المستقبل، سيمنح حسابًا مؤقتًا جديدًا.
ماذا يعني تغيير إخفاء عنوان الآي بي من منظور مراقب تعديلات؟
تقليل التعرض لعناوين الآي بي
إن التغيير الأكبر هو أن عناوين الآي بي لن تصبح منظورة للعموم.
أي شخص ليس لديه حساب أو لا يستوفي الحد الأدنى اللازم للوصول إلى عناوين الآي بي (طالع التحديث القانوني) لن يمكنه الاطلاع على عناوين الآي بي.
من أجل تقليل أثر ذلك على مراقبة التعديلات، سوف ندشن تحسينات على ميزة معلومات عناوين الآي بي.
سيشتمل هذا الأمر على بيانات من خدمة Spur.
الحصول على إمكانية وصول إلى عناوين الآي بي
يدًا بيد مع القسم القانوني التابع للمؤسسة، صُغنا توجيهات جديدة.
تعرّف هذه التوجيهات من سيمكنه الوصول إلى عناوين الآي بي وكيف.
سيمكن للمستخدمين الذين يستوفون المتطلبات اختيار الكشف عن عناوين الآي بي من صفحة خاص:تفضيلات.
طالع كيفية عمل خاصية الكشف بالتفصيل.
سوف تسجل إمكانية الوصول والكشف هذه في سجل وستكون متاحة لمجموعة محدودة من المستخدمين (التحقق من المستخدمينوالمضيفونوفريق الثقة والسلامة).
قنوات اتصال أفضل مع المحررين ذوي الحسابات المؤقتة
سوف تربط الحسابات المؤقتة بملف تعريف ارتباط محفوظ في المتصفح.
طالما أن ملف تعريف الارتباط موجود، سوف توعز تعديلات المستخدم إلى نفس الحساب المؤقت.
سيتمكن أيضًا أصحاب الحسابات المؤقتة من تلقي إشعارات على صفحة النقاش كما هو الحال مع المستخدمين المسجلين.
نأمل أن يفسح هذا الأمر المجال لاتصال أفضل مع المستخدمين ذوي الحسابات المؤقتة.
كما أن هذا الأمر يجوز أن يحل بعض المشاكل طويلة الأجل التي طرحتها المجتمعات (طالع T278838).
توثيق عناوين الآي بي التي يستخدمها المخربون
سيصبح ممكنًا توثيق عناوين الآي بي التي يستخدمها ذوي النوايا السيئة توثيقًا للعموم عن طريق صفحات الإساءة طويلة الأجل، كما هو الحال حاليًا.
إلا أنه يجب توخي الحذر وتجنب الكشف عن عناوين الآي بي التي يستخدمها أصحاب الحسابات المؤقتة الآخرين.
أثناء مناقشة أفعال أصحاب النوايا السيئة، يجب استخدام أدوات مثل الإخفاء لو تبين أن المستخدم غير مخرب حينما ثار الشك في نواياه.
يمكن الاطلاع على مزيد من التفاصيل عن هذا الأمر في التوجيهات.
الأدوات المتاحة لأغراض مراقبة التعديلات
كما هو الحال مع المحررين من عناوين آي بي، يمكن التحقق من المستخدمين أصحاب الحسابات المؤقتة ومراقبة تعديلاتهم عن طريق خاص:منع أو خاص:تحقق من مستخدم أو خاص:تحقق.
خلاف ذلك، يمكن استخدام سمة معلومات عناوين الآي بي للوصول إلى معلومات عن عناوين الآي بي المستخدمة لأي مراجعة كانت.
نصوغ حاليًا توجيهات لأدوات وبوتات للسحابة الحاسوبية للوصل إلى عناوين الآي بي لأغراض مراقبة التعديلات.
سوف ننشر تحديث عن هذا الأمر قريبًا.
ما سيحدث إلى عناوين الآي بي القائمة على مواقعنا؟
عناوين الآي بي القائمة المسجلة من قبل على مواقعنا الويكي ستظل كما هي.
التعديلات الآتية بعد تنفيذ إخفاء عنوان الآي بي سوف تعزى إلى أسماء مستخدمين مؤقتة.
منذ أننا سوف ندشن خاصية إخفاء عناوين الآي بي تدريجيًا، سيعني هذا أن هذا التغيير سوف يحدث على مواقع ويكي مختلفة في أوقات متفاوتة.
كيف ستعمل خاصية الكشف عن عناوين الآي بي؟
سيتمكن المستخدمون الذين يمكنهم الوصول إلى عناوين الآي بي من كشف عناوين آي بي الحسابات المؤقتة.
إليكم مثال على كيفية عمل هذه الخاصية:
ماذا سيحدث للأدوات والبوتات التي تعتمد في عملها على عناوين الآي بي؟
نعكف على استيعاب أثر هذا الأمر على الأدوات التي يتولى صيانتها متطوعين.
هذه مهمة ينهض بها فريقنا وكذلك فريقي الأبحاث والهندسة.
بعد ذلك سوف نتعاون مع الفريق القانوني لاستيعاب ما هي الأدوات التي يجوز لها الاستمرار في الوصول إلى عناوين الآي بي والتوجيهات الخاصة بالكيفية التي يمكن بها تنفيذ عملها.
سوف ننشر تحديثًا على هذه الصفحة حال وجود خطة عمل في هذا الشأن.
خطط التنفيذ
نعتزم اختبار أعمال إخفاء عناوين الآي بي ببطء، وسيشمل ذلك إفساح ما يكفي من وقت كي تقدم المجتمعات آرائها وملاحظاتها وكذلك اختبار الخاصية.
نرغب في ألا ينتج عن تنفيذنا لهذه الخاصية عرقلة أعمال المجتمعات.
أولويتنا الأخرى هي تجنب حدوث نواتج غير مرغوبة على صحة المجتمعات وسلامتها.
لهذا السبب طبقّنا مقاييس نعتزم مراقبتها بينما ننفذ التغييرات المخطط لها.
نبحث عن مجتمعات ترغب في أن تصبح مرشحة لاختبار تدشين (تجربة) خاصية إخفاء عناوين الآي بي.
نفكر جديًا بعض المعايير مثل عدد التعديلات الآتية من عناوين آي بي التي تتلقاها المجتمعات ومدى عجالة أعمال مكافحة التخريب وحجم المشاريع واحتمال حدوث اضطرابات.
سوف ننشر تحديث آخر على هذه الصفحة عن الجهات المرشحة التي وقع علينا اختيارنا في موعد قريب من تشدين خاصية إخفاء عناوين الآي بي.
لو كنت ترغب في أن يختبر مجتمعك تدشين خاصية إخفاء عناوين الآي بي، يرجى اتخاذ قرار في صفة مجتمع وإبلاغنا بذلك على صفحة النقاش.
<span id=":_Refocusing_work_on_IP_Masking">
: إعادة تركيز أعمال إخفاء عناوين الآي بي
مرحبا بكم. سوف نعيد تركيز عملنا رسميًا على مشروع إخفاء عناوين الآي بي الأساسي، منذ أننا انتهينا الآن من المرحلة الأولى من سمة معلومات عناوين الآي بي ومشاريع أخرى متصلة بها. سوف نمضي قدمًا في التخطيط الفني كي نستوعب ما سيحتاج للتغيير حينما يسري تنفيذ أعمال إخفاء عناوين الآي بي. سوف نتواصل مع متطوعينا الفنيين للمساعدة في تقييم التغييرات وترحيل الأدوات حسب مقتضى الحال. بدء بعض من جهود التخطيط هذه بالفعل على فبريكاتور ويجوز لك التواصل معنا هناك لو كانت لديك أسئلة عن مهام بعينها.
سوف اتبع ما سلف بمنشور آخر كي أشارك موجز بالقيمة النافعة الدنيا التي قررناها. هذه القيمة النافعة الدنيا تستند إلى النقاش الذي جرى بيننا وبين المجتمع في السابق، سواء عن طريق هذه الصفحة أو عن طرق أخرى. يرجى عدم التردد في الاطلاع على هذه النقاشات السابقة وكلك آخر الأخبار السابقة المنشورة على هذه الصفحة. لو كانت لديكم أسئلة أو بواعث قلق، يمكنكم التواصل معنا على صفحة النقاش.
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.
<span id=":_IP_Masking_and_changes_to_workflows">
: إخفاء عنوان IP وكيفية حماية مواقع الويكي
ناقشنا طريقتين مختلفتين لإخفاء IP التي نعنيها. كمتابعة لذلك، توصلنا إلى عدد قليل من مهام سير العمل المختلفة وكيف ستتغير مع التطبيقين المختلفين.
ملاحظة: في كلا التطبيقين، سيكون المشرفون والمضيفون والمدققون والمستخدمون الذين لديهم دور IPViewer قادرين على كشف عناوين IP على صفحات مثل أحدث التغييرات والتاريخ، وذلك لأغراض مكافحة التخريب.
تجربة التحرير للمستخدمين غير المسجلين
الوضع الحالي: في الوقت الحالي، يمكن للمستخدمين غير المسجلين التحرير دون تسجيل الدخول (في معظم مواقع الويكي). قبل إجراء التعديل، يظهر لهم رسالة تخبرهم أنه سيتم تسجيل عنوان IP الخاص بهم ونشره بشكل عام.
الهوية المستندة إلى IP أي (IP-based identity): سيتمكن المستخدمون غير المسجلين من التحرير كما هو الحال حاليًا. وقبل إجراء التعديل، سيرون رسالة تُخبرهم أن تعديلاتهم ستُنسب إلى نسخة مشفرة من عنوان IP الخاص بهم. سيكون عنوان IP نفسه مرئيًا للمشرفين والمُراجعين. سيتم الاحتفاظ بها لفترة محدودة من الوقت.
الهوية المستندة إلى الجلسة Session-based identity: هذا مشابه لما ورد أعلاه باستثناء أنه سيتم إخبار المستخدمين بأن تعديلاتهم ستنسب إلى اسم مستخدم تم إنشاؤه تلقائيًا.
لقطة شاشة للهوية المستندة إلى IP
لقطة شاشة للهوية المستندة إلى الجلسة
التواصل حول المستخدمين غير المسجلين
الوضع الحالي: تتم الإشارة إلى المستخدمين غير المسجلين من خلال عناوين IP الخاصة بهم أو إذا كانوا مخربين معروفين على المدى الطويل، فغالبًا ما يتم إعطاؤهم اسمًا بناءً على سلوكهم.
الهوية المستندة إلى IP: لن يتمكن المراجعون والمشرفون من الإشارة إلى عناوين IP علنًا ولكن سيتمكنوا من الإشارة إلى عنوان IP المشفر أو اسم المُسيء على المدى الطويل. ويمكنهم مشاركة عنوان IP مع الآخرين الذين يمكنهم الوصول إليه.
الهوية المستندة إلى الجلسة: لن يتمكن المراجعون والمشرفون من الإشارة إلى عناوين IP علنًا ولكن سيتمكنوا من الإشارة إلى أسماء المستخدمين التي تم إنشاؤها تلقائيًا. يمكنهم مشاركة عنوان IP مع الآخرين الذين يمكنهم الوصول إليه. يمكن أن يساعد ذلك في تحديد جهة فاعلة معينة، ولكن قد يكون محيرًا أيضًا إذا كان هناك العديد من عناوين IP وراء اسم المستخدم، على غرار عدد الأشخاص المختلفين الذين يمكن أن يكونوا وراء IP اليوم. لتخفيف هذا القلق، نقوم ببناء أداة ستكون قادرة على عرض معلومات حول جميع عناوين IP المختلفة التي ينشط المستخدم من خلالها.
تجربة صفحات النقاش للمستخدمين غير المسجلين
الوضع الحالي: يمكن للمستخدم غير المسجل تلقي الرسائل على صفحة النقاش لعنوان IP الخاص به. بمجرد تغيير عنوان IP الخاص به، فإنه يتلقى الرسائل على صفحة نقاش عنوان IP الجديد. هذا يُقَسِّم المحادثات ويجعل من الصعب البقاء على اتصال مع مستخدم معين غير مسجل.
الهوية المستندة إلى IP: في هذا التطبيق، يظل الوضع كما هو حاليًا. سيتلقى المستخدمون غير المسجلين رسائل على صفحات نقاش IP المشفرة الخاصة بهم، وبمجرد تغيير عنوان IP الخاص بهم، تتغير صفحة الحديث المرتبطة بهم أيضًا.
الهوية المستندة إلى الجلسة: في هذا التطبيق، يتلقى المستخدمون غير المسجلين رسائل على صفحة نقاش مرتبطة بملف تعريف ارتباط cookie في متصفحهم. حتى إذا تغير عنوان IP الخاص بهم، فإن ذلك لا يزال يسمح لهم بتلقي الرسائل على صفحة النقاش الخاصة بهم. إذا تم مسح ملف تعريف ارتباط المتصفح الخاص بهم، فلن يحتفظوا بهوية الجلسة الخاصة بهم وسيتلقون ملف تعريف ارتباط جديدًا وصفحة نقاش جديدة مرتبطة بذلك. نظرًا لأن عناوين IP تتغير بشكل متكرر أكثر من ملفات تعريف الارتباط، فمن المحتمل أن ينتهي الأمر بالعديد من المستخدمين بصفحة نقاش شبه دائمة ما لم يحاولوا على وجه التحديد عدم القيام بذلك. ميزة أخرى يجب ملاحظتها هي أن رسائل صفحة النقاش لن تصل إلى مستخدم آخر في أي حال.
إشعارات صفحة النقاش
منع المستخدمين غير المسجلين
الوضع الحالي: يمكن للمشرف حظر عنوان IP أو نطاق IP مباشرة. بالإضافة إلى ذلك، يمكنهم تحويله إلى حظر تلقائي يمكنه الاحتفاظ بملف تعريف الارتباط في متصفح المستخدم والذي يمنعهم من التحرير حتى إذا قاموا بتغيير عناوين IP. تم العمل بهذه الوظيفة قبل بضع سنوات.
الهوية المستندة إلى IP: يظل الوضع كما هو حاليًا. يجري إخفاء عناوين IP بشكل افتراضي ولكن يمكن للمشرفين والمراجعين الذين لديهم الصلاحيات الوصول إليها.
الهوية المستندة إلى الجلسة: يتيح لنا هذا التطبيق الاحتفاظ بالوضع الحالي للمنع بواسطة عناوين IP. كما يسمح لنا أيضًا بأداء المنع القائم على ملفات تعريف الارتباط فقط. يمكن أن يكون هذا مفيدًا في الحالات حين يشارك الأشخاص الأجهزة (مثل مكتبة أو مقهى إنترنت) ويؤدي حظر عنوان IP أو نطاق عناوين IP إلى منع غير ضروري. نود الإشارة إلى أن هذا لن ينجح في الحالات التي يكون فيها المخربون محررين ذوي خبرة ويمكنهم التهرب من منع ملفات تعريف الارتباط.
تساعد هذه الأسئلة الشائعة في الإجابة على بعض الأسئلة المحتملة التي سيطرحها المجتمع حول أساليب التنفيذ المختلفة التي يمكننا اتباعها لإخفاء IP وكيف سيؤثر كل منها على المجتمع.
س: بعد تنفيذ إخفاء IP، من سيتمكن من رؤية عناوين IP؟
ج: سيتمكن المدققون والمضيفون والمشرفون من رؤية عناوين IP الكاملة عن طريق الاشتراك في تفضيل حيث يوافقون على عدم مشاركتها مع الآخرين الذين ليس لديهم إمكانية الوصول إلى هذه المعلومات.
مكن منح المحررين الذين يشاركون في أنشطة مكافحة التخريب، التي أقرها المجتمع، الحق في رؤية عناوين IP لمواصلة عملهم. سيتم التعامل مع هذا الحق للمستخدم مثل حقوق المستخدم الأخرى من قبل المجتمع، ويتطلب حدًا أدنى من التعديلات وفترة التسجيل.
سيتمكن جميع المستخدمين الذين لديهم حسابات تزيد عن عمر معين ولديهم حد أدنى من التعديلات (يتم تحديدها) من الوصول إلى عناوين IP غير المقنعة جزئيًا partially unmasked IP دون إذن. هذا يعني أن عنوان IP سيظهر مع إخفاء بتات الذيل tail octet(s) -الأجزاء الأخيرة-. يمكن الوصول إلى هذا عبر "تفضيل" حيث يوافقون على عدم مشاركته مع الآخرين الذين لا يمكنهم الوصول إلى هذه المعلومات.
لن يتمكن جميع المستخدمين الآخرين من الوصول إلى عناوين IP للمستخدمين غير المسجلين.
س: ما هي خيارات التنفيذ الفني المحتملة؟
ج: على مدار الأسابيع القليلة الماضية، انخرطنا في مناقشات متعددة حول الإمكانيات التقنية لتحقيق هدفنا في إخفاء عنوان IP مع تقليل التأثير على المستخدمين والقراء لدينا. لقد جمعنا التعليقات من مختلف الفِرق وحصلنا على وجهات نظر مختلفة. فيما يلي المساران الرئيسيان:
الهوية القائمة على IP: في هذا الأسلوب، نحتفظ بكل شيء كما هو ولكن نستخدم نسخة مجزأة من عناوين IP بديلا عن عناوين IP الحالية. هذا يحافظ على الكثير من مهام سير العمل الحالية لدينا ولكنه لا يقدم أي مزايا جديدة.
الهوية المستندة إلى الجلسة: في هذا التطبيق، نقوم بإنشاء هوية للمستخدمين غير المسجلين بناءً على ملف تعريف ارتباط المتصفح الذي يحدد متصفح أجهزتهم. ويستمر ملف تعريف الارتباط حتى عندما يتغير عنوان IP الخاص بهم وبالتالي لا تنتهي جلستهم.
س: كيف يعمل مسار الهوية المستندة إلى IP؟
ج: في الوقت الحالي، يتم تحديد المستخدمين غير المسجلين من خلال عناوين IP الخاصة بهم. لقد نجح هذا النموذج في مشاريعنا لسنوات عديدة. يفهم المستخدمون المتمرسون في عناوين IP أنه يمكن استخدام عنوان IP واحد من قِبل عدة مستخدمين مختلفين بناءً على مدى ديناميكية عنوان IP هذا. هذا صحيح بالنسبة لعناوين IP مثل IPv6 أكثر من IPv4.
قد يقوم مستخدم غير مسجل أيضًا بتغيير عناوين IP إذا كان يتنقل أو يقوم بالتحرير من موقع مختلف.
إذا سعينا وراء حل "الهوية المستند إلى IP" لإخفاء IP، فسنحافظ على الطريقة التي تعمل بها عناوين IP اليوم عن طريق إخفاءها ببساطة بمُعَرِّف مشفر. سيحافظ هذا الحل على عناوين IP مميزة مع الحفاظ على خصوصية المستخدم. على سبيل المثال، قد يظهر مستخدم غير مسجل مثل مستخدم:192.168.1.2 كمستخدم:ca1f46.
فوائد هذا التطبيق:
يحافظ على مهام سير العمل والنماذج الحالية بأقل قدر من التعطيل.
عيوب هذا التطبيق:
لا يقدم أي مزايا في عالم يتحرك بسرعة نحو عناوين IP أكثر ديناميكية/أقل فائدة.
س: كيف يعمل مسار الهوية المستندة إلى الجلسة؟
ج: يقوم هذا التطبيق بإنشاء هوية جديدة للمستخدمين غير المسجلين بناءً على ملف تعريف ارتباط يتم وضعه في متصفحهم. في هذا الأسلوب، يوجد اسم مستخدم تم إنشاؤه تلقائيًا تُنسب إليه تعديلاتهم وإجراءاتهم. على سبيل المثال، يمكن إعطاء المستخدم:192.168.1.2 اسم مستخدم:Anon3406.
في هذا التطبيق، ستستمر جلسة المستخدم طالما كان لديه ملف تعريف الارتباط، حتى عند تغيير عناوين IP.
فوائد هذا التطبيق:
يربط هوية المستخدم بمتصفح الجهاز، مما يوفر طريقة أكثر ثباتًا للتواصل معهم.
هوية المستخدم لا تتغير مع تغيير عناوين IP
يمكن أن يوفر هذا النهج طريقة للمستخدمين غير المسجلين للوصول إلى تفضيلات معينة متاحة حاليًا للمستخدمين المسجلين فقط
يمكن أن يوفر هذا الأسلوب طريقة للمستخدمين غير المسجلين للتحويل إلى حساب دائم مع الاحتفاظ بسجل التحرير الخاص بهم
عيوب هذا التطبيق:
تغيير كبير في النموذج الحالي لما يمثله المستخدم غير المسجل
تستمر هوية المحرر غير المسجل فقط طالما استمر ملف تعريف ارتباط المتصفح
سيحصل المخربون في "وضع الخصوصية" أو الذين يحذفون ملفات تعريف الارتباط الخاصة بهم على هوية جديدة دون تغيير عنوان IP الخاص بهم
قد يتطلب إعادة التفكير في بعض خطوات سير العمل والأدوات للمجتمع
س: هل المؤسسة تفضل أحد الاقتراحين؟
ج: مسارنا المفضل هو العمل بـ "الهوية المستندة إلى الجلسة"، لأنه سوف يفتح العديد من الفرص في المستقبل.
بإمكاننا أن نتعامل مع قضايا تواصلية لمدة عشرون سنة.
وعندما يقوم البعض بحذف التعريفات المرتبطة به ليحصل على هوية جديدة، سيظل الـ IP ظاهرا لكل محاربي التخريب مع صلاحيات المستخدم الجديدة. نحن نعلم أن حذف ملفات الارتباط (كوكيز) من جهاز أسهل من تغيير ال IP، ونتوقع تأثير ذلك.
: اقتراح مشاركة عناوين الآي بي مع هؤلاء الذين يحتاجون للوصول إليها
Hi everyone. It has been a few months since our last update on this project. We have taken this time to talk to a lot of people — across the editing community and within the Foundation. We have put careful consideration towards weighing all the concerns raised in our discussions with experienced community members about the impact this will have on anti-vandalism efforts across our projects. We have also heard from a significant number of people who support this proposal as a step towards improving privacy of unregistered editors and reducing the legal threat that exposing IPs to the world poses to our projects.
When we talked about this project in the past, we did not have a clear idea of the shape this project will take. Our intention was to understand how IP addresses are helpful to our communities. We have since received a lot of feedback on this front from a number of conversations in different languages and in different communities. We are very grateful to all the community members who took the time to educate us about how moderation works on their wikis or in their specific cross-wiki environment.
We now have a more concrete proposal for this project that we hope will allow for most of the anti-vandalism work to happen undeterred while also restricting access to IP addresses from people who don’t need to see them.I want to emphasize the word “proposal” because it is in no way, shape or form a final verdict on what will happen. Our intention is to seek your feedback about this idea – What do you think will work? What do you think won’t work? What other ideas can make this better?
We developed these ideas during several discussions with experienced community members, and we’ve refined them in collaboration with our Legal department. Here’s the outline:
Checkusers, stewards and admins should be able to see complete IP addresses by opting-in to a preference where they agree not to share it with others who don't have access to this information.
Editors who partake in anti-vandalism activities, as vetted by the community, can be granted a right to see IP addresses to continue their work. This could be handled in a similar manner as adminship on our projects. The community approval is important to ensure that only editors who truly need this access can get it. The editors will need to have an account that meets some threshold of time since registration (threshold is yet to be decided) and number of edits (number is yet to be decided).
All users with accounts that meet some threshold of time since registration (threshold is yet to be decided) and number of edits (number is yet to be decided) will be able to access partially unmasked IPs without permission. This means an IP address will appear with its tail octet(s) – the last part(s) – hidden. This will be accessible via a preference where they agree not to share it with others who don't have access to this information.
All other users will not be able to access IP addresses for unregistered users.
IP address access will be logged so that due scrutiny can be performed if and when needed. This is similar to the log we maintain for checkuser access to private data. This is how we hope to balance the need for privacy with the communities’ need to access information to fight spam, vandalism and harassment. We want to give the information to those who need it, but we need a process, we need it to be opt-in so that only those with an actual need will see it and we need the accesses to be logged.
We would like to hear your thoughts about this proposed approach. Please give us your feedback on the talk page.
لقطة شاشة للهوية المستندة إلى IP
لقطة شاشة للهوية المستندة إلى الجلسة
.png)