Talk:IP Editing: Privacy Enhancement and Abuse Mitigation/Archives/2021-11

From Meta, a Wikimedia project coordination wiki

Authorship concerns

  1. IP adress can be assigned to different users so edits from IP are unquestionably anonymous and will stay such virtually forever. When you choose for user meaningful ID you make edits "pseudonymous" not anonymous. Right now you cannot register username that resembles IP address. With introduction of ID I see no technique to prevent user from mocking up themself as "temporary" user. I feel some unconfidence with this.
  2. If you assign ID through cookies what will prevent people from stealing such cookies to identify themselves as another person? For example, if I want to delete sole contribution of ID-assigned user I can use cookies to make speedy deletion request "by author".
  3. Will all the ID be uniq? IPs is knowingly not uniq what makes them truly anonymous. If there will be repetitive IDs, one can pretend to be author of other's work and, for example, do speedy deletion "by author requests" without any right to do that. I am really concerned whether you can make IDs uniq because this make them exhaustable and vulnerable to simple bruteforce attacks. Or they will be too long or too ugly.
  4. My last concern depends on uniqueness of ID, if they are such, there will be no problem. But this is a legal question. Author's name is protected by law. After you assign it to one user, is is doubtful you can freely assign the same name to another user.
--Igel B TyMaHe (talk) 12:20, 11 November 2021 (UTC)
@Igel B TyMaHe Hello.
  1. We will make sure that unregistered usernames look distinct from registered usernames. They will also be randomly auto-generated and assigned but not self-selected by the end user. This can change though, if needed.
  2. I am not sure if I understand your question. How can someone steal cookies?
  3. IDs will always be unique to the cookie. They could be an auto-assigned ID number or such. Can you elaborate on why IDs will be vulnerable to bruteforce attacks? What would that achieve? --
NKohli (WMF) (talk) 03:01, 17 November 2021 (UTC)
(To be clear, I think we're talking about session hijacking. Please confirm so we all understand each other.)
Re: the legal aspect of authorship, nothing should change here. IPs are already not unique, for that matter. /Johan (WMF) (talk) 17:33, 18 November 2021 (UTC)

Everyone is a sockpuppet

If a pack of newly registered accounts enters a discussion, everyone knows how to handle that. From now on, whenever an honest EX-IP-user tries to discuss, everyone will ‘know’ they’re nothing more than a sock manipulating with cookies. Way to go. — 188.123.231.59 00:00, 11 November 2021 (UTC)

Well, first of all, a lot of people would have access to the user right where they can see the masked IP; there won't be anywhere near anything the checkuser process. So any such suspicion would be easy to check and confirm or dismiss, at least to degree we can do so with IPs. (IP jumping is, of course, a thing. But that's the case today too.) Second, whether to base it on a cookie or to an IP is up for discussion. They both have their drawbacks and benefits. /Johan (WMF) (talk) 01:15, 11 November 2021 (UTC)
Which makes participants a lot less equal, again. Equality in discussions would require masking registered accounts names as well, and from everyone, so that only arguments would matter in dispute resolution, not reputations. As for IP jumping it’s only easy for some, while cookie exploiting is for everyone. — 188.123.231.59 08:05, 11 November 2021 (UTC)
I'd say cookie exploiting still is for a minority – most people don't have any idea of how cookies work. But of course you're right that it makes it easier, nor that we don't have a problem with unregistered users not being fully respected partners of a conversation (which, at least on the wikis I know best, is true today too). Just to make sure I understand your feedback correctly, out of the two alternatives presented, you're arguing for the identity to be tied to the IP because you think a cookie-based solution will lead to even more issues for unregistered users in trying to be part of the conversation, is that correct? /Johan (WMF) (talk) 13:43, 12 November 2021 (UTC)
True, i believe encoding an IP in the way that changes almost nothing and only hides the actual ISP / geo location data from most viewers would be the best solution. IP editors don’t need any control over abusing the new system. Just always encode the same IP adress the same way, the other IP address the other way etc. — if the person behind it wanted to keep control they would create an account to personally control. — 188.123.231.59 20:31, 12 November 2021 (UTC)
Detecting the newly created accounts without rolling over their name would be nice. I always try to be polite to everyone but being able to instantly see who is new would be nice.... Hmm if the anonymous is going to have a number does that mean we can tell? Wakelamp (talk) 01:25, 21 November 2021 (UTC)

Masking algorithms

With apologies for repeating myself, it would be very helpful for all editors to know whether two contributions come from similar IP addresses, and to find other contributions from the same range. An algorithm such as Crypto-PAn achieves the first of these requirements and may help with the second. Certes (talk) 16:29, 15 November 2021 (UTC)

Agree. Can you tell if they come from the same VPN? --Wakelamp (talk) 04:32, 21 November 2021 (UTC)

We need fingerprints ID

I do not understand the suffering of most for very old protection against IPv4 addresses. With the introduction of IPv6, IP-based security has become obsolete. Most common users mixed with vandals use mobile operators. They have giant IPv6 country-wide segments. IPv6 prohibits an operator from tampering with the "user interface" portion of the address. Therefore, all attempts to block vandals using an IP address mask for a huge IPv6 segment are absolutely useless. Therefore, we still need to redo the vandal protection.

I think anonymous identification cookies are a good idea. Most of the vandals are schoolchildren and stupid people, so they won't think to clear the cookies. Therefore, all their contributions from dynamic addresses will be automatically combined, making it easier to remove it.

We must understand that in the near future, blocking by IP-addresses will stop working altogether, because users will be operating from giant IPv6 segments and you cannot block the IP range without shutting down millions of people.

Instead of outdated IP address protection, it is better to use user attributes. It's a good idea to display the GeoIP tag that Wikipedia is collecting now. You also need to start using professional fingerprint deanomization tools, many of which are elementary in implementation.

Some of the fingerprint algorithms are very easy to implement, and each such method has a probability of determining the uniqueness of the user above 99.9%:

  1. HTTP_ACCEPT
  2. Font Fingerprint
  3. WebGL Vendor & Renderer
  4. and so on

Typically, each fingerprint has a repeatability among users no more than 5,000-10,000 variations. This allows you to introduce even a global identifier on fingerprints as a combination of numbers from fingerprint variants. This does not disclose the user's personal data to other users, but it allows users to be identified with a probability of 99.999%

This will greatly simplify the work of check users. Of course, fingerprints can be blocked by addons, but not everything like HTTP_ACCEPT. A special private browser mode is required, similar to the TOR Browser mode from Firefox. However, only a small number of users will be able to enable this and it is easy to determine that they have done this. For such users check user should see special flag as "professional anonomization enabled". Easy to implement mode for blocking users with PRO anonimous mode for some articles.--2A00:1FA0:C433:8FC2:ACAE:2BAC:619E:8195 15:34, 21 November 2021 (UTC)

Good idea. Or an automatic ID founded on hardware fingerprint (or MAC address). We need something more consistent and persistent than a cookie based id. --Jean-Christophe BENOIST (talk) 15:57, 22 November 2021 (UTC)

Monitoring what happens in terms of editor behaviour

