Wikimedia Forum: Difference between revisions

Content deleted Content added

Inline

Revision as of 13:10, 16 January 2020

The Wikimedia Forum is a central place for questions, announcements and other discussions about the Wikimedia Foundation and its projects. (For discussion about the Meta wiki, see Meta:Babel.)
This is not the place to make technical queries regarding the MediaWiki software; please ask such questions at the MediaWiki support desk; technical questions about Wikimedia wikis, however, can be placed on Tech page.

You can reply to a topic by clicking the "[edit]" link beside that section, or you can start a new discussion.

Participate:

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} and sections whose most recent comment is older than 30 days.

Sortable table scripts

Is there a more complicated sortable table script like javascript that you can use which recognises K as 1,000 and M as 1,000,000 when sorting rows?

Or if not, any others bar; {| class="sortable wikitable" ? — The preceding unsigned comment was added by 2A02:C7F:D827:BE00:A8D3:4B31:778D:30F6 (talk)

Information about sorting is at mw:Help:Sorting — billinghurst sDrewth 11:52, 18 December 2019 (UTC)[reply]

Voting requirement in CheckUser policy and Oversight policy

In these policies the voting requirement of successful CheckUser and Oversight election is 70–80% support and 25-30 support. This is a vague number. I propose to change it to excatly 70% and 25. Comments welcome.--GZWDer (talk) 19:21, 20 December 2019 (UTC)[reply]

Why? Tell me how it is ineffective? The numbers are not vague, they are specific, it is called a range. It is used by the stewards and it takes in a number of factors. There is no requirement for absolutism. — billinghurst sDrewth 21:16, 20 December 2019 (UTC)[reply]

So this means steward may decide whether or not to grant the flag if the number of support is between 25 and 30?--GZWDer (talk) 07:19, 21 December 2019 (UTC)[reply]

It gives the steward flexibility. Don't tell us the rule of 10+ years, show us how it is not working. — billinghurst sDrewth 07:48, 21 December 2019 (UTC)[reply]

I agree with GZWDer that the rule should be improved. 70% of support in most projects would make a simple RfA fail, yet apparently that'd be okay for an RfCU/OS? In addition, the policy must explicitly state that RfCU/OS cannot be opened forever in an attempt to get the required thresholds. Just put it simple: 75% of support and 25 votes in support as minimum requirements. I don't want flexibility when it comes to hand out permissions that involve people's privacy. CU/OS is not "not a big deal". I want clear, exact rules, easy to follow. Local wikis might still enact rules making access to the tool harder than the Meta policy. —MarcoAurelio (talk) 11:23, 21 December 2019 (UTC)[reply]

Except the proposal does not change the base criteria, and your suggestion now makes it harder. Stewards can close at 70% and 25 votes right now, completely within scope. I understand that the variability was due to not force stewards to close when 25 exactly was reached where some of the votes where edge cases and contentious, and as such game the system. The timing was left open as the smaller communities were not like the WPs and numbers were not immediate, though I would feel comfortable with an extended period of time that is not more than 3 months. — billinghurst sDrewth 12:37, 21 December 2019 (UTC)[reply]

@MarcoAurelio and Billinghurst: I have proposed an amendment in Requests for comment/Amendment of CheckUser policy and Oversight policy. Note in this amendment I also proposed a much more significant change.--GZWDer (talk) 14:17, 21 December 2019 (UTC)[reply]

Propose new global user group: Global strong IP block exemption

Nowadays it's common for many users to use a proxy to edit because of internet censorship. I propose a new user group similar to global IP block exemptions that can also bypass local IP blocks and local rangeblocks unless the wiki explicitly opt out of the user group. This may reduce the need to request local IP block exemption in individual wikis.--GZWDer (talk) 07:13, 31 December 2019 (UTC)[reply]

I would say "Full global IP block exemption". Ruslik (talk) 08:49, 31 December 2019 (UTC)[reply]

Comment Your proposal overrides local wiki administration, and I do not believe that this is a good idea. It pushes the requirement for this to be managed by stewards who are limited in number, and by stewards who would be unable to check the local large wiki as they do not have the rights to run those checks under the current system. I think the proposal is ill-conceived without consideration for the requirements to manage. The current system has stewards managing exemptions for the blocks they place, and local administrators managing the exemptions for their blocks. The current system allows for local admins measures to be the priority at local wikis, and that seems appropriate to me. — billinghurst sDrewth 08:52, 31 December 2019 (UTC)[reply]

I believe that this should only progress with a full RFC, and full notification to all wikis. Nothing less I feel is acceptable. — billinghurst sDrewth 08:54, 31 December 2019 (UTC)[reply]

I will add that the main propose of user group is to allow users to edit under open proxies and individual wiki may opt out from the group completely.--GZWDer (talk) 11:10, 31 December 2019 (UTC)[reply]

I think the purpose may not be useful at all. Wikis who may opt out from the group would be, in most of cases, the largest ones, which most of the time do not need global intervention. That would lead to small wikis, in which users could ask for the global IP block exemption group instead. Esteban16 (talk) 18:40, 31 December 2019 (UTC)[reply]

Support There are lots of reasons for this. A good one is that sometimes a wiki editor is well known in person and online to other established wiki editors, and this user is editing from a place where they are in danger for editing wiki, and lots of established wiki editors agree that this user ought to be able to edit Wikipedia. Right now we have no process for granting such a user rights to edit from VPNs. There are other cases but we cannot consider other ones until we fix something about this one. There are notes in lots of places like this and we do not have centralized conversation, but some are at Grants:IdeaLab/Partnership between Wikimedia community and Tor community and within that cataloging all ways. I would join a small group to talk through the next steps to advance this. If we were to do this, I expect the first step would be to collect everything already said and try to summarize it in one place. Blue Rasberry (talk) 13:22, 2 January 2020 (UTC)[reply]
Support I also support this, and suggest that having a discussion to flag benefits and challenges can be a first initial step as this issue seems to be growing in importance given many technical needs and challenges. --- FULBERT (talk) 19:25, 3 January 2020 (UTC)[reply]
Strong oppose Under no circumstances. This violates every principle of local control. En.wiki intentionally hard blocks ranges that are already globally hard blocked because we have a much stricter policy on this than the stewards do. This would be a way to circumvent allowing local projects to determine their own policies for level of trust needed to edit on a proxy and effectively allow sockmasters to bypass one of the best means we have at forcing them to reveal actual CU data. @SQL, ST47, and JJMC89: the three of you may be interested in this since the four of us have all been fairly active on the open proxy front on en.wiki.
While this has an opt-out provision, it is still dangerous as this would basically create an automatic opt-in on large projects without any consultation. Small-wikis aren't really impacted by this, as they don't have enough sysops to make large range blocks, and mid-sized ones have enough sysops and are large enough that they can effectively handle the granting of IPBE. There is no need at all for this except to make it much more difficult to prevent abuse of multiple accounts. TonyBallioni (talk) 19:35, 4 January 2020 (UTC)[reply]
Oppose Users who require the use of VPNs already have the ability to request local IPBE on the projects on which they are active. We routinely grant this when the requester demonstrates both a need and trustworthiness. We have any number of prolific sockpuppeteers and vandals who would jump at any opportunity to simply claim to be from a country which blocks Wikipedia and get a free pass around any and all IP blocks. This is a non-starter: IPs that are blocked are blocked for a reason. The choice of whether to grant an exemption to those blocks should be left to the community that implemented the block, which is the community that will actually be affected if the exemptions are granted too liberally. ST47 (talk) 20:48, 4 January 2020 (UTC)[reply]
This group would need to be more heavily restricted than the current GIPBE group, and I doubt it would ever get support from the anti-abuse people at large wikis. We need better anti-abuse infrastructure than blocking the means by which entire countries edit these projects. – Ajraddatz (talk) 20:56, 4 January 2020 (UTC)[reply]
Oppose. Projects that actively manage VPN / Webhosting ranges are likely to opt out, and the rest would be covered by current global IPBE. SQL ^{Query me!} 04:07, 5 January 2020 (UTC)[reply]
Limited support. If this was heavily restricted, such as only making global renamers, Stewards, global rollbackers, global sysops, and global interface editors eligible for right (and only after a second discussion with consensus to grant). As of the time of writing this, that group is only 206 total people (none of whom would be automatically be given this right). However, I don't much of a demand for this nor really do I see a point since the only wikis that would have been affected are the most likely to opt-out anyways. –MJL ‐Talk‐^☖ 04:42, 5 January 2020 (UTC)[reply]
- Global sysop is one of the least significant rights there is: it’s the ability to admin on projects with no active community and thus nothing to harm. Global rollback is more powerful as it’s truly global, but many editors who have it would never qualify for local IPBE on a major project. Stewards already have all rights. I couldn’t name a global interface editor. Renamers are usually sysops on their home project, so it wouldn’t be necessary, and even for those who aren’t, they’re almost always trusted locally so they can get it if actually needed. Relegating it to a clique of editors most people who edit content projects have never heard of isn’t ideal. TonyBallioni (talk) 05:34, 5 January 2020 (UTC)[reply]
  - Not sure what your obsession with measuring relative importance is all about. Global sysops have an important, and different, role from big wiki admins. There are some areas of experience overlap, some areas of difference. The substantive part of your comment, that a strong GIPBE is not necessarily relevant to advanced global permissions groups, is true. – Ajraddatz (talk) 05:52, 5 January 2020 (UTC)[reply]
    - The relative importance is part of the substance of the comment. It’s a measure of trust: global sysop alone does not meet the standard for a trusted user on most large projects, and that’s what this would be impacting. I know that’s not a popular thing to say on meta, but we give out global sysop relatively easily precisely because it can’t really harm much on projects that have local admins. Granting IPBE to them would change that. Remembering that most global rights holders are unknown outside these pages is important anytime we have a discussion about possibly expanding their technical rights based on the premise of trust. That’s not saying global rights holders aren’t trusted, but that trust is best assessed locally where it can be measured either via RfA or through a request for IPBE, not through a process on meta. TonyBallioni (talk) 06:04, 5 January 2020 (UTC)[reply]
      - @TonyBallioni: Global sysops are kind of a big deal to folks on smaller wikis. A global rollbacker can't do nearly as much damage to Scots Wikipedia that a global sysop could. Either way, my preference is for people who do a lot of cross-wiki work to be the only ones who are even eligible. That is just in the hypothetical situation where this pases (which it won't). –MJL ‐Talk‐^☖ 18:11, 5 January 2020 (UTC)[reply]
      - Hm. The argument that lumping in an unrelated permission, carrying consequences to community governance outside the original scope of the group, is valid. I think you can make that point without (intentional or otherwise) commenting on the relative importance of the role and the mechanism by which users are selected for it. But your point is taken. – Ajraddatz (talk) 00:56, 8 January 2020 (UTC)[reply]
