Talk:IP Editing: Privacy Enhancement and Abuse Mitigation

Add discussion
Active discussions

About IP Editing (discuss)
About IP Addresses (discuss)  · IP Editing Restriction Study (formerly Login Required Experiment) (discuss)


IP Editing: Privacy Enhancement and Abuse Mitigation Archive index
This page is to collect feedback for the privacy enhancement for unregistered users project.
Hoping to hear from you. You can leave a comment in your language if you can't write in English.
Filing cabinet icon.svg
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 14 days and sections whose most recent comment is older than 120 days. For the archive overview, see Talk:IP Editing: Privacy Enhancement and Abuse Mitigation/Archives.

Please remember that this page is used by people from a number of communities, with different native languages. If you avoid using acronyms from your home wiki, that will help them participate in the discussion.

October FAQ Update QuestionsEdit

Thanks for the new update. If I have the ability to unmask and I have opted in to that preference does that mean that all IPs are automatically unmasked? How would this tie into session based unmasking? Depending on answers to this I'm likely to have some more questions. Thanks and best, Barkeep49 (talk) 20:20, 29 October 2021 (UTC)

Thanks for the questions, Barkeep49. We're working on getting Product, Legal and Trust & Safety together on a proposal for how to best unmask a number of IPs, but we're looking more at a one-click solution than a preference which works on all IPs forever. For one thing, we need the accesses to be logged. /Johan (WMF) (talk) 12:17, 1 November 2021 (UTC)
(For those who didn't see it, there is an update on how to handle masking at IP Editing: Privacy Enhancement and Abuse Mitigation#IP Masking Implementation Approaches (FAQ). It'll go out in Tech News on Monday. Johan (WMF) (talk) 12:24, 1 November 2021 (UTC))

Why?Edit

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)

ContributionsEdit

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)

Everyone is a sockpuppetEdit

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)

Cyphering IPsEdit

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)

Authorship concernsEdit

  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)

Use case for unmasking IPsEdit

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)

Global contributions and other external toolsEdit

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)

Masking algorithmsEdit

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)

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

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)

IPv6 and privacyEdit

"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)

Monitoring what happens in terms of editor behaviourEdit

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 preventionEdit

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)

We need fingerprints IDEdit

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)

    • Who needs to know more about fingerprints and probability of detection I recomended to check the site with collection of such Java Scripts. In Chrome engine is impossible to block all this fingerprints. It can do Firefox with privacy.resistFingerprinting option. However it is very easy to detect that privacy.resistFingerprinting is enabled. Blocking of fingerprints will return empty or known values. --2A00:1FA0:C433:8FC2:ACAE:2BAC:619E:8195 16:44, 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)

Archived without responseEdit

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 holderEdit

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)
Return to "IP Editing: Privacy Enhancement and Abuse Mitigation" page.