I wonder if this will change the behavior of anonymous users in some way that we can't foresee; maybe not having an IP address will makes them feel uncomfortable in some way

Are the team going to monitor before and after, to see there are statistically significant changes to - The number of new editors, and the split rate between unregistered and registered - The behavior of unregistered editors - distribution of the number of subsequent edits, distribution of the number of subsequent edits, number of edits reverted, vandalism etc Wakelamp (talk) 01:30, 21 November 2021 (UTC)

@Wakelamp Thanks for the question. We are already tracking some of metrics you mentioned about blocks, unblocks, reverts, page protection, page deletion etc for both registered and unregistered editors. We also track metrics about edits from IP editors - this happens by default thanks to our edit database. To measure community health overall, we are also keeping an eye on number of admins and admin to content ratio on our projects, as well as number of checkuser requests that are filed by the community. -- NKohli (WMF) (talk) 03:27, 23 November 2021 (UTC)

Abuse prevention

Increased abused mitigation is unlikely to work, as even a one second revert is enough time for a screen-dump Maybe we could reduce abuse if we targeted the vandal's motivation instead reduce the benefits. There has been lots of discussion in the past, but if they are just after a screen dump, then even a one second revert is too much

IF we moved some NPP functionality to Publish, we could

  • warn the vandal before publishing a high vandalism article that the edit will be reverted. Stop this NPP functionality if they repeatedly try it (identified using the new cookies
  • warn that vandalism may be reported to their VPN/ISP in their IP address country
  • Stop the value of the edit by placing a watermark/blank the page (only to the editor) saying article waiting for NPP review
  • Give them an option to send a copy of the preview to friends - Even provide a program to do this so they can draw big arrows (but change the wiki URL)

Yes, it would allow a user to work out how to get around some of the tools, but they can do that by trial and error.

Risks of an increased Abuse Mitigation Approach

The three plots above make a few things apparent:

  • The proportion of desirable newcomers entering Wikipedia has not changed since 2006
  • These desirable good newcomers are more likely than their ancestors to have their first contributions rejected
  • The decline in good newcomers is the result of a decline in desirable newcomers. Undesirable newcomers (not shown) retention rate stays constant.

Does Abuse mitigation work

  • The assumption we work under is that reversion in under 5 minutes reduces benefit and thus motivation for vandals. I think the benefit for nearly all is achieved as soon as they hit publish and take a screen shot.

It's the screenshots many of them want (based on searches on google/instagram/twitter for Wikipedia hack/edit lolz and funny); editors want to make lasting contributions, but many vandals may not care. OR they will send their revision of an article to their friends.

As an example of the mentality, this site [1] shows the needs of many of the vandals - it allows an update on your chosen article on ES:WP with a find and replace of your choice.

Rather than mitigation and an us versus them culture (even though in this essay portrayed humorously), maybe we should try to understand the Vandals motivations, so we can do nudges that decrease their motivation to vandalize, and increase their motivation to become WP editors. Wakelamp (talk) 04:29, 21 November 2021 (UTC)

@Wakelamp I tweaked your comment to fix some of the links. I hope you don't mind. This is very thoughtful and valuable feedback. We are already thinking about changes for the unregistered users and how we can nudge them towards creating accounts as part of this change. I like your ideas about nudging them towards better behavior. This is very timely. I will discuss this with my team. Thank you very much. -- NKohli (WMF) (talk) 04:47, 23 November 2021 (UTC)

Archived without response

Hi Johan,

Thought I'd re-note <https://meta.wikimedia.org/wiki/Talk:IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation/Archives/2021-10> - it didn't receive an answer, and the issue of whether those in non-"friendly" nations would fall under the same recent restrictions as the more normal NDA-roles is relevant. Nosebagbear (talk) 11:27, 30 November 2021 (UTC)

Nosebagbear: Huh, I somehow missed this before it was archived. Talking to the relevant teams and will update with an answer as soon as I have it. /Johan (WMF) (talk) 11:52, 30 November 2021 (UTC)
Nosebagbear: This will be included in an update from Legal. /Johan (WMF) (talk) 20:20, 1 December 2021 (UTC)

What about global rights holder

For groups active in SWMT work, the ability to see full IPs is very critical, you can see the SRG reports. For Global Rollback and Global sysop, members are added to the groups by at least 5 days and 14 days of discussions respectively. The comments are held at SRGP which IMHO is equal or more rigourous than a sysop RFA of a small wiki (these can be promoted for temp status without any vote - albeit with at most 3 months and mostly 1 month duration grant). So it will make sense to grant access to full IPs to GR/GS and as of SWMT team members, we can IMHO set up a lesser right to see IP for active users who are not yet ready for global rollback. Hope this can be addressed by the team, thanks. Camouflaged Mirage (talk) 11:54, 30 November 2021 (UTC)

We definitely want good global coverage. Thanks for the suggestion, will talk to the team. /Johan (WMF) (talk) 11:56, 30 November 2021 (UTC)
I've talked to Legal and to the rest of the team and this seems doable. /Johan (WMF) (talk) 02:09, 1 December 2021 (UTC)
Thank you @Johan (WMF) for the promising replies. Camouflaged Mirage (talk) 09:26, 1 December 2021 (UTC)
Camouflaged Mirage: We'll have to look into implementation, of course, but this has been added to our plans. As you say, global coverage is necessary and we don't want to mess things up for SWMT. /Johan (WMF) (talk) 10:54, 1 December 2021 (UTC)
I realised I sound unnecessarily vague above. Both Legal and we in the Product team say "yes, this makes sense". Most of our discussion has been around things like "what if the local wiki has set a higher threshold for access", but I figure that's very unlikely to be the case for the wikis SWMT look after anyway. /Johan (WMF) (talk) 20:22, 1 December 2021 (UTC)
@Johan (WMF) Yeah, this is a valid point. For Global Sysops, they act in wikis which had consented them to act so they aren't in all projects. For Global Rollback, it's truly global like although we care for those smaller wikis, our rights are across all projects. And all GS are GR by default, like they can just ask for GR. I know some projects are concerned about GR rights to be mis-used. So this is a concern that needs more global consensus like how supressredirect / autopatrol can be issues over some wikis. I will suggest we poll the projects to see what their threshold is (like the application process), if all of those seems to match the rigour of the SRGP discussions for GR, I think we are fine. Camouflaged Mirage (talk) 12:59, 4 December 2021 (UTC)

Cyphering IPs

It isn’t interesting to anyone that the start of IP is 217, it’s interesting only that 217.117.125.72 is close to 217.117.125.83 but 117.117.125.72 doesn’t. So why can’t we cypher IPs like 1fc4b57.125.83? 217.117.125.83 11:16, 11 November 2021 (UTC)

Do I understand you correctly that you are suggesting we only mask the first two octets of an IP address and expose the rest?
I can imagine scenarios where this could be misleading. Say if 217.117.125.72 and 117.117.125.83 are active on the page and they are cyphered as 1fc4b57.125.72 and 7c5f6e2.125.83 people might assume they are closer to each other but they are not really. NKohli (WMF) (talk) 01:24, 17 November 2021 (UTC)
But if IPs are 217.117.125.72 and 217.118.125.83 we have such problem now. 217.117.125.83 18:34, 17 November 2021 (UTC)
Unless you salt the IP with something that changes over time, it'd be easy to perform a known-plaintext attack of that system by seeing what random public IPs resolve to (eg. 217.117 → 1fc4b57). There are only 65k such /16s, so with a bit of determination you could figure out most of them fairly quickly. If you rotated the cipher somehow, you'd lose the ability to know that any IPs having the same first two octets are in the same /16 (or at least you could only make some kind of time-boxed statement of sameness), which prevents the main point of the system. And even then, you're vulnerable to the same attack within the rotation (so if I can find any IP that ciphers to 1fc4b57 quickly enough, I still find your IP). Inductiveload (talk) 19:49, 4 January 2022 (UTC)
Yes, anyway, the edits of IPs are voluntarily. So why is it not enough to inform them, that their edits will be associated with their IP-adress? IPs are anonymous. Greetings 84.186.35.187 17:37, 5 January 2022 (UTC) (That was me Redlinux (talk) 17:39, 5 January 2022 (UTC))

Use case for unmasking IPs

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.

What's the benefit of unmasking the actual ip of a user? Wouldn't the better thing be to create a tool wherein a user who has been granted the proposed right, would input two masked identities say User:Anon3406 and User:Anon5538 and an output would say whether these two have the same ip, so just a "match" or an "unmatch", instead of revealing the actual ip. - hako9 (talk) 17:09, 12 November 2021 (UTC)

String comparison of IP addresses only gets you so far. To be able to implement a rangeblock (at the smallest size) or check for open proxies, you need the whole address. AntiCompositeNumber (talk) 14:49, 13 November 2021 (UTC)
  • Regarding require a minimum number of edits and days spent editing - what are these values? And before you say communities can pick - please verify that 1 edit and 1 day suffices. — xaosflux Talk 15:04, 15 November 2021 (UTC)
Xaosflux: We had a suggestion ("least a year old and have at least 500 edits"), but received a lot of pushback on the time limit being too long, so shorter than that. Legal has required that there is some sort of limit, so it won't be one edit and one day. /Johan (WMF) (talk) 13:17, 16 November 2021 (UTC)
@Johan (WMF): so somewhere between (2 to 499 edits) and (2 to 364 days) -- who is the decision maker on this and when are they expected to make the decision? I'm assuming communities can always be more stringent. Unless this is bundled or made in to an autopromote group, users will need to specifically request this like other groups I'm assuming - that alone should drastically limit it, as most user won't bother to request. — xaosflux Talk 14:19, 16 November 2021 (UTC)
Xaosflux: I would count on the 500 edits remaining, that was not the part people had issues with in the discussions we've had so far and satisfies the requirements we have from Legal. And while the time period would be shorter, I would still assume we're talking about months, rather than days. Yes, communities can be more stringent if they want to, of course, we have no intention to interfere more in the communities' workflows than we have to.
In practice I, NKohli (WMF) and STei (WMF) will run a new number by Legal. Formally, this is NKohli (WMF)'s decision with approval from Legal.
NKohli (WMF): Do you have a suggestion for a timeline here? /Johan (WMF) (talk) 14:50, 16 November 2021 (UTC)
  • Thanks, just throwing out information from some extended confirmed settings in use on projects (edits/days) azwiki:500/30, bgwiki:500/120, enwiki:500/30, fawiki:500/30, jawiki:500/120, kowiki:500/30, rowiki:500/30, svwiki:500/30, viwiki:500/30, zhwiki:500/90. I'd suggest a lightweight framework of something like: "no autopromotion", "500 edits + 30 days". Create one new permission and one new group that holds the permission, make the group assignable and removable by sysops - who are expected to follow the minimum requirements rule (noting that there will likely be exceptions - for example for people that operate multiple "accounts"). The new permission could be bundled with existing groups: stewards, sysops, checkusers - and by request possible to other admin-like groups such as eliminators. — xaosflux Talk 15:22, 16 November 2021 (UTC)
Xaosflux: Our plan is that the groups you mention will be able to opt in with a single click, having already the community's confidence, so there should be no need to burden anyone with a process. /Johan (WMF) (talk) 15:26, 16 November 2021 (UTC)
Obviously those groups should have it inherently, but just to clarify we'll need the new permission so we can assign it to additional users outside the admin corps. Nosebagbear (talk) 19:02, 16 November 2021 (UTC)

The very idea to conceal the IP addresses appears to cause very bad results. In our section there is a vandal who does his bad deeds at least since the end of July. He constantly creates pages with insults of a Russian actor. Fortunately, one of the pages with insults was created anonymously, which allowed careful users to determine the rang of IP addresses used by the vandal. If the new rules are introduced, then only high-ranked users will be still able to find out the IP addresses and ask the admins to lock them. The problems will become a worse version of the ones which we face when dealing with open proxies. I hope that this idea to show randomly generated pseudonyms instead of IP addresses will not be implemented. 178.70.250.106 19:58, 16 ноября 2021 (UTC)

178.70.250.106: It will happen. We're doing it because of changing norms and regulations around privacy online – so the Legal department's analysis is that this is necessary – not because we unilaterally decided it was a good idea. /Johan (WMF) (talk) 20:40, 16 November 2021 (UTC)
Just so long as the tools under construction mean that no part of the CVU/IP-sock workflow ends up having either a higher time taken, lower positive-clearance, or higher false positive rate then the status quo. That would be unacceptable. Though I've not seen anything on how to duplicate things like the Congress or Parliament watches (often on Twitter and so on) that check for problematic edits from those politically-hot button areas. Nosebagbear (talk) 20:58, 16 November 2021 (UTC)
We have some of those, yes. I'm not sure I see a solution for them, to be honest. I'll add it to the list of questions for the Legal department, if there is room to do anything there. /Johan (WMF) (talk) 02:35, 17 November 2021 (UTC)
@Johan (WMF): - that does not seem to be indicated in the impact text In order to provide proper tool support for our administrators’ work, we must be careful to preserve or provide alternatives to the following functions currently fulfilled by IP information - it notes that there may be a transition (which going from past changeovers on Wikipedia, an acceptable problematic transition period is usually viewed as 1 month) drop in effectiveness, but that improved tools will resolve the workflow issues that might be caused (or at least compensate for them by saving effort elsewhere, although this is itself dubious as editor and editor time is not the most fungible of resources) Nosebagbear (talk) 16:11, 19 November 2021 (UTC)
I don't think 500 edits is enough. We still see vandalism in extendedconfirmed-locked articles, much rarer but it happens. Also I'd like to not perform a dozen revision deletes every day on my projects AIAB page, just because of all the extendedconfirmed users who would not understand or care about how to deal with this. I think the requirement should essentially be the same as it is to receive rollbacker rights. Could even be same user-group. EstrellaSuecia (talk) 02:11, 20 November 2021 (UTC)
EstrellaSuecia: Just to be clear, someone will make an actual decision to give the user the right, it won't happen automatically. You still think it's not enough? /Johan (WMF) (talk) 14:26, 22 November 2021 (UTC)
Nosebagbear: Our intention with that text was to point out the specific things we were looking at, e.g. showing "this is from a university library" in IP Info so that would be obvious for anyone looking it up, but yes, I can see how broadcasting that an edit has been done for institution X could be construed as being covered by that text even if it wasn't our intention. I've started a conversation with Legal about this. /Johan (WMF) (talk) 14:26, 22 November 2021 (UTC)
Hi Johan, I realise 3 weeks is a fairly short period of time by the normal Legal time, but was wondering if they'd responded to this prior to the Christmas break? Nosebagbear (talk) 13:01, 15 December 2021 (UTC)
I think for wikis which have 30/500 protection, partially masked should be given for extended-confirmed users, and another wikis will be given a right called partially see IP address group, which is autogranted for users which made 30/500 edits; or make a RfC about universally extended confirmed protection. For small wikis, the requirements can be lowered to prevent crosswiki vandalism, needing 6 months and 5000 global edits to globally see partially masked IPs. Thingofme (talk) 15:47, 5 January 2022 (UTC)

Global contributions and other external tools

This is a follow up to Special:Permalink/22188440#Global contributions and other external tools. Is there an update on what we plan to do with the ip_changes table and the Toolforge replicas? I assume we will stop replicating this data, because otherwise IPs will be public. But by doing that, we break tools like XTools Global Contributions and GUC which stewards rely on to check for collateral damage across all wikis before blocking an IP or range. We cannot feasibly check every wiki individually. We could write an on-wiki gadget that uses the API, but this would be orders of magnitude slower than what we're used to now. I suggest the team build a global contributions tool into Extension:GlobalBlocking or something similar. XTools uses the ip_changes table and it is generally very fast, despite having to query up to 900+ wikis, so I imagine getting something like this into production would be acceptable performance-wise. Kind regards, — MusikAnimal talk 15:38, 15 November 2021 (UTC)

Hi @MusikAnimal! We do not yet have a firm answer for what we will do to replace these critical tools but we are thinking about it. We investigated with pulling in global contributions information into the IP Info Feature and it looks like we will be able to do that. It's possible we will expand that tool to include more information in the future. Thank you for calling this out. -- NKohli (WMF) (talk) 04:21, 17 November 2021 (UTC)
@NKohli (WMF) Thanks, great to hear! I see now the "See global contributions" link in File:IP Info (10 June update).png. As long as that works for ranges, too, we should be in good shape. The data is all there, so it wouldn't seem terribly hard to build a Special:GlobalContributions page that gives a chronological list of edits across all wikis, along with tags, etc. (mw-reverted in particular is helpful). I suppose this special page would only be visible to stewards or whatever other global groups we decide have the right to view IPs.
Possibly unnecessary technical rambling: As I understand it, the production db clusters are now identical to Toolforge's, so the querying strategy could be very similar to what's done in XTools – where by we query 900+ wikis with just nine individual queries (because there are only 9 database sections: s1, s2, etc). The important thing I guess wanted to make is that this new tool should be built before we break the Toolforge replication of the ip_changes table so we don't break any workflows. If it means anything, this table stores IPs as a hash. They are not discernible to the public without first doing base conversions, so it's already sort of "masked" but probably not in a legal sense :) Thanks and hope all is well, — MusikAnimal talk 04:56, 17 November 2021 (UTC)
Better to let tools access a hashed table. This is mostly a self-imposed obligation, w/ flexibility in how to implement it. –SJ talk  17:13, 7 January 2022 (UTC)

