IP Editing: Privacy Enhancement and Abuse Mitigation/Updates/fa

This page is a translated version of the page IP Editing: Privacy Enhancement and Abuse Mitigation/Updates and the translation is 14% complete.

September 2023: New features, new names, and Wikimania

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 qustions 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.
Wikimania slide deck

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.

Older updates

April 2023: The Plan for IP Masking

As promised, here's an update about how IP Masking would work.

It will cover the changes for both unregistered and registered editors. We want to acknowledge at the outset that we still have lots of open questions and things we have not decided upon. This is our initial plan and does not cover everything we aim to do during this project. As we are proceeding we are discovering new pieces of previously unforeseen work.

Your feedback will help us understand what more we can do to make IP Masking easier on our communities.

This update is an FAQ format as that makes the upcoming changes clear and understandable.

What does IP Masking change from the perspective of a non-logged-in editor?

Currently, before a non-logged-in user completes an edit, they are informed that their edits will be attributed to their IP address.

In the future, before a non-logged-in user completes an edit, they will be informed that their edits will be attributed to a temporary account. Its name will be a number, incrementing for each new account. The account will be tied to a cookie that lives in the user's browser. As long as that cookie exists, the user will keep the same temporary account, and all their edits will be attributed to that account. The IP addresses of the user may change, but the temporary account will not change as long as the cookie exists. A temporary account generated on one wiki will also work on other wikis that the user may contribute to.

What will temporary usernames look like?

We don't know yet.

Our initial mockups considered using an asterisk as a prefix followed by an auto-incrementing number. (Example: *12345.) You will find these mockups below.

But as some volunteers pointed out, the asterisk is not a good choice because of an outstanding MediaWiki bug.

We are discussing different prefix options and will be conducting user tests with these.

Our current top candidates (in no particular order) are:

  • Caret (^) – User:^12345
  • Hyphen (-) – User:-12345
  • Tilde (~) – User:~12345
  • Exclamation mark (!) – User:!12345
  • Question mark (?)[1]User:?12345
  • Year prefix – User:2023-12345