Oppose. Based on global policies shouldn't infringe on local controls and if we allow opt-outs, we will see an issue where it resemble GS which most large wikis opted out. To note that most of the hard IP blocks (ACB types) are only placed either globally (which is GIPBE) or on large projects which opted out caused this to be moot. The only process will be something quasi GR,GS application but Tony opposition makes sense and I see it as more crumblesome than local requests. I just can't see any benefit from such a right.--Camouflaged Mirage (talk) 06:13, 5 January 2020 (UTC)[reply]
Support per User:Bluerasberry. remember Bassel Khartabil, we need to provide tools to avoid surveillance from those without our scruples. Slowking4 (talk) 02:42, 8 January 2020 (UTC)[reply]
Further comment If Global Sysops don't already have local IPBE on the wikis where global sysop has an effect, I would be open to adding that to global sysop. Not globally, but on the small wikis where global sysop is enabled. If Global Sysops do already have that power, I'm not sure why they are being mentioned above as a potential use-case for this permission. I don't see any reason for global sysops to automatically receive IPBE on wikis where they are not sysops, and if they need it, they can request it from the local admins. ST47 (talk) 13:18, 8 January 2020 (UTC)[reply]
Global sysops have "ipblock-exempt" though not "global-ipblock-exempt", as noted at Special:GlobalGroupPermissions. It would do no harm to add the extra right into place (not that I have heard of a global sysop being blocked by a steward's block.) It is a small hole, and it would need: a steward's block, with not local block at a wiki where there global-sysop rights don't apply; though it is a hole that should be removed. There would still the chance for a global sysop to be blocked at a wiki that has opted out, and local blocks are applied, and in those cases the person should seek local IPBE. — billinghurst sDrewth 21:56, 8 January 2020 (UTC)[reply]

Explain it again please

@TonyBallioni, ST47, SQL, and Camouflaged Mirage: Can any of you explain your oppose a bit more? Suppose this scenario: you want to edit your own accounts, these which I just pinged, where you already have a long history of wiki editing. However, you are traveling and for whatever reason you can only use a blocked IP address in your Internet connection. If you had IP block exemption, then that userright would be applied to this, your well known account, and permit you to edit from that account. Why would you think it is harmful if you personally were to edit using your own accounts, anywhere in Wikimedia projects, wherever you might be? Is there not some level of trust after which we let established accounts edit regardless of how they connect to Internet?

I was recently confused to be IP blocked from editing wiki from my own account from a wifi connection in the United States train service, Amtrak. What would have been the harm? Why is it so harmful to wiki and helpful to sockmasters to allow well established registered accounts do publicly logged activities while those accounts are logged in? And why not make the permission global across Wikimedia projects? Blue Rasberry (talk) 12:57, 8 January 2020 (UTC)[reply]

@Bluerasberry: Users who require IPBE can already request it globally (for global blocks) and locally on the projects where they are active (for local and global blocks). In fact, I already have global IPBE because I edit from a work network that is routinely globally blocked, and I have local IPBE on enwiki because I am a sysop (it is included in the sysop and bot permission groups). However, I don't need or want exemption from local blocks on all wikis. If the admins on a certain wiki block an IP range due to heavy abuse, or as part of a policy to block public VPNs or open proxies, then that wiki should have control over who is exempt from that block. Plus, it wouldn't make any sense for someone who is denied local IPBE to be able to go to the stewards and get it as a global permission, which local wikis would have no way of blocking or revoking. Given how easy it is to evade checkuser with IPBE, granting this permission globally would be very dangerous. ST47 (talk) 13:13, 8 January 2020 (UTC)[reply]

@ST47: Thanks and okay you convinced me - we we do exemptions, they should not be universal to all 300+ projects, but only for the limited few projects which a person uses and where monitoring is in place. That makes sense, so many people would only want 1 project, and some people would only want that lower-level ambient steward exemption. I am still doubtful about the accessibility of permission. On English Wikipedia, currently about 300 users have the IPBE flag (not counting admins) and there are many complaints on the talk page that people seeking it are not able to access it. You convinced me that even among trusted users we should not grant general permission, but somehow I am still seeing some users who seem worthy of some trust not able to access this. Blue Rasberry (talk) 15:50, 9 January 2020 (UTC)[reply]

@Bluerasberry: You were blocked by a steward's block, and either global IPBE (global-ipblock-exempt) or local IPBE (ipblock-exempt) would have allowed your account to edit at that wiki. That is not this proposal.

This proposal is to assign to a person both of those IPBE rights (global and local) at a stewards level and basically override any local hard IP block (admin-imposed or system-imposed). An example: if you are hard blocked by IP address at enWP as they don't like the edits coming from your IP address (logged in or logged out), the stewards can apply rights to an account so that you can edit from that IP address despite the local IP block. The proposal then allows wikis to opt out of being overridden. — billinghurst sDrewth 22:12, 8 January 2020 (UTC)[reply]

Addendum. This is my issue with this proposal as put forward. It sounds very sweet, however, is vague and does not explain the complexities of what is being proposed, especially at a technical level. The proposal should be put with both social and technical detail provided, explaining the features/benefits, strengths and weaknesses of the proposal, what it would allow in a positive nature, what it would allow in a negative nature, what it would not change. Who is going to manage this? What workload will it impose? What standard would be expected to allow someone to have it? Does it expire? What would be the optin/optout requirements. — billinghurst sDrewth 22:53, 8 January 2020 (UTC)[reply]

Thanks for the explanation because I was unaware of the "steward's block" concept, and I think I understand that now, and how and why local and global exemptions bypass that. I admit - I know nothing about the technical complexities of managing these rights. I said more below - can you clarify how much of this is a technical challenge versus a social one? Blue Rasberry (talk) 15:50, 9 January 2020 (UTC)[reply]

i think it's great stewards can unilaterially stop all editing from that notorious LTA farm and COI den, amtrak. rest assured editors will try to circumvent such necessary work stoppages, by asking for exemptions. they should be sternly denied; don't they know they are here at the sufferance of the functionaries? and rest assured librarians should not add references too fast under #1lib1ref, lest they be throttled as the vandals they are. we should all embrace the kiss up kick down ethics as the only and best way to run a railroad. Slowking4 (talk) 22:14, 9 January 2020 (UTC)[reply]

@Slowking4: You are being a doofus. You have been around long to have a level of understanding, and to not portray everything with a sense of negativity. I think that you will find that there was an consistently abused range, and it was not identifiable as being amtrak. When it was identified then there were changes made to the block. If there is any block in which people believe there is an issue then they can ask for a review at SRG. This is a world of complexity and the majroity of it is got right, and the rest is able to be reviewed when it is not got right. — billinghurst sDrewth 10:38, 10 January 2020 (UTC)[reply]

better doofus than burning down the village in order to save it. a proxy was identified and blocked, and no consideration was given for the disruption to editors. the attitude is clear, "why waste time talking when you can use a flamethrower". and the answer is "admin may i", i will be happy to advise the next room of librarians "mistakes are made, but reviewable in due course" and "vandal fighting is job one, and user experience writing an encyclopedia is always secondary". Slowking4 (talk) 14:57, 10 January 2020 (UTC)[reply]

local ip block effect to $wgautocreateaccount I think this is can be solve. This is very hard for new user come from other wiki to login in several wikis Sappra (talk) 22:47, 8 January 2020 (UTC)[reply]

If that can be done it would be great; that is an outstanding issue with SUL. – Ajraddatz (talk) 23:07, 8 January 2020 (UTC)[reply]

As something that GIPBE allows or for all users? Because the latter seems like a great way to let people evade ACB blocks. ST47 (talk) 02:13, 9 January 2020 (UTC)[reply]

As it stands, anon-only global blocks prevent account creation. This is intended, but not intended to prevent existing users who edit from proxies etc to be prevented from having their account automatically created elsewhere. Implications for other types of blocks would need to be examined, and couldn't be done for local hard blocks for instance (though those would block the account either way). – Ajraddatz (talk) 02:44, 9 January 2020 (UTC)[reply]

@Bluerasberry: I'm not sure how this would have helped you in that case. I think most large wikis would be very likely to opt-out of this permission as we prefer to manage our policies locally. Have you considered asking for IPBE locally, or asking the blocking admin (or the community) to re-evaluate the block? SQL ^{Query me!} 05:20, 9 January 2020 (UTC)[reply]

@SQL: I am unfamiliar with the process and did not quickly see the way to ask for permission. If there were a public and documented way to get the userright then I would, but if the only way to get it is with a special process, then I prefer not to seek permissions which are not accessible to everyone. I am still unclear what options exist. Blocking edits from the wifi of the United States national train service might be wise, and I do not object to that. I only find it strange because I ought to be trustworthy enough to make routine edits while logged into this my established account, and I could not find a way to do so. I also am trying to understand why it would be risky for me to edit, and what userright option is right for me and for me to recommend to others. Blue Rasberry (talk) 15:50, 9 January 2020 (UTC)[reply]

@Bluerasberry: I hope this is correct place to reply to you, this entire thread is a little confusing to follow. For me my opposition is that if we allow wikis to opt out, we will then resulted into a situation of Global Sysop-like permission where they can apply on certain wikis and not on the others. Like GS, I expect most large wikis to opt out and typically these are wikis which do hard IP blocking (Account creation Blocked) in settings. Hence, this entire right is almost useless. If we are to force every wiki to accept this right, we will almost get into a train-wreck, as even some of the truly global rights (like Global interface editors) can create controversy.

In addition, if we are to provide wikis with comfort that every candidate is properly vetted, we need a process like Global rollback or even more likely Global Sysop at SRGP which is really crumblesome. It may be easier to just ask at individual projects. For me, I asked for GR as I give up asking at individual projects for the rollback which I had asked at least 8 times in different projects. It is unlikely that a candidate for IPBE needs to edit so many project all with local hard IP blocks at one time. It will be more likely they are affected by global block which they can ask for GIPBE.

I hope this clarifies, feel free to ask me for anymore clarifications. --Camouflaged Mirage (talk) 10:56, 10 January 2020 (UTC)[reply]

Is this a social challenge or a technical challenge?

In my view, whenever this conversation comes up, it is typically established users saying that they want to edit from a VPN but the response is that this is risky because if established users could do this, then we also have to grant permission for random new account sockpuppets to do it also. I fail to see how giving permission to established accounts creates other risks, but I hear the repeated sincerity of various people who have said over the years that somehow there is great risk in granting this userright too freely.

Here is the proposal: experienced Wikipedia editors with a history of engagement should be able to edit Wiki projects from blocked IPs, like VPNs and publicly shared wifi, while logged into their established accounts. What is the origin of the risk in this scenario? Is the risk that the operator of the account would have too much power in case of their misconduct? If so, then I fail to understand that risk, because established accounts seem low risk, and also being able to edit from a VPN would not change the public logging and monitoring of all their actions or let them do anything they were not already doing. Is the challenge social, and that we currently lack a standard of trust? So far as I know, there are no cases of any experienced Wikipedia user getting IPBE rights, then engaging in misconduct which they otherwise could not have done. I am not even able to recognize what misconduct an account could perform with a VPN that it could not do without. So far as I understand, VPNs are risky for new accounts and sockpuppetting, but I fail to understand how and why VPNs are risky for established accounts.

If the challenge is social, and that we could do grant the right by establishing high standard of trust then we could organize that conversation. If the challenge is technical, and there is some liability in granting this userright to well-meaning but non-technical Wikipedia editors, then it would be helpful for me to understand that. Is the challenge that various Wikimedia projects manage this independently, and we have no easy way to reconcile or share notes on blocks in various Wikimedia projects? Thanks everyone. Blue Rasberry (talk) 15:50, 9 January 2020 (UTC)[reply]

We have fairly recent, and egregious, examples of users who would be considered experienced, but who had actually been abusing multiple accounts for many years. See for example w:User:Edgar181. (His admin account would have had local ipbe, but the socks would not.) Granting ipbe as broadly as you describe would allow an editor to create a sockpuppet, make a few hundred edits, get IPBE and immediately move to a VPN, wait 90 days for CU data to expire, and immediately start it up again. With good discipline they could easily avoid creating any technical link between the accounts. This is why enwiki chooses to require some sort of need before issuing IPBE, not simply experience. There are a handful of users with ipbe on other wikis, and even with gipbe, who are indef blocked on enwiki. Even a few users who are checkuser blocked for sockpuppetry. Good thing their global IPBE didn't allow them to evade our blocks on open proxies and VPNs. ST47 (talk) 16:33, 9 January 2020 (UTC)[reply]

(ec) @Bluerasberry: The issue is not with VPNs, it is people, be they be as vandals or as spambots. From my previous life as a steward we primarily dealt with spambots, xwiki LTAs, and occasionally at wikis following CU requests. As gIPBE is equivalent to reinstating normal editing capability, it is not a major issue to issue it to users with some gentle review as it allows editing to all the wikis again at a low risk of unseen vandalism, especially knowing that it does not override local wiki countermeasures. That is not the case with local wikis having to manage their requirements, especially as they are getting the targeted abuse.

As such stewards are setting a coarse filter, which works fine to get rid of the large rocks, and the wikis have their fine filters for the real problematic cases. As such why ST47's examples are useful as highlights, but not problems as how they are handled by stewards.

While GZWDer's proposal is lovely in a world of merit, however, that is not where we are living, as similarly indicated by ST47's comments. The situation is that those large wikis are hardly likely to give up their access to fine filters and hand over those keys to stewards and some vague process; one can see that they will opt-out where they have checkusers, so you are left with a large number of smalls wikis where this has no impact, and a small number of large wikis that may not opt out. As such the number of positive cases is likely going to be minimal. None of this information has been part of the proposal, nor is their any indication of the suspected numbers of people who would be impacted. It is a social solution without any quantification of the problem or the impact of the solution. — billinghurst sDrewth 10:59, 10 January 2020 (UTC)[reply]

Thanks. I will think about all this for a while. Blue Rasberry (talk) 15:05, 10 January 2020 (UTC)[reply]

Password reset under globally blocked IP range

As a local admin on zh.wikipedia, I received several unblock requests saying they can't reset their password because their IPs are globally blocked. In an earlier case, an local admin disabled the related global block temporarily and that user reported a successful password reset. However, this didn't work in a recent case. I'm confused about two things: Is it necessary to block password reset from a globally blocked IP? What should users with good faith, who are using a globally blocked IP, do to reset their password? --Tiger- (talk) 07:46, 6 January 2020 (UTC)[reply]

This is a long-term issue that no one has fixed yet. Please see phab:T109909. Due to these problems that you state, I think we should change it to permit password resets by blocked IPs, but limit the amount of password resets that can be triggered for an account in a 24 hour period to, perhaps, 5. Vermont (talk) 10:09, 6 January 2020 (UTC)[reply]

5? You would be killing me.

@Tigerzeng: Point them to try at metawiki as that is not globally password protected, and may give them an avenue through. At least as a first level response, and it is may be something that you can easily code into the mediawiki: ns text to make it easier. — billinghurst sDrewth 21:21, 6 January 2020 (UTC)[reply]

Do this at meta seems to be feasible. I'll try this next time someone comes to me. --Tiger- (talk) 08:18, 9 January 2020 (UTC)[reply]

WikiLovesEarth

wikilovesearth.bio

(LinkSearch: meta | en | es | de | fr | ru | zh | simple | c | d | Wikipedias: top 25 · 50 · major wikis · sc · gs)(Search: Google | en (G) | fr (G) | de (G) | meta (G) | backlinks | → links ←)

wikilovesearth.org

(LinkSearch: meta | en | es | de | fr | ru | zh | simple | c | d | Wikipedias: top 25 · 50 · major wikis · sc · gs)(Search: Google | en (G) | fr (G) | de (G) | meta (G) | backlinks | → links ←)

Important! Until October the biosphere site http://www.wikilovesearth.bio/ worked fine, since december it redirects to a porn site. Don't know if it's hijacked or domain sold or what happened there. That link is in use, so a crosswiki search run is necessary for to comment that link out or remove or replace by http://wikilovesearth.org/. --Achim (talk) 20:09, 13 January 2020 (UTC)[reply]

Edit: I sent an email to abuse@registrar.eu to let them check. --Achim (talk) 20:43, 13 January 2020 (UTC)[reply]

I emailed the WLE team, and they're going to contact the people who own/owned the domain. Cheers. Quiddity (WMF) (talk) 18:27, 15 January 2020 (UTC)[reply]

I don't think we have a crosswiki search tool, can COIBot help? Maybe billinghurst may want to take a look. Thanks much --Camouflaged Mirage (talk) 13:08, 16 January 2020 (UTC)[reply]

@@ Line 91: / Line 91: @@
 == WikiLovesEarth ==
+{{LinkSummary|wikilovesearth.bio}}
+{{LinkSummary|wikilovesearth.org}}
 '''Important!''' Until October the biosphere site http://www.wikilovesearth.bio/ worked fine, since december it redirects to a porn site. Don't know if it's hijacked or domain sold or what happened there. That link is in use, so a crosswiki search run is necessary for to comment that link out or remove or replace by http://wikilovesearth.org/. --[[User:Achim55|Achim]] ([[User talk:Achim55|talk]]) 20:09, 13 January 2020 (UTC)
 :Edit: I sent an email to abuse@registrar.eu to let them check. --[[User:Achim55|Achim]] ([[User talk:Achim55|talk]]) 20:43, 13 January 2020 (UTC)