Why?

If you know IP you know only provider so there’s no problem with knowledge of IP. 217.117.125.83 16:05, 9 November 2021 (UTC)

We know a fair bit more than the Internet Service Provider, actually. But most importantly, for legal reasons: IP Editing: Privacy Enhancement and Abuse Mitigation#Motivation. /Johan (WMF) (talk) 16:24, 9 November 2021 (UTC)
In some cases an IP number can be directly linked to a person. For this reason the Dutch Privacy Authority considers an IP addresses personal data that require special care under EU law. --MarcoSwart (talk) 18:40, 9 November 2021 (UTC)
It means that only Dutch IP numbers must be masked. Carn (talk) 11:51, 17 November 2021 (UTC)
Catering to the demands of weak and cowardly politicians ⟨…⟩ is not the Wikimedia way. 217.117.125.83 14:38, 10 November 2021 (UTC)
We adhere to a lot of requirements, even in cases where we as a movement disagree with them (e.g. copyright laws in countries lacking the freedom of panorama) with more consensus than we have around showing IPs. This is quite different from censorship of articles, which is the context of the quote above. Nor do I think we'd generally describe the evolving online privacy regulations and norms as weak and cowardly, whether we agree with them or not, or agree with the specific implementations. /Johan (WMF) (talk) 16:21, 10 November 2021 (UTC)
Privacy is a human right. Respecting human rights is the Wikimedia way. --MarcoSwart (talk) 15:39, 12 November 2021 (UTC)
Why do you think that it’s privacy? 217.117.125.83 18:33, 17 November 2021 (UTC)
Let's suppose we have an editor from China, who says something rude about the President Xi or questions Party Policy. The Chinese secret services have great skill in tracking IP movement and then matching that to an individual. There even has to be a concern about Checkuser, because they have the patience to play the long game but we have to balance that against effective management of the project. Our US friends say, well that's China, would never happen here! but you came very close to a successful coup d'etat a year ago and a similar action (burning of the Reichstag) brought dictatorship to Germany less than a century ago. There is autocratic rule to a greater or lesser extent in Turkey, Egypt, Myanmar, North Korea and India (Kashmir). This is not about places like the Netherlands, where there is respect for the rule of law: it is about the places where the law is shaped to serve the governing power. --John Maynard Friedman (talk) 20:35, 4 January 2022 (UTC)
So China (& some others) found tool, how to destroy WMF at all by wikipedians' the very self hands. Because of crawling vandalisms by robots, which could not be eliminated by administrators, as in massive attack cannot help non-admins, who will not be able to identify vandal-bots and so able help admins (not enough time). So here rises dilema: is some person security (cf. does this tool guarantee his security, apart makink it a little bit safer?) more, than WMF existence at all? What about crossproject vandalism? What about smaller projects with weak or absent admin staff? --Kusurija (talk) 06:17, 5 January 2022 (UTC)
  • If a editor edits from China, the Chinese government will know who it is regardless if we implement IP masking or not. They monitor ALL traffic within the country and from timing data of the metadata alone they could figure out who made the edit. Further, it is naive to assume that none of our admins, who can still see the IP addresses, are covert agents for China. Bottom line: unless a user has been really really careful, any edit can be traced back to them. So, IP masking, as per your example, may actually lead people into a false sense of security. Jason Quinn (talk) 07:21, 16 January 2022 (UTC)