Do any of these strike you as a great or a terrible choice? Please add your comments either on the talk page or Phabricator.

  1. (While the question mark is a great sign for something unknown and is widely understood, there are details we're still figuring out. For example, it'll need to be encoded into the URL using %3F. This URL encoding shouldn't be a problem, but would be a hiccup for users who are used to typing in URLs by hand.)

How long do temporary usernames persist for?

Some time after the first edit (tentatively one year) or as a result of clearing the user's cache, the cookie will automatically expire.

Existing edits will still be attributed to it, though.

After the old username expires, if the user edits again in the future, they will be granted a new temporary account.

What does IP Masking change from the perspective of a patroller?

Limited IP address exposure

The biggest change is that IP addresses will no longer be visible to the general public.

Anyone who does not have an account or does not meet the required thresholds for IP address access (see Legal's update) will not be able to see IP addresses. To mitigate the impact on patrolling, we will be releasing improvements to IP Info Feature.

This will include data from the Spur service.

Obtaining access to IP addresses

Together with the Foundation's Legal department, we have developed new guidelines.

These define who will be able to access IP addresses and how. Users who meet the requirements will be able to opt-in to reveal IP addresses through Special:Preferences. See how the reveal functionality will work in detail.

This access and reveal will be logged and will be available to a limited group of users (CheckUsers, stewards, Trust & Safety).

Better communication channels with temporary editors

Temporary accounts will be linked to a browser cookie.

As long as the cookie persists, the user's edits will be attributed to the same temporary account. Temporary account holders will also be able to receive talk page notifications just like registered users. We hope this will allow for better communication with temporary users. It may also resolve some long-standing issues raised by the communities (see T278838).

Documenting IP addresses for vandals

It will be possible to document IP addresses for bad actors publicly through long-term abuse pages, as currently.

However, care should be taken to not expose IP addresses for other temporary users. When discussing possible bad actors, tools like suppression should be used if the user is not found to be a vandal as suspected.

More details about this can be found in the guidelines.

Tools available for patrolling

Like IP editors, temporary users can be checked and patrolled through Special:Block, Special:Checkuser and Special:Investigate.

Additionally, IP Info Feature can be used to access information about the underlying IP address for the given revision.

We are developing guidelines for Cloud tools and bots to access IPs for patrolling.

We will have an update for this soon.

What happens to existing IP addresses on our sites?

Existing IP addresses that are already recorded on our wikis will remain untouched.

Edits that come in after IP Masking will be attributed to temporary usernames.

Since we will roll out IP Masking gradually, this will mean that this change will happen on different wikis at different times.

How will the IP address reveal functionality work?

Users who can access IP addresses will be able to expose IP addresses for temporary accounts.

Mockups for how this functionality would work:

What will happen to tools and bots that rely on IP addresses to function?

We are working to understand the impact to volunteer-maintained tools.

This is a task for our team as well as the Research and Engineering teams. Next, we will work with Legal to understand which tools may continue to access IP addresses and the guidelines for how they can operate.

We will provide an update on this page once we have a plan of action.

Rollout plans

We plan to test IP Masking slowly, to include ample time for communities' feedback and testing.

We want our rollouts not to hinder communities' processes. Our another priority is to avoid undesirable outcomes for the health of the communities. We have implemented metrics that we plan to watch as we roll out the changes. We are looking for communities that would be candidates for testing launch (piloting) of IP Masking. We are considering criteria such as number of IP edits the communities receive, urgency of anti-vandalism work, size of the project, and potential for disruption. We will have another update on this page about our chosen candidates closer to the launch of IP Masking.

If you'd like your community to test the launch of IP Masking, please make a decision as a community and let us know on the talk page.

February 16, 2023: 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.

February 25, 2022: 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.

December 9, 2021: پوشش آی‌پی و نحوهٔ محافظت از ویکی‌ها

ما دو رویکرد متفاوت برای پوشش آی‌پی را که در نظر داریم مورد بحث قرار دادیم. در ادامه آن، ما با چند گردش کار متفاوت و نحوه تغییر آنها با دو پیاده‌سازی متفاوت مواجه شده‌ایم.

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.

تجربه ویرایش برای ویرایشگران ثبت‌نام نشده

روش فعلی: در حال حاضر، ویرایشگران ثبت‌نام نشده می‌توانند بدون ورود به سیستم (در اکثر ویکی‌ها) ویرایش کنند. قبل از انجام ویرایش، اعلامیه‌ای را می‌بینند که به آنها می‌گوید به صورت دائمی آدرس آی‌پی آنها به طور عمومی ضبط و منتشر می‌شود.

هویت آی‌پی-محور: ویرایشگران ثبت‌نام نشده می‌توانند مانند حال حاضر ویرایش کنند. قبل از انجام ویرایش، آنها پیامی را می‌بینند که به آنها می‌گوید که ویرایش‌های آنها به نسخه رمزگذاری‌شده آدرس آی‌پی آنها نسبت داده می‌شود. خود آدرس آی‌پی برای مدیران و گشت‌بانان قابل مشاهده خواهد بود. برای مدت زمان محدودی حفظ خواهد شد.

هویت دوره-محور: این شبیه به بالایی است، با این استثنا که به ویرایشگران گفته می‌شود که ویرایش‌های آنها به یک نام کاربری تولید شده به طور خودکار نسبت داده می‌شود.

برقراری ارتباط در مورد ویرایشگران ثبت‌نام نشده

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.

تجربهٔ صفحهٔ بحث برای ویرایشگران ثبت‌نام نشده

روش فعلی: یک ویرایشگر ثبت‌نام نشده می‌تواند پیام‌هایی را در صفحهٔ بحث برای آی‌پی خود دریافت کند. هنگامی که آدرس آی‌پی ویرایشگر تغییر می‌کند، آنها پیام‌هایی را در صفحهٔ بحث آدرس آی‌پی جدید دریافت می‌کنند. این کار مکالمات را منقطع می‌کند و برقراری ارتباط با یک ویرایشگر ثبت‌نام نشدهٔ خاص را دشوار می‌کند.

هویت آی‌پی-محور: در این پیاده‌سازی، روش فعلی باقی می‌ماند. ویرایشگران ثبت‌نام نشده پیام‌هایی را در صفحات بحث آی‌پی رمزگذاری شده خود دریافت خواهند کرد و هنگامی که آی‌پی آنها تغییر کرد، صفحهٔ بحث مرتبط با آنها نیز تغییر می‌کند.

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 screenshot
اعلان صفحهٔ بحث

مسدودسازی ویرایشگران ثبت‌نام نشده

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.

October 2021: رویکردهای پیاده‌سازی پوشش آی‌پی (سؤالات متداول)

This FAQ helps answer some likely questions the community will have about the various implementation approaches we can take for IP Masking and how each of them will impact the community.

Q: Following implementation of IP Masking, who will be able to see IP addresses?

A: Checkusers, stewards and admins will 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 user right would be handled like other user rights by the community, and require a minimum number of edits and days spent editing.

All users with accounts over a certain age and with a minimum number of edits (to be determined) will be able to access partially unmasked IPs without permission. This means an IP address will appear with its tail octet(s) – the last parts – 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.

Q: What are the potential technical implementation options?

A: Over the last few weeks we have been engaged in multiple discussions about the technical possibilities to accomplish our goal for IP Masking while minimizing impact to our editors and readers. We gathered feedback from across different teams and gained varying perspectives. Below are the two key paths.

  • IP based identity: In this approach, we keep everything as is but replace existing IP addresses with a hashed version of IPs. This preserves a lot of our existing workflows but does not offer any new benefits.
  • Session based identity: In this approach, we create an identity for the unregistered editors based on a browser cookie which identifies their device browser. The cookie persists even when their IP address changes hence their session does not end.

Q: How does IP based identity path work?

A: At present, unregistered editors are identified by their IP addresses. This model has worked for our projects for many years. Users well-versed with IP addresses understand that a single IP address can be used by multiple different users based on how dynamic that IP address is. This is more true for IPv6 IP addresses than IPv4.

An unregistered user may also change IP addresses if they are commuting or editing from a different location.

If we pursue the IP-based identity solution for IP Masking, we would be preserving the way IP addresses function today by simply masking them with an encrypted identifier. This solution will keep the IPs distinct while maintaining user privacy. For example, an unregistered user such as User: may appear as User:ca1f46.

مزایای این رویکرد: Preserves existing workflows and models with minimal disruption

معایب این رویکرد: Does not offer any advantages in a world moving rapidly towards more dynamic/less useful IP addresses

Q: How does session-based identity path work?

A: The path is to create a new identity for unregistered editors based on a cookie placed in their browser. In this approach there is an auto-generated username which their edits and actions are attributed to. For example, User: might be given the username: User:Anon3406.

In this approach, the user’s session will persist as long as they have the cookie, even when they change IP addresses.

مزایای این رویکرد:

  • Ties the user-identity to a device browser, offering a more persistent way to communicate with them.
  • User identity does not change with changing IP addresses
  • This approach can offer a way for unregistered editors to have access to certain preferences which are currently only available to registered users
  • This approach can offer a way for unregistered editors to convert to a permanent account while retaining their edit history

معایب این رویکرد:

  • Significant change in the current model of what an unregistered editor represents
  • The identity for the unregistered editor only persists as long as the browser cookie does
  • Vandals in privacy mode or who delete their cookies would get a new identity without changing their IP
  • May require rethinking of some community workflows and tools

Q: Does the Foundation have a preferred path or approach?

A: Our preferred approach will be to go with the session-based identity as that will open up a lot of opportunities for the future. We could address communication issues we’ve had for twenty years. While someone could delete the cookie to get a new identity, the IP would still be visible to all active vandal fighters with the new user right. We do acknowledge that deleting a cookie is easier than switching an IP, of course, and do respect the effects it would have.

June 10, 2021: پیشنهاد به‌اشتراک‌گذاری نشانی‌هایی آی‌پی با کسانی که به این دسترسی نیاز دارند

سلام بر همگی. از آخرین بروزرسانی برای این پروژه چند ماه می‌گذرد. ما در این مدت با افراد زیادی — در میان اجتماع ویرایشگران و در داخل بنیاد — گفتگو کرده‌ایم. ما در خصوص ارزیابی همهٔ نگرانی‌های مطرح‌شده در گفتگوهای خود با اعضای باتجربهٔ جامعه در مورد تأثیری که این امر بر تلاش‌ها جهت مبارزه با خرابکاری در سرتاسر پروژه‌های ما ایجاد می کند، دقت ویژه‌ای داشته‌ایم. همچنین حرف‌های تعداد قابل توجهی از افرادی که حامی این پیشنهاد به‌عنوان گامی به سوی بهبود حریم خصوصی ویرایشگران ثبت‌نام‌نکرده و کاهش تهدیدهای حقوقی که به‌واسطهٔ فاش‌سازی نشانی‌های آی‌پی برای همگان، متوجه پروژه‌های ما می‌شود، هستند ار نیز شنیده‌ایم.

زمانی که در گذشته دربارهٔ این پروژه گفتگو کردیم، ایدهٔ واضحی برای شکل‌دهی به این پروژه نداشتیم. قصد ما، درک چگونگی مفید بودن نشانی‌های آی‌پی برای اجتماعاتمان بوده‌است. ما از آن زمان تاکنون بازخوردهای زیادی در این زمینه از تعدادی از گفتگوها در زبان‌های مختلف و اجتماع‌های مختلف دریافت کرده‌ایم. ما از تمامی اعضای احتماع که زمان خود را صرف آگاه‌سازی ما دربارهٔ چگونگی انجام کارهای گرداندن ویکی‌های خود یا محیط میان‌ویکیایی خاص خود کرده‌اند، بسیار سپاسگزاریم.

ما اکنون پیشنهادی مشخص‌تر برای این پروژه داریم که امیدواریم امکان انجام بی‌درنگ بیشتر کارهای مبارزه با خرابکاری را فراهم کند و در عین حال دسترسی به نشانی‌های آی‌پی را برای افرادی که نیازی به دیدن آن‌ها ندارند، محدود کنیم. قصد دارم روی واژهٔ «پیشنهاد» تأکید کنم؛ چرا که به‌هیچ شکل، نحو یا گونه‌ای نشان‌دهندهٔ آنچه اتفاق خواهد افتاد، نیست. قصد ما این است که بازخورد شما پیرامون این ایده را بدانیم – فکر می‌کنید چه‌چیزی کارساز خواهد بود؟ معتقید چه‌چیزی کارساز نخواهد بود؟ چه ایده‌هایی می‌توانند بهبودش دهند؟

ما این ایده‌ها را در پی گفتگوهای متعدد با اعضای باتجربهٔ اجتماع توسعه داده‌ایم و آن‌ها را با همکاری بخش حقوقی بنیاد اصلاح کرده‌ایم. طرح کلی به‌شرح زیر است:

  • بازرسان کاربر، ویکی‌بدها و مدیران باید بتوانند به‌واسطهٔ تعهد به عدم به‌اشتراک‌گذاری نشانی‌های آی‌پی با سایر افرادی که به این اطلاعات دسترسی ندارند، این نشانی‌ها را به‌طور کامل مشاهده کنند.
  • ویرایشگرانی که در فعالیت‌های ضد خرابکاری مشارکت دارند، طبق آنچه مورد توافق اجتماع است، می‌توانند برای ادامه‌دادن به کار خود، دسترسی مشاهدهٔ نشانی‌های آی‌پی را کسب کنند. این کار می‌تواند به طریقی مشابه کسب دسترسی مدیریت در پروژه‌های ما انجام پذیرد. به‌منظور حصول اطمینان از این که تنها ویرایشگرانی که نیاز مبرم به این دسترسی دارند، به آن دست می‌یابند، تأیید اجتماع برای این کار بسیار مهم است. ویرایشگران برای کسب این دسترسی، ملزم به داشتن حساب کاربری با حداقل عمر یک سال و داشتن دست کم ۵۰۰ ویرایش هستند.
  • تمامی کاربرانی که عمر حساب آنان بیش از یک سال باشد و دست کم ۵۰۰ ویرایش داشته‌باشند، قادر خواهند بود بدون کسب دسترسی، بخشی از نشانی‌های آی‌پی را مشاهده کنند. این بدین معنی است که بخش‌های پایانی نشانی آی‌پی مخفی خواهد بود. این قابلیت به‌واسطهٔ ترجیحاتی در دسترس خواهد بود که بر مبنای آن، کاربر متعهد می‌شود تا نشانی آی‌پی را با سایر افرادی که به این اطلاعات دسترسی ندارند، به اشتراک نگذارد.
  • سایر کاربران قادر به مشاهدهٔ نشانی آی‌پی کاربران ثبت‌نام‌نکرده نخواهند بود.

دسترسی به نشانی آی‌پی در سیاهه ثبت خواهد شد تا در صورت نیاز، امکان بررسی دقیق میسر باشد. این مشابه سیاهه‌ای است که از دسترسی بازرسان به اطلاعات خصوصی جمع‌آوری می‌شود. اینگونه است که امیدواریم بتوانیم تعادلی میان نیاز به حفظ حریم خصوصی و نیازهای اجتماع به دسترسی به اطلاعات جهت مبارزه با هرزنگاری، خرابکاری و آزار و اذیت برقرار کنیم. ما می‌خواهیم اطلاعات را در اختیار کسانی قرار دهیم که به آن نیاز دارند؛ اما نیاز به یک فرآیند داریم و لازم است که تنها افرادی منتخب با نیاز مبرم قادر به مشاهدهٔ نشانی‌های آی‌پی باشند و نیاز داریم که دسترسی به این اطلاعات در یک سیاهه ثبت شود.

ما مشتاق هستیم که نظرات شما در مورد این روش پیشنهادی را بدانیم. لطفاً بازخوردهای خود را در صفحهٔ بحث با ما در میان بگذارید.

  • به‌نظر شما چه‌چیزی کارساز خواهد بود؟
  • به‌نظر شما چه‌چیزی کارساز نخواهد بود؟
  • چه ایده‌هایی باعث بهبود این ایده می‌شوند؟