IP-based versus session-based masking: Why not both?

Consider this sequence of events:

  1. Alice makes an edit from 1.2.3.4, but does not clear cookies afterwards
  2. Alice makes an edit form 1.2.3.5, but remembers to clear cookies afterwards
  3. Alice makes an edit from 1.2.3.5

Now either IP-based or session-based masking "break the chain" at some point. But what if these edits are publicly logged as:

  1. Masked User 473982743:47982
  2. Masked User 027469812:47982
  3. Masked User 027469812:51023

Now everyone can see that there is might be one user behind all these edits, but we haven't given up her IP. Suffusion of Yellow (talk) 20:10, 15 November 2021 (UTC)

  • Third "Alice makes an edit from 1.2.3.5" is indistinguished from "Bob makes an edit from 1.2.3.5" so an assumption that all 3 edits are from one user is incorrect. The correct assumption is that Alice and Bob have the same IP, and then if we somehow know Alice's IP we know Bob's IP as well. This is a minor threat but still a threat. (In my opinion this is not so far from giving plain IP. Changes are redundand in such case). --Igel B TyMaHe (talk) 08:13, 16 November 2021 (UTC)
    Good point. This threat also applies to a pure IP-based masking scheme, too. Combining both schemes doesn't make it any worse, unless I'm not thinking of something. Suffusion of Yellow (talk) 23:23, 16 November 2021 (UTC)
    This starts to get into a meta-discussion (not the project) IMO about what actually constitutes a unique user. Certainly Alice and Bob are two distinct people. But if they are using the same IP and the same browser on the same device without any additional identifiers (like credentials or a token), are they actually a distinct user? Anyhow, the hybrid approach proposed above does seem like it would eliminate some of the concerns around the limitations of either implementation. SBassett (WMF) (talk) 22:12, 18 November 2021 (UTC)
    Might I suggest that the "MY LITTLE BROTHER DID IT" essay may hold some relevance to SBassett's question about a unique user. If abuse is coming from an IP, we block it. When blocking an IP, we aren't exactly blocking a person, but rather a connection to the internet. This wouldn't be any different, and Bob still gets blocked for what Alice did. The difference is that, Charlie, who just got Alice's IP, doesn't get blocked, as we could see that Alice definitely changed IP address so it would be pointless to block the one she has moved off. Mako001 (talk) 12:34, 13 January 2022 (UTC)
  • I like this hybrid approach. ProcrastinatingReader (talk) 19:56, 10 December 2021 (UTC)
  • I like the hybrid approach. Details that need to be worked out are the retention policy for the data. We need to consider scenarios where an authoritarian government (1) grabs a user's computer and checks their cookies, and (2) breaks into a WMF server and steals our logfiles. What policy strikes a reasonable balance between allowing WMF to defend its websites, and prevents our data from falling into the wrong hands and causing real life harm to a user or even a mere visitor to the website? This problem is deep and will require ongoing thought and research, regardless of which path is chosen. Jehochman (talk) 18:22, 4 January 2022 (UTC)
I guess that if an authoritarian government actually grabbed someone's computer, the cookies would be fairly irrelevant, browsing history would likely be enough, and we can't do anything about that. The idea of the whole IP masking thing is to avoid the situation where they actually do grab it. Mako001 (talk) 12:34, 13 January 2022 (UTC)
  • Indeed I see advantages in the hybrid approach too. --.mau. ✉ 18:25, 4 January 2022 (UTC)
  • Yes, using both is certainly an improvement to either. I also don't see why IPs from the same range editing the same page can't be tagged as possible socks (or some less accusatory wording). They are both still remain masked. This is not just a vandal fighting issue, ordinary collaborative discussions are affected. Conversations on talk pages will start to become really difficult when unregistered users get involved. At the moment, it is faily obvious when the same person makes another reply, even from a dynamic IP. With masked IPs this could get very confusing unless there is some kind of marker. SpinningSpark 18:56, 4 January 2022 (UTC)
  • I am also interested in seeing what a hybrid approach would look like. Will there be a trial period with specifics before we decide definitively which approach (or both?) will be used? Spencer (talk) 03:34, 5 January 2022 (UTC)
  • I also agree with a hybrid approach, but where the IP is not necessarily transparent. So, besides getting a session handler (e.g. anon-1fe49afc7bc5), for whom we can see the User contributions, we can also have an list of IP anonymised identifiers for that user (which might be shared by different anonymous users), and direct access to any contributions done each (still hidden) IP, and we are still able to (temporarily) block anonymous contributions from a given IP (even without seen it!), or pass it forward to a checker for more information if necessary. MarianoC 10:48, 7 January 2022 (UTC)
  • I like this approach, too. It could even be improved further by including a hash for the IP range (first three numbers) only: then one would see that all edits are from the same range without knowing the range... --Qcomp (talk) 13:47, 7 January 2022 (UTC)
  • Support, came here to suggest this, along with an explicit nod to basic hashed fingerprinting. That also elevates the feel of the whole project from "switch from one suboptimal solution to a second suboptimal solution, with added transition costs and confusion" to "extend current system to add more useful nuance + make everyone's lives easier" ;) –SJ talk  17:16, 7 January 2022 (UTC)
  • I also like this approach, but there are a lot of users if the IPs or cookies changes, and it's hard to discuss with masked usernames in this way. However, it can be inferred that it would be easier to combat vandalism, if we use both cookies (one cookies) or IPs IP editing. The cookies show that an temporary account for IPs are disappeared frequently, once cookies changes, the edit would be lost. Thingofme (talk) 11:58, 8 January 2022 (UTC)
  • Yeah, this should be the #1 option. Makes it much harder to evade scrutiny, ab-users will inevitably forget to always change both the IP and the Cookie. Assign the cookie to all users, registered ones too. Would give CU's another way of tracking down sockpuppeteers.Mako001 (talk) 12:21, 13 January 2022 (UTC)
  • I agree, combining both IP-based and session-based identifiers seems to be more useful than using either of these alone. Sintakso (talk) 17:33, 19 January 2022 (UTC)

Contributions

How will I able to find my contributions? Will be there way to say to the site that I want to save my edit under IP? 217.117.125.83 17:25, 10 November 2021 (UTC)

Much like today! They will be tied to your identity; how said identity is to be defined is up for discussion (see above and the update on the main page). It won't last forever, of course, but then again – no unregistered identity does. Including IPs. /Johan (WMF) (talk) 01:12, 11 November 2021 (UTC)

It’s the way to finally force anyone who needs that to register. — 188.123.231.59 23:50, 10 November 2021 (UTC)

That's not our intention here, at least; then we wouldn't spend so much time and effort trying to make masking work. /Johan (WMF) (talk) 01:12, 11 November 2021 (UTC)
"It’s the way to finally force anyone who needs that to register."
"That's not our intention here..."
Why? Why are we all going through all this... effort, when simply going to mandatory account creation, across the board, would solve most, if not all, of these concerns with IP-editing, IP-privacy, IP-vandalism, IP-socking, etc., etc.? And, even if there are any 'cons' to mandatory registration, do they outweigh the 'pros'...? (jooc) - wolf 09:11, 25 January 2022 (UTC)

Previous discussions

IPv6 and privacy
"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."

Actually, for purposes of privacy, IPv6 can be considered to be essentially static. Each user is assigned many IPv6 addresses, but each address belongs only to a single Internet connection (router), as opposed to a many-to-many relationship between dynamic IPv4 addresses and users. Hence, the IPv6 range assigned to a single household (it seems it's usually /64) is as personally identifiable as a static IPv4 address. Daß Wölf 19:48, 20 November 2021 (UTC)

  • No, IPv6 is protected against such a simple detection of a user as "privacy extension". Usually an IPv6 address is issued for 1 day, then the client receives a new one. Old IPv6 addresses respond 1 week. Also, new IPv6 is usually issued upon reconnection.

You also need to understand that IPv6 segments have a capacity of trillions of numbers. Therefore, mobile operators often create one IPv6 segment for the entire country. Therefore, if a vandal works from such a segment, you can neither block him by IP, nor even understand what city he is in.

An additional point is that it is rather difficult to apply masks to IPv6 addresses. The "user interfaces" portion of the address is actually under the control of the client. This leads to the fact that within one IPv6 segment, all users are fundamentally indistinguishable.

Vandals will not need open proxies in the near future, because their smartphone is enough for them to "crack" the protection of Wikipedia.

In the near future, IPv6 will replace IPv4. In the US, over 40% of connections are already IPv6.

Everyone who is crying here about blocking vandals' IP addresses needs to understand that in the next few years, IPv6 addresses will make it almost useless to study them, as blocking masks, and it will be impossible to block IPv6 segments. Blocking the IPv6 segment of a mobile operator means cutting off millions or even tens of millions of people.

Instead of suffering about getting into someone else's personal data, it is better to think about modern means of identifying anonymous users, which using modern technologies. This tech are NOT based on IP addresses, but are based on fingerprints based on the characteristics of browsers and hardware. This is similar to User Agent, but much more selective (identification accuracy is higher than 99.999%). Also, you will not be able to understand that User Agent is being faked for you. Modern fake addons like "Random User Angent" choose very realistic options from templates. However, browsers' fingerprints are blocked now very roughly and it is easy to understand what the user is doing. Such users can be blocked as users of open proxies are now blocked.--2A00:1FA0:C433:8FC2:ACAE:2BAC:619E:8195 16:30, 21 November 2021 (UTC)

If this really is as technically feasible as claimed, it is a great idea. SpinningSpark 18:57, 4 January 2022 (UTC)
Practically all websites that use fingerprinting abuse the unique identifiers that it exposes. Users should not be blocked for rightfully protecting themselves against fingerprinting. If the rest of the web did not abuse this technology I would agree though. PJvanMill (talk) 15:36, 26 February 2022 (UTC)
Can unregister user use username without password?
I think unregistered users must give a choice to make usernames without passwords. I mean when an unregistered user click on edit, he/she will see a popup showing some alphanumeric usernames or a text field that allow them to create a username without a password? Such usernames may have their separate namespace.--Ameen Akbar (talk) 20:50, 4 January 2022 (UTC)
I agree, it would be nice to let users that aren't logged in to identify themselves somehow.
93.107.67.214 20:54, 2 May 2022 (UTC)
I disagree on this however this may result in impersonate unless we define that anonymous username cannot uses for identify individual, in additional I think doing this have no significant good reason for Wikimedia communities. --NP-chaonay (talk) 13:10, 4 May 2022 (UTC)
For me if public-hidden IP is implemented, I think it best to use something that can uniquely linked to IP address without reveal of the IP address, instead of using username (or assume that you agree on username for unregistered, let Wikimedia shown both username and unique ID), in this way anyone who cannot access IP-user's IP address can able to distinguish and report ip-user behaviour. NP-chaonay (talk) 13:17, 4 May 2022 (UTC)
Aporte de argumentos sobre la relevancia en Wikipedia de: Centro de Investigación y Desarrollo Agrícola de Ohio
{| class="hidden-archive mw-collapsible mw-collapsed" style="width: 100%; clear: both; font-size: 88%; padding: 1px; margin-top: 0.2em;"

|- ! style="padding: 0.25em 1em; line-height: 1.5em; background-color:#f2dfce;" | Off-topic/Unrelated to the IP masking subject. |- | style="text-align:center; font-style:italic;" | The following discussion has been closed. Please do not modify it. |- | style="border: solid 1px silver; padding: 8px; background-color: white;" |

El Centro de Investigación y Desarrollo Agrícola de Ohio es un artículo relevante en la Wikipedia en español por los siguientes argumentos:
1º Es un centro de investigación y desarrollo de proyectos relacionados con la agricultura, que es dependiente de la Facultad de Ciencias Alimentarias, Agrícolas y Ambientales de la Universidad Estatal de Ohio, prácticamente desde sus inicios en 1882.[2]
2º En el año 1979 por parte de los científicos de esta institución se realizó un descubrimiento de la mayor importancia, un teosinte en México ("Zea diploperennis")[3][4], que podía cruzarse con maíz para hacer este más resistente a las enfermedades.[5]
3º Entre otros muchos trabajos realizados en este centro, es un lugar de investigación en la consecución y desarrollo de nuevos cultivares de manzana, entre ellos es de destacar la variedad Melrose, desarrollada en la década de 1920, cuya selección final se hizo en 1937 y la manzana se introdujo en los circuitos comerciales en 1944. Posteriormente se la nombró como la manzana oficial representante del Estado de Ohio.[6][7]
4º A que en la wikipedia en inglés"Ohio Agricultural Research and Development Center" está aceptado este artículo con suficiente amplitud de criterio, además de no estar cuestionada en absoluto su relevancia.
Javier martinlo (discusión) 18:41 7 ene 2022 (UTC) |}

Questions from 魔琴
Hi. I have 2 questions:
  1. I am from mainland China, so I wonder, since users from mainland China can't sign Confidentiality Agreement for Nonpublic Information, can they have access to unencrypted IP addresses?
  2. I participate in SWMT, but I don't have global rollback/sysop right (lacking experience...) How will it affect my work?

--魔琴 (talk) 05:21, 8 January 2022 (UTC)

That's the problem. The Confidentiality agreement for nonpublic information sign that user mustn't live in countries that censor Wikipedia like mainland China, so zhwiki is the largest wiki in which there are no local checkusers, even with 65 admins. For IP address, I think that user are not trusted to see the IP address, so personally, I think only checkusers can check unregistered users for their IPs. They would be called as a random name, and would not affect global tasks. However, rangeblock would become impossible and only for checkusers. Thingofme (talk) 14:27, 8 January 2022 (UTC)
"[S]o zhwiki is the largest wiki in which there are no local checkusers." No, the zhwiki doesn't have local CU because the Foundation removed CheckUser access from all local users due to "security concerns" in Mar 2018, accordingly after some still-unknown CheckUser posted IP-user relationships on the village pump. --魔琴 (talk) 04:48, 9 January 2022 (UTC)
魔琴, Thingofme, we will get back to you on special cases like that of China. But for others, we have some notes here and there with more information on editors who will be able to see IP addresses and what they are required to do for access. ––STei (WMF) (talk) 16:39, 19 January 2022 (UTC)
@STei (WMF) hello - I was wondering if there had been further thought on the general question of "are regions subject to CANI restrictions, also subject to unmask-UP restrictions"? A not tiny percentage of the editorial base are associated with a project that has admins but is CANI-limited.
On a personal basis, the Chinese government (as the big example) is more than capable of knowing every China-based editors' IP address when editing, regardless of our own masking. There are, of course, countries where such a safeguard may be of use, even on a limited state-actor level. Nosebagbear (talk) 15:14, 15 March 2022 (UTC)
魔琴, I will be reaching out soon to see if we can speak one-on-one about your unique challenges, including the message you left on my talk page. –– STei (WMF) (talk) 07:14, 22 March 2022 (UTC)
Access for community tools
Hi, I see the two approaches about the IP-masking (IP vs. session). I personally would like to choose the session-based approach as it offers new opportunities on analyzing user activities (and keep the option open for blocking or deleting cookies). However, I see that many editors will be against it. What we should ensure that statistical and similar tools developed by community members (for example on toolforge.org) will not be broken after this move. Will we provide automatic access for these tools to the IP addresses (or session data) or did you think on this issue? Samat (talk) 22:31, 15 January 2022 (UTC)
Hello @Samat, I will get back to you on the status of community tools and those we are currently working on/refreshing for the era of masked IPs. –– STei (WMF) (talk) 09:00, 18 January 2022 (UTC)
Hi @STei (WMF): - now that the WMF has opted for session data, can you confirm how these tools will be affected? Nosebagbear (talk) 15:05, 15 March 2022 (UTC)
What if somebody spy on my computer to get IP addresses while I don't know?
About "Following implementation of IP Masking, who will be able to see IP addresses?": What if somebody spy on my computer to get IP addresses while I don't know my computer 's being spied? For example, if my brother look at my computer while I am viewing an IP's talk page, and thus get the IP? I'm afraid actually....--Emojiwiki (talk) 05:39, 20 January 2022 (UTC)
I do not think the Internet can solve your social or family problems.
It is not clear what you wanted to ask but I suspect your family share the same IP so the point is moot: you all have the same IP and therefore you have the same talk page if it is shared by IP only, and you have a different talk page if it's based in cookies. Either way you should rather talk to one another instead expcting Wikipedia to resolve your internal problems. In my own opinion. grin ✎ 14:53, 20 January 2022 (UTC)
I think he meant that he may accidentally give away the unencrypted IP addresses. --魔琴 (talk) 15:08, 21 January 2022 (UTC)
yes, gave away unencrypted IPs that are not mine. Emojiwiki (talk) 11:12, 14 February 2022 (UTC)
Per Grin, it is your social or family problems. Unfortunately there is no way on Internet and Mediawiki that can resolve your problem. Only you can resolve problems by yourself. Thank you. SCP-2000 12:12, 14 February 2022 (UTC)
WMF: Thank you, time to review your feedback
Thank you all for talking to us about how to proceed with IP Masking.

The Wikimedia Foundation will be reviewing your feedback as it decides on the best approach and features to employ. We hope to announce the outcome of the decision making soon.

In the meantime, we are revising the project page to make it easier to read and also provide answers to your most recent questions.

––– STei (WMF) (talk) 06:25, 14 February 2022 (UTC)

WMF: A personal thank you
Tagging along here, with Sandister adding thanks above, I just wanted to say thank you to everyone who has put their energy into this project and returned to comment, discuss, and prompt us along to how to best handle the situation. Due to time constraints, I'm no longer actively involved in this project, as STei (WMF) has taken over my role, and it felt strange to just fade away with no explanation to those who have talked so much with me specifically. This is a difficult project, but I have – as always – really appreciated the time some of you have put into it. /Johan (WMF) (talk) 10:21, 14 February 2022 (UTC)
@Johan (WMF): had missed this and wanted to thank you - both NKohli, and then you, have done a strong job being communicative despite a) being tasked with a mandatory change that multiple communities don't want, thus inserting you into a firestorm and b) being the front-facing person between the communities and other, less communicative, teams. Nosebagbear (talk) 10:07, 23 February 2022 (UTC)
WMF: New update on IP Masking implementation - 25 Feb 2022
Hi all -- we have a new update for you on the project page: Implementation Strategy and next steps (25 February 2022). We appreciate all the time and effort you all put into providing your thoughts in these discussions the last few weeks. We tried to take every comment into consideration and come up with a solution that brings out the best-possible outcome. I want to apologize at the outset if this does not agree with your personal opinion. It was a hard decision to make either way. Your opinion is still valid and welcome. It helps us in planning for the tools we may need to build or plan for use cases we may not have thought about. Thank you very much. -- NKohli (WMF) (talk) 01:16, 26 February 2022 (UTC)
Hi @NKohli (WMF) and STei (WMF):, this got discussed right back at the start, but I've not seen any formal answers on it. As the definition of success is "does all of the current workflows at least as well, and hopefully some other aspects better", how are you measuring this?
False positives, false negatives, and time-taken/account are all key facets - and needs to be tracked individually for LTA-pursuit, CU work, regular SPI caseload etc etc.
I'm just don't want us to get to the end of the process and have disagreements as to whether there's been a net gain. This is especially the case as workflow time isn't really fungible - saving time for one group but costing it for another doesn't even out, because not all editors (definitely including me!) can do all things that required knowledge of IPs. Nosebagbear (talk) 12:48, 26 February 2022 (UTC)
Hi @Nosebagbear. That's a good question about measuring impact. We brainstormed on it internally when we kick-started this project. Like you said, there are many facets to measure and it is difficult to measure them all effectively.
On the quantitative end, we made a list of metrics ("guardrail metrics") which we will be tracking continuously to see if any of those numbers change dramatically as we rollout the key features on this project and begin the process of masking IPs (still a while away). These numbers include: number of active admins, admin to content ratio, new admins per month, number of blocks, unblocks, range blocks, reverts, page protections, page deletions, checkuser requests etc. You can find the full list in the tasks listed under this phab task.
For each of the individual features we are working on, we will be building out a feedback mechanism. This is true for both IP Info and Similar Editors (automated sockpuppet detection service). We'll be carefully evaluating feedback and using it to fine tune the features to get better results.
Lastly, we are thinking about doing qualitative analysis by running surveys on individual projects as we roll out the features to both a) spread awareness about this work and b) get feedback.
If you think of other things we can be doing, let us know. These are some of the ideas we came up with but I'm sure there's more we can be doing to measure the impact of this work. -- NKohli (WMF) (talk) 20:46, 1 March 2022 (UTC)
Hi @NKohli (WMF):, had seen this when you replied, and with some more thought it seems fine in most regards - there are three significant ones, two of which would need to be included in the feedback/survey bits and one that I'm not sure how to track off the top of my head:
  1. Time of task - this has lots of aspects, but is fairly clear - time to handle each part of a workflow that would use the info (noticing, finding appropriate IPs, blocking etc etc)
  2. (Perceived) complexity of workflow - even if it's roughly time equivalent, if people are thinking it's significantly more arduous that will have an affect (for example, I view CVU as a lightweight task to do when I am tired)
  3. The trickier one is one of the most crucial - identifying numbers of new editors moving into the different workflows - which the userright is not a clearcut marker for in total, let alone individual strands. One of my concerns is that editors who already do it, will accept a certain amount of awkwardness to keep doing what they know, but newer editors won't take it up at the same rate. That would impose an appreciable medium-term (12 months+) risk. Nosebagbear (talk) 09:55, 15 March 2022 (UTC)
Tools update
Hello,

I was just hoping I could get a bit of clarity on the most recent update (that is, the tools update made on the 3rd March). It reads as if in the present tense (that is, the team has been redeployed to securepoll/votewiki for the affiliate/community elections later this year), but then the detail and the linked-to pages read as if in relevance to last year's redeployment to securepoll for the STV creation et al.

In effect, I'm a bit confused by the timings, current focus, and such Nosebagbear (talk) 14:07, 3 March 2022 (UTC)

Sorry @Nosebagbear we didn't post anything new about that. @STei (WMF) has been moving things around, trying to make the page more succinct and readable. It was probably an accidental change there. @STei (WMF) could you review the changes once please? I think the dates of the updates might have gotten lost. Thank you. -- NKohli (WMF) (talk) 21:37, 3 March 2022 (UTC)
@Nosebagbear, @NKohli (WMF)is right. No updates on tools, just an update on the implementation. STei (WMF) (talk) 17:47, 4 March 2022 (UTC)
Ah, that makes more sense, tah muchly Nosebagbear (talk) 18:18, 4 March 2022 (UTC)
The right to privacy is what they have given up, there is no need to spend energy on it.
It's easy to create accounts, and it's easy to create a whole bunch of them if you focus on vandalism. (Because my community has a lot of blocked disposable accounts)

If you have an account, as long as you don't disclose information, no one knows where you come from, which means you have enough privacy. And if you're not a vandals, UserChecker won't actively check your account and know the IP you're logged in with(though they won't publish your IP either). For good guy, an account is the best privacy protection and a regular channel of communication..

If you edit with an IP, a whole bunch of people can know where you're from, or where you want to be seen as where you're from (for vandals). When you edit with IP, you're already preaching: you don't mind your privacy at all (on the bright side).

In this case, why do we spend a lot of money on superfluous? (Although the foundation has a lot of money to fill the pool and swim in it.) THEY DO NOT CARE THAT. I fear this will become the next "Superprotect" and "Media Viewer". --Cwek (talk) 01:23, 15 March 2022 (UTC)

@Cwek FYI: It is because of the legal risk. SCP-2000 02:39, 15 March 2022 (UTC)
Those who give up their rights do so at their own risk, not make the foundation a babysitter. --Cwek (talk) 02:55, 15 March 2022 (UTC)
"do so at their own risk". This puts an enormous amount of responsibility in the hands of people who might not be as computer versed as you are, or maybe simply have made a one-off mistake. To me, it is like saying that Ponzi schemes should not be forbidden, because people entered into them of their own volition. Survival of the fittest combined with survival bias... I find that an incredibly naive view of technology. We are a very big website, with lots of our editors residing in dangerous places (and those places being increasingly hostile specifically towards us) and personally think that ethically we can not keep using IP addresses the way we have been. We DO have responsibility, we cannot just say "you should have used an account/VPN in the 5 years before your country's regime went fascist". —TheDJ (talk • contribs) 13:48, 15 March 2022 (UTC)
When they edit with IP, they should already know what risks they face. So if they can take their responsibility to protect their privacy rights, they should know what to do, which is what we should encourage - create an account. In short, an account is already the best way to protect user privacy. --Cwek (talk) 03:12, 15 March 2022 (UTC)
Unfortunately based on the information given by WMF legal team, it is legal need instead of ethical responsibility. SCP-2000 12:39, 15 March 2022 (UTC)
It's ridiculous to say it's a waste of money when no one has any idea if they adds any costs. That's such an off discussion issue that WMF already considered. If this is for legal issues, then so be it. That alone saves the foundation from potential lawsuits. The Grid (talk) 16:54, 15 March 2022 (UTC)
WMF: IP Masking implementation strategy and next steps
The Wikimedia Foundation has decided to go with the session-based approach. It has taken note of the numerous feedback on the issue of users deleting their cookies and changing their identities. As we work out the technical details, if you have any more comments on the session-based approach and any additions we can make, please leave them below. Thank you.

–– STei (WMF) (talk) 14:55, 15 March 2022 (UTC)

  • Please think again. A session-based approach has advantages when a good-faith anonymous editor uses one device on multiple IPs, but these are outweighed by the scope for abuse when a new unblocked identity can be created at will. The code you propose to write will never be executed, because this plan will force projects to ban unregistered editing completely. The thrill of seeing my first IP edit (a trivial typo fix) go live for the world to see led to 14 years of contributions. Please don't prevent new editors from making that journey. Certes (talk) 14:42, 16 March 2022 (UTC)
    Thanks for your comment. –– STei (WMF) (talk) 15:38, 17 March 2022 (UTC)
  • @STei (WMF) does the team have a method on ensuring how they're going to stop the increased vandalism/socking that this will enable (resetting cookies/sessionID being (even) easier than resetting IPs), or is it just being accepted as a negative in return for the positive? Nosebagbear (talk) 15:47, 16 March 2022 (UTC)
    We mentioned in the update that the technical details of how we will address this issue of cookie deletion and identity change will be shared when finalised. –– STei (WMF) (talk) 15:45, 17 March 2022 (UTC)
Stable section titles would be appreciated
Stable section titles would be appreciated for persistent links, e.g. from The Signpost. Someone added "NEW" to one of the section titles and I suppose it will be removed in the future. Bri (talk) 15:36, 16 March 2022 (UTC)
The page has seen a lot of updates and we try to make recent information easy to catch for readers. However, this concern is also true. 'NEW' will be removed. –– STei (WMF) (talk) 15:49, 17 March 2022 (UTC)
@STei (WMF): You don’t need to remove the ‘NEW’ from the title, you could just add the old title to the {{anchor}} template immediately preceding it. Actually I’d suggest doing that and keeping the section title unchanged, so that translators don’t have to update the translated section titles to remove ‘NEW’ from them. It also has the benefit that links like Special:MyLanguage/IP Editing: Privacy Enhancement and Abuse Mitigation#Implementation Strategy and next steps (25 February 2022) work even if the section title is translated into the user’s language. —Tacsipacsi (talk) 16:07, 17 March 2022 (UTC)

The collapsible headings make the page a bit awkward. Usually when you click on a heading in the TOC you're directed to a section where you see the same headings, but here for example in section 6 you have subheadings 6.1-6.4 in the TOC but in the actual section there are two subheadings (Legal update 02 & 01). The TOC and page headings don't match and it's quite confusing (to me at least). -kyykaarme (talk) 12:02, 26 March 2022 (UTC)

Statistics woman!
Statistics woman, we need you! I'm quite serious, we do. A "session-based approach" has been decided upon. Exact details aren't quite known at this point I think, but "session-based" alone is making some vandal fighters shiver. What we need from you is quite simple: statistics. How much vandalism there is now, how much vandalism there is right before this is rolled out, how much vandalism there is right after and how much after vandal fighters (and vandals..) have had some time to get used to the new system. Important decisions may hinge on this, and without data no community can make an informed decision. Statistics woman, please, save the day. :-) — Alexis Jazz (talk or ping me) 03:36, 27 March 2022 (UTC)
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Talk:IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation/Archives/2021-11&oldid=23741684"