Ban IP edits on pt.wiki
Closed, DeclinedPublic

Assigned To
None
Authored By
Erico
Aug 24 2020, 3:20 PM
Referenced Files
F32251426: image.png
Sep 8 2020, 6:36 PM
F32251424: image.png
Sep 8 2020, 6:36 PM
Tokens
"Love" token, awarded by jardel."Dislike" token, awarded by JPLSilva."Dislike" token, awarded by He7d3r."Dislike" token, awarded by Jane023.

Description

Hi all!

Portuguese Wikipedia is discussing banning edits from IPs. This is an idea that has been discussed for a long, long time.

RfC link: https://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Esplanada/propostas/Banimento_de_IPs_(23ago2020)

There are no benefits, for ptwiki, in allowing IP editions, at least in the main domain. Over the years, IPs are slowly destroying the site.

In this scenario, the community is massively supporting the idea because we believes that mandatory registration will increase new users retention and decrease the energy spent to combat these edits, since the vast majority of which are inappropriate. Note that it is very easy to create an account.

No founding principle of Wikipedia would be disrespected. We will remain free, open, but more secure and credible.

However, there are doubts about the feasibility. There is no mention of this possibility, or any restrictions, in "Limits to configuration changes": https://meta.wikimedia.org/wiki/Limits_to_configuration_changes. On the other hand, WMF staff previously informed community members that this decision would be in the hands of the community.

Some points:

a) is it possible to ban IP edits?
b) if technically possible, what level of support is required?

Kind regards,
Érico Wouters

EDIT - Related links:
https://meta.wikimedia.org/wiki/Research:Value_of_IP_Editing
https://meta.wikimedia.org/wiki/Talk:IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation/Archives/08-2019#Simpler_solution_-_turn_off_IP_editing
https://discuss-space.wmflabs.org/t/report-on-the-hungarian-wikipedia-experiment-with-partially-disabling-flagged-revisions/1984

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

In the discussion of the Lusophone community, I was in favor of banning IPs, as they are the main vandalists of Wikipedia Lusophone; but the foundation principle says that

The ability of almost anyone to be able to edit (most) articles without registering.

she says without registering, it is an easy matter to assimilate; it is not a condition, in which if the community accepts the ban of IPs; banning happens. It is a condition, which I even understand why WMF employees refuse; I sincerely think it is even better to use the abuse filters and tools against vandalism, for example: Huggle - That it is easy to detect vandalism, and reverse it. I will exchange my vote for a disagreement for the part of the possibility that an abuse filter is possible, since the filter will monitor the edits by IPs and be able to revert it if it is vandalism and would not have to ban IPs; that I violated a pillar of the foundation's principles.

dbarratt renamed this task from RFC: Banning IP editions on pt.wiki to Ban IP editions on pt.wiki.Aug 28 2020, 1:51 PM

In the discussion of the Lusophone community, I was in favor of banning IPs, as they are the main vandalists of Wikipedia Lusophone; but the foundation principle says that

The ability of almost anyone to be able to edit (most) articles without registering.

she says without registering, it is an easy matter to assimilate; it is not a condition, in which if the community accepts the ban of IPs; banning happens. It is a condition, which I even understand why WMF employees refuse; I sincerely think it is even better to use the abuse filters and tools against vandalism, for example: Huggle - That it is easy to detect vandalism, and reverse it. I will exchange my vote for a disagreement for the part of the possibility that an abuse filter is possible, since the filter will monitor the edits by IPs and be able to revert it if it is vandalism and would not have to ban IPs; that I violated a pillar of the foundation's principles.

First, there is no pillar being "violated". We are challenging not a pillar, but a "foundational" principle born and implemented at wiki.en in 2005, 4 years after wiki.pt was running as a community. Nobody there was consulted, as far as I know, before alien entities decided that the bizarrery that "anyone can edit" forcibly included IPs - which are not persons, and are not equivalent to them - was something "foundational". Not unsurprisingly, that topic has been controversial since ever at wiki.pt, with a lot of community members wanting to get rid of it, but with fear of challenging a status quo where they had no word, to start with. To me, this was clearly a colonial/imperial-like interference of the wiki.en community into other local communities, which unfortunately continues to be perpetuated.

As for filters and Huggle, the first requires a very qualified task force to implement, monitorize and update, while the second relies on the availability of enough qualified members of the community to run Huggle almost continuously, or at least at peak times. Both have shown to be very problematic over the times due to the very limited community resources. While we have a stupendous battery of filters in place now, it is the work of 4 or 5 persons at most, and it's not replicable. And we need a minimum taskforce for at least monitoring and updating them, which often is not available. Either you already have an expertize on stuff like regexp and an excellent domain of logic, or it would be quite difficult to make something useful with them. As for Huggle, not only there is a chronic problem of people willing to waste their volunteer time there operating it, instead of creating content, but it's a bad solution as well, since it fills up the historic of the articles with revertions after revertions, polluting it and making it much less readable.

Finally, about the mentioned "foundational principle", let's not forget the huge fallacy of talking about "freedom" when referring to using IPs to edit. IPs are a liability, both for then persons behind them, for the project and ultimately for WMF, which has the obligation/ideal of ensuring a safe environment for editing the projects. IPs can reveal who and where you are, up to the desk the computer is installed at. Just to mention a well known case from wiki.pt, less than 2 years ago a military police worker from São Paulo, Brasil, which politically edited Wikipedia using and IP from the Military Police network, was easily detected, publicly denounced and subject to disciplinary process and other charges at their workplace, for using an IP he most probably believed was "anonymous", as Wikipedia policies very wrongly call them. This liability and source of danger for Wikipedia users should have been more than enough reason to have thrown that "foundational" principle down the toilet long ago. Yet, inexplicably, there are still people defending it (never caring to explain why, but just parroting "it's the status quo", as you just did). In any case, calling this "anonymity" and "freedom to edit" is nothing but a sad joke.

Best,
Paulo

Boldly re-opening this task. With great respect to @Ladsgroup, I find the reasons given in T261133#6406865 to be non-technical and speculative.

This task still requires Product Owner input (who?) to be implemented. I do not see any technical objections. If there are Product or Technical objections, please feel free to decline.

Likewise, I think it is worth considering other technical implementations to solve the described problem as is recommended in T261133#6406865.

Ladsgroup closed this task as Declined.EditedAug 28 2020, 3:32 PM

From https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes

Gaining on-wiki consensus and filing a task does not guarantee that the request will be fulfilled. Ultimate authority lies with the system administrators, and site configuration requests may be declined for any reason, including but not limited to the following: to protect the Wikimedia founding principles and core values, to protect the integrity of a project, because performance issues or because fulfilling the request would include deploying an extension that was discontinued.

It doesn't need to be technical to be rejected and we have been rejecting similar requests by other communities before (IIRC). Me and other members of the team of deployers (including Martin and others) decided this is against "Wikimedia founding principles". If you're willing to override this, please give the team a board directive or a statement from c-levels. For improving anti-vandalism and anti-harassment tools in ptwiki, please create other tickets.

First, there is no pillar being "violated". We are challenging not a pillar, but a "foundational" principle born and implemented at wiki.en in 2005, 4 years after wiki.pt was running as a community. Nobody there was consulted, as far as I know, before alien entities decided that the bizarrery that "anyone can edit" forcibly included IPs - which are not persons, and are not equivalent to them - was something "foundational". Not unsurprisingly, that topic has been controversial since ever at wiki.pt, with a lot of community members wanting to get rid of it, but with fear of challenging a status quo where they had no word, to start with. To me, this was clearly a colonial/imperial-like interference of the wiki.en community into other local communities, which unfortunately continues to be perpetuated.

Finally, about the mentioned "foundational principle", let's not forget the huge fallacy of talking about "freedom" when referring to using IPs to edit. IPs are a liability, both for then persons behind them, for the project and ultimately for WMF, which has the obligation/ideal of ensuring a safe environment for editing the projects. IPs can reveal who and where you are, up to the desk the computer is installed at. Just to mention a well known case from wiki.pt, less than 2 years ago a military police worker from São Paulo, Brasil, which politically edited Wikipedia using and IP from the Military Police network, was easily detected, publicly denounced and subject to disciplinary process and other charges at their workplace, for using an IP he most probably believed was "anonymous", as Wikipedia policies very wrongly call them. This liability and source of danger for Wikipedia users should have been more than enough reason to have thrown that "foundational" principle down the toilet long ago. Yet, inexplicably, there are still people defending it (never caring to explain why, but just parroting "it's the status quo", as you just did). In any case, calling this "anonymity" and "freedom to edit" is nothing but a sad joke.

Hello Darwinius, well ... there is no wiki that I know of, that IPs have been banned, I understand that people inexplicably still defend (never bothering to explain why, but just repeating). But this request will only be made if WMF employees; not taking that request, a "violation" of the founding principles. And I will change (again) my vote to Agree, because it is still possible to use the abuse filters; in relation to the abuse filters I refer to the Filter 180.
In short, we need to find a way or an answer for WMF employees to accept the ban, without them claiming that it "violates" the founding principles; the more I believe it is possible. Send one, good luck with that decision!

P.S .: I forgot to add that the order will only be accepted if ALL WMF employees; do not consider it a violation of the founding principles.

But this request will only be made if WMF employees; not taking that request, a "violation" of the founding principles

You're aware right that the people objecting are mostly not currently WMF employees/contractors.

Unless i missed people's WMF employee/contractor status changing (entirely possible), the only current wmf people commenting here are: aklapper, tgr, dbarratt and keynote2k. Contrary to popular belief the developer community is not just WMF employees

Unless i missed people's WMF employee/contractor status changing (entirely possible), the only current wmf people commenting here are: aklapper, tgr, dbarratt and keynote2k.

And Ladsgroup declining the task twice.

Thank you @Tgr for the constructive and helpful comment!

Unless i missed people's WMF employee/contractor status changing (entirely possible), the only current wmf people commenting here are: aklapper, tgr, dbarratt and keynote2k.

And Ladsgroup declining the task twice.

I'm not working for WMF.

And Ladsgroup declining the task twice.

I'm not working for WMF.

I'm sorry for the misunderstanding. It would help to clarify what "As a software engineer in Wikimedia Germany" means in that case and how much difference WMF or WMDE makes in regards to affiliation.

Suggesting changes to founding principles, or asking that a certain project be exempted from them, is a valid discussion for global community forums like Meta or wikimedia-l. (Not one that's likely to succeed, but valid nevertheless.) Phabricator is not such a forum. (See Phabricator etiquette.) Please do not get into policy debates here, you will be wasting your time, and you will be wasting other people's time too.

De facto policies around anonymous edits have been shaped by research on the value of IP editing. If you want to have a productive discussion about whether those policies are wrong for pt.wiki, or in general, engaging with the arguments made on that page is probably a good way forward.

Why would it be a valid discussion for the "global community" (whatever that is), and not for phabricator? I don't recall anyone from wiki.pt being forced to ask the "global community" if we could implement the local upload of copyrighted files when it was approved by community decision back in 2009.
As far as I know, it was simply implemented by the devs based on that decision, without any kind of drama, like is happening here.

This is not a "policy" debate. This is about a (still eventual, though probable) community decision. I really do not understand what is the basis for the refusal.
I hope it's not this joke or personal essay from 2004, which, as far as I know, has never - NEVER - been sanctioned by any community.

I would also like to stress that this kind of study, even if interesting for those studying wiki.en, is unrelated to our community at wiki.pt. You can't take evidence gathered in one specific context and community and blindly apply to an entirely different community without any kind of evidence that both share the same context. Without that evidence, it is basically irrelevant and unhelpful.

Best,
Paulo

Request of enabling CAPTCHA for IP edits in ptwiki was similarly declined on 2013 by Deputy Director of WMF at the time on similar grounds: T51860#589243 ptwiki is not first wiki to make such requests and all similar requests have been denied already:

I'm boldly declining this as T214876#4915725 has not been answered, and as "Disabling anonymous editing was seen to violate the inclusivity of the Founding principles" which I assume is even a bigger problem in communities of smaller languages.

Note that declining does not mean that you cannot continue discussing here, but the first step seems to be providing more information about your AbuseFilter rules instead (and potentially improving that first).

Nothing here makes ptwiki an exception, if you wish to be granted an exception, please get a board directive for us.

I don't recall anyone from wiki.pt being forced to ask the "global community" if we could implement the local upload of copyrighted files when it was approved by community decision back in 2009.
As far as I know, it was simply implemented by the devs based on that decision, without any kind of drama, like is happening here.

The possibility to define local EDPs for "Fair Use" etc had been a documented cross-wiki policy since before 2009, according to
https://foundation.wikimedia.org/w/index.php?title=Resolution:Licensing_policy&oldid=20032 . Hence a different situation and not some controversial precedent.

Request of enabling CAPTCHA for IP edits in ptwiki was similarly declined on 2013 by Deputy Director of WMF at the time on similar grounds: T51860#589243 ptwiki is not first wiki to make such requests and all similar requests have been denied already

And now we have the worst of the worlds, with newbies having to solve CAPTCHAs in their first editions, demotivating them, while IPs are free to vandalize at will.

Another very alarming, dangerous and worrisome thing: Anyone editing unregistered at wiki.pt both through the Wikipedia app, and through Visual Editor (mobile or desktop) is not aware in the least that they are revealing their IP to the world. There is no warning, no information, nothing. The person simply saves the edition, and their IP gets revealed without any kind of warning nor consent. You can imagine the kind of (even possibly fatal) danger this kind of thing represent, even to registered editors who log out by accident and do not realize they are logged out when they edit? There have already been documented cases of people persecuted in their workplace and menaced with judicial process for doing controversial editions unregistered at wiki.pt. It's not even theoretic anymore.

As someone wisely noted, the best way to protect people using IPs is to ban the use of IPs.
It is quite unbelievable how this terrible security flaw is still there after almost 20 years of project.

Best,
Paulo

Another very alarming, dangerous and worrisome thing: Anyone editing unregistered at wiki.pt both through the Wikipedia app, and through Visual Editor (mobile or desktop) is not aware in the least that they are revealing their IP to the world. There is no warning, no information, nothing. The person simply saves the edition, and their IP gets revealed without any kind of warning nor consent. You can imagine the kind of (even possibly fatal) danger this kind of thing represent, even to registered editors who log out by accident and do not realize they are logged out when they edit? There have already been documented cases of people persecuted in their workplace and menaced with judicial process for doing controversial editions unregistered at wiki.pt. It's not even theoretic anymore.

The visual editor shows this popup by default:

image.png (540×392 px, 24 KB)

The Android app also tells this at least in English:

image.png (291×406 px, 66 KB)

In T261133#6443906, @Majavah wrote:

Another very alarming, dangerous and worrisome thing: Anyone editing unregistered at wiki.pt both through the Wikipedia app, and through Visual Editor (mobile or desktop) is not aware in the least that they are revealing their IP to the world. There is no warning, no information, nothing. The person simply saves the edition, and their IP gets revealed without any kind of warning nor consent. You can imagine the kind of (even possibly fatal) danger this kind of thing represent, even to registered editors who log out by accident and do not realize they are logged out when they edit? There have already been documented cases of people persecuted in their workplace and menaced with judicial process for doing controversial editions unregistered at wiki.pt. It's not even theoretic anymore.

The visual editor shows this popup by default:

image.png (540×392 px, 24 KB)

The Android app also tells this at least in English:

image.png (291×406 px, 66 KB)

No, it does not. I just tested (again), and nothing of that sort appears. Not in the wikipedia app, not on desktop mode, and not in the mobile mode (which I just tested again 1 minute ago, just to be sure).

In T261133#6443906, @Majavah wrote:

[...]

No, it does not. I just tested (again), and nothing of that sort appears. Not in the wikipedia app, not on desktop mode, and not in the mobile mode (which I just tested again 1 minute ago, just to be sure).

I just tested all three myself (and took screenshots visible on my comment), and every method I tried tells it very clearly. Did you try it in a private window (where there aren't any cookies which may remember you dismissing such popups earlier)?

In T261133#6443939, @Majavah wrote:
In T261133#6443906, @Majavah wrote:

[...]

No, it does not. I just tested (again), and nothing of that sort appears. Not in the wikipedia app, not on desktop mode, and not in the mobile mode (which I just tested again 1 minute ago, just to be sure).

I just tested all three myself (and took screenshots visible on my comment), and every method I tried tells it very clearly. Did you try it in a private window (where there aren't any cookies which may remember you dismissing such popups earlier)?

Yes. The wikipedia app I downloaded and edited: No warning. Desktop mode: experimented in a private window. My edit is there, live - No warning as well. Mobile phone: I'm always logged out there, so that was easy. I just edited, also no warning, at all.

In T261133#6443939, @Majavah wrote:
In T261133#6443906, @Majavah wrote:

[...]

No, it does not. I just tested (again), and nothing of that sort appears. Not in the Wikipedia app, not on desktop mode, and not in the mobile mode (which I just tested again 1 minute ago, just to be sure).

I just tested all three myself (and took screenshots visible on my comment), and every method I tried tells it very clearly. Did you try it in a private window (where there aren't any cookies which may remember you dismissing such popups earlier)?

I've just sent you an email with some the tests I've been making, they are all linked to my IP, though using different platforms and modes to edit.
I can also post any screenshot that may be useful, though nothing of that sort of what You've shown appeared on any of these 3 situations. Editing by code (which very few IPs use, I suppose) shows a quite discrete warning in pale grey saying I'm using my IP, but not the other 3.

Paulo

Keep in mind the only way to get sysadmins to deploy this is to present an approval from the Board - there is no sense in discussing validity of IP editing in this task.

Please split potentially non-working IP exposure warnings into a separate conversation not in this ticket. Thanks a lot.

This is not a "policy" debate. This is about a (still eventual, though probable) community decision.

That's the problem: you see this as a community decision that must be implemented. The sysadmins see this as a problem that cannot be solved in the proposed way. Please focus on solving the problem, not trying to ram through the proposed solution.

You have suggested that several things need to be improved (e.g., the things that have been tried on ptwiki and have not worked). Have you opened any Phabricator tasks about those things? If not, then you're just wasting everyone's time.</harsh>

You have suggested that several things need to be improved (e.g., the things that have been tried on ptwiki and have not worked). Have you opened any Phabricator tasks about those things? If not, then you're just wasting everyone's time.</harsh>

No, I've not. I noticed in the last few days, while exploring how life was for an IP on wiki.pt. I'm a volunteer here, and the time I dedicate to these things is limited. Furthermore, I have not the least idea if those things such the lack of warnings for IPs and CAPTCHA for newbies are by design or are bugs. But I will take some time to open a phabricator task, at least for the lack of warnings, as @Aklapper suggested.

In any case, I do believe I'm entitled to rant or mumble about allowing such egregious security problems as revealing ones IPs to the world - sometimes due to accidental/undetected log out, as has happened to me and a lot of people I know - while being deeply concerned about "foundational principles" that are nothing but a joke or personal essay made by someone back in 2004, that somehow passed into something that is now looked as "official" without having been subject to any kind of approval by any Wikimedia community, at least that I'm aware of.

Best,
Paulo

For background on captchas at registration, see T241921: Fix Wikimedia captchas. It's an unfortunate situation, but there is no easy way to improve it.

For background on captchas at registration, see T241921: Fix Wikimedia captchas. It's an unfortunate situation, but there is no easy way to improve it.

I know about that problem with captchas at registration, which has been preventing blind people from registering their accounts autonomously (why is it not spelt with sound, as many other captchas everywhere? That would allow the blind to register accounts without the support of someone else). But that is not what I'm talking about.

I routinely lead and monitor activities with students which have to act as newbies, as well as new editors that register during edit-a-thons and other focused activities. They always have to struggle with the captcha during their initial editions, which is quite awkward, since as IPs whey would not have to struggle with any kind of similar obstacle - while they face it after registering the account. Of course, this also means that the blind not only need support for registering, but also for their first editions as newbies, since there is no way they can see the captcha, and Wikimedia cahptchas for some reason can't be heard (they do not have a sound /spelt version).

I've no idea why newbies also have to struggle with those additional captchas when they try to edit, while IPs are free to edit at will without any kind of similar obstacle. Is this by design?

Paulo

The captcha conditions for IP editors and non-autoconfirmed editors are identical (inserting external links). Admins can manually confirm new users, that might be a worthwhile thing to do for outreach events. (Likewise, you can ask participants for their preferred username at the start of the event, and create their accounts for them, so they don't have to deal with the captcha.)

The captcha conditions for IP editors and non-autoconfirmed editors are identical (inserting external links). Admins can manually confirm new users, that might be a worthwhile thing to do for outreach events. (Likewise, you can ask participants for their preferred username at the start of the event, and create their accounts for them, so they don't have to deal with the captcha.)

I can't test that without creating an account, but your explanation seems to agree with the cases where the captcha appeared to the newbies (they were creating new articles).

If it's me creating the accounts, they start already confirmed? Or do I still have to confirm them?

If it's me creating the accounts, they start already confirmed? Or do I still have to confirm them?

You still have to do it. (Automating that is not a bad idea; I filed T262621: Add checkbox to account creation form for making the user manually confirmed.)

Tgr renamed this task from Ban IP editions on pt.wiki to Ban IP edits on pt.wiki.Sep 25 2020, 8:20 PM

I disapprove of the action being requested here (I gave a thumbs down token) but I love this discussion. I love it especially because the elephant in the room is nowhere in the (admittedly very thoughtful) comments. Let me start by suggesting that not all wikipedias are created equal and some are considered more equal than others. On a sliding scale of equality, I think I would begin with the Finnish Wikipedia and end maybe with various failed incubator wikis or that story of the hijacked Wikipedia (sorry can't remember which that was). I think the ptwiki has always fascinated me because the European origin of the language is so far away physically from the most speakers of the language. In a way, it is a breeding ground for social unrest on a global scale against colonial views and antiquated notions of what we like to call "reliable sources". I would love to see a demographic breakdown of the abusive IP edits, but sadly that would probably be against our principles to create. Maybe it has been done on a voluntary basis already and if so I for one would love to read the English summary! Otherwise, maybe this would be a good idea to organize: appoint local contributors per major city to conduct local editor surveys.

In a way, it is a breeding ground for social unrest on a global scale against colonial views and antiquated notions of what we like to call "reliable sources".

We have a number of endemic problems at wiki.pt, but, curiously, what you mention never, ever happened there, as far as I know. Unfortunately, till this day wiki.pt stays populated almost only by Portuguese and Brazilian editors. Brazilian society is not that different from the Portuguese (both are basically mainly European, both have strong influences and inputs from Africa and other parts of the globe). Also, Brazil vs. Portugal is very similar to EUA vs. England. Apart from the indigenous nations and their descendants - which continue to be persecuted in Brazil till this day - what you really have there is the descendants of the actual colonizers and the ones enslaved by them, as well as a lot of other ppl that migrated there after independence of the territory was granted to the settlers (at least this is how ppl generally identify themselves there).

Maybe if Africa was in the game things would be different, but unfortunately their (our, since I live in what is geographically Africa, as well :P but culturally the identity here is European, so it really doesn't count) presence continues to be residual, despite a lot of effort to engage those populations.

Best,
Paulo

If it's me creating the accounts, they start already confirmed? Or do I still have to confirm them?

You still have to do it. (Automating that is not a bad idea; I filed T262621: Add checkbox to account creation form for making the user manually confirmed.)

Thanks! That would be very helpful, indeed. Granting conformation to dozens of students can be a PIA

what you really have there is the descendants of the actual colonizers and the ones enslaved by them, as well as a lot of other ppl that migrated there after independence of the territory was granted to the settlers (at least this is how ppl generally identify themselves there)

Perhaps an analysis of the overlap between the Yoruba and Portuguese wikis might help shed some light on the problem then? If the overwhelming majority of abusers are in the overwhelming majority of readers (which would be a logical conclusion), then perhaps some of the vandalism is shared by both?

what you really have there is the descendants of the actual colonizers and the ones enslaved by them, as well as a lot of other ppl that migrated there after independence of the territory was granted to the settlers (at least this is how ppl generally identify themselves there)

Perhaps an analysis of the overlap between the Yoruba and Portuguese wikis might help shed some light on the problem then? If the overwhelming majority of abusers are in the overwhelming majority of readers (which would be a logical conclusion), then perhaps some of the vandalism is shared by both?

Why Yoruba? I don't think there is any relation between the two wikis. Afro-Brazilian culture has a lot of yoruba related traditions and words, but people there don't speak that language, as far as I know. In any case, I don't think there is any relation at all between that and vandalism. Wiki.pt vandalism comes mostly from a single source, which is very well identified: Educational institutions (and students, at home).

Why Yoruba?

Interesting! I was under the impression that it is one of the official languages of Brazil, which would indeed be very weird if no one spoke it there

Why Yoruba?

Interesting! I was under the impression that it is one of the official languages of Brazil, which would indeed be very weird if no one spoke it there

Brazil only has two official languages, Portuguese and gestural language. Yoruba (or a version of it) is still used as a ritual language in some parts of Brazil, and there are many words that were borrowed from that language, but as far as I know there are no speakers of it over there.

Hi, while this is an interesting conversation, discussing where which languages are spoken doesn't feel directly related to the topic of this ticket.
It would be nice if you could consider taking that conversation to a better suited venue, e.g. on-wiki. Thanks for your understanding!

Hi, while this is an interesting conversation, discussing where which languages are spoken doesn't feel directly related to the topic of this ticket.
It would be nice if you could consider taking that conversation to a better suited venue, e.g. on-wiki. Thanks for your understanding!

the question or comment was (at least originally) about vandalism on wiki.pt, which I suppose is on topic. As I said, Wiki.pt vandalism comes mostly from a single source, which is very well identified: Educational institutions (and students, at home). This bit we know quite well, for years. But I've never seen any efficient toll we could use to deter it, apart from blocking them entirely.

Just to log this somewhere: since 5th October, Portuguese Wikipedia started blocking IP access to editing via scripts (with thousands of user-facing client errors: T264665) and abuse filters that already drew criticism from WMF Legal.

If everyone seems to be OK with the situation (some people at WMF in T264940 seem to be), it would’ve honestly been better to use MediaWiki’s built-in restrictions instead of this b-... workaround stuff.

The rejection doesn't mean they can circumvent it. I let WMF T&S know.

Just to log this somewhere: since 5th October, Portuguese Wikipedia started blocking IP access to editing via scripts (with thousands of user-facing client errors: T264665) and abuse filters that already drew criticism from WMF Legal.

If everyone seems to be OK with the situation (some people at WMF in T264940 seem to be), it would’ve honestly been better to use MediaWiki’s built-in restrictions instead of this b-... workaround stuff.

They are mocking the rules of the project. It doesn't matter if Wikimedia doesn't agree, they own the playground.

I had already warned you about this imposition here. Will Wikimedia need to intervene?

Coming back to this 3 years later: if ptWP was allowed to proceed with their IP edit ban, it should still be done on the server side, not on the frontend.

Also, Farsi Wikipedia was allowed a configuration change in T291018: Temporarily disable article editing by anonymous users on fawiki

The rejection doesn't mean they can circumvent it. I let WMF T&S know.

Seemingly, WMF T&S doesn’t care.

Em T261133#8994615, @stjn escreveu:

Coming back to this 3 years later: if ptWP was allowed to proceed with their IP edit ban, it should still be done on the server side, not on the frontend.

I've been thinking about this for a while now, but today I'm not sure it's a good idea. Everyone is happy with the way it's working and moving to a server-side configuration could break some part of the current workflow (special attention to T287228).

Also, Farsi Wikipedia was allowed a configuration change in T291018: Temporarily disable article editing by anonymous users on fawiki

And we had different results, where part of that could be attributed to the way it was implemented.

Coming back to this 3 years later: if ptWP was allowed to proceed with their IP edit ban, it should still be done on the server side, not on the frontend.

I've been thinking about this for a while now, but today I'm not sure it's a good idea. Everyone is happy with the way it's working and moving to a server-side configuration could break some part of the current workflow (special attention to T287228).

Then these workflows need to be implemented server-side. It is simply unacceptable that this is a client-side solution for years.

@stjn can you clarify? Last I checked ptwiki is preventing this "server side" (via https://pt.wikipedia.org/wiki/Especial:Filtro_de_abusos/180) not client-side, such as by javascript. Yes, there are better server-side ways to do this, but that isn't a server vs client difference.

Last I checked ptwiki is preventing this "server side" (via https://pt.wikipedia.org/wiki/Especial:Filtro_de_abusos/180) not client-side, such as by javascript.

This too. We have:

  • Two scripts that directs the logged out user to the login screen when he clicks on the edit link.
  • The filter that prevents logged-out users from editing and
  • Several IP range blocks that block the busiest ranges, "alleviating" the abusefilter.

Allied to these measures, we modified some messages in the MediaWiki (example) so that it does not appear that our future editor is "blocked" or that he is "prevented from editing", just that he needs to create an account first.
It sounds confusing, but works like a charm.

Thanks for the note Albertoleoncio, so other than the link to discourage edits, all of the heavy lifting is being done "server-side".

@stjn can you clarify? Last I checked ptwiki is preventing this "server side" (via https://pt.wikipedia.org/wiki/Especial:Filtro_de_abusos/180) not client-side, such as by javascript. Yes, there are better server-side ways to do this, but that isn't a server vs client difference.

That’s ‘server-side hacks’, not ‘server-side’. All of the interface changes are done by JS-defined tricks, users can still access editing interface, not notice the (ugly) banner, and edit the page unknowingly (and, crucially, save their personal IP in the abuse filter logs). That should not be the case when IP users are not allowed to edit entirely. I mean, one hack they could’ve also done is use Titleblacklist to prohibit editing entirely from the start, but that’s still a hack. Their solution should be done and visible without scripts.

Especially since it is somewhat incomplete: edit warning on mobile says something like Warning: You are not authenticated. While your edits are welcome, you may need to create an account before editing this page. By creating an account, you will also enjoy many other benefits. whereas the wiki doesn’t allow the IP editing at all. Mobile version already has native handling of IP edit ban as well, which locally hacked version doesn’t use.

Agree it could certainly be better, just noting that the actual enforcement is being done server side, not client-side. Were this to rely on client-side enforcement it would be trivially bypassed.

I also agree that implement it in the MediaWiki configuration is better than the current implementation.

When the javascript trick does not work for some reason (e.g. browser js disabled or web app edit), the non-logged users only discover they can not edit after they write something and try to save, that is not the ideal. And also there is no "view source" button for IPs.

If the IP restriction would be implemented via MediaWiki configuration today, the only change is that it would fix those details, it would not be a big change because IPs already can not edit for more than 2 years.

The WMF didn't say we can not do that, their reaction was study the consequences, and their study showed the results were in general positive. In my opinion, the main reason for not apply it via MediaWiki configuration is technocracy, the people who have the knowledge and privileges to implement it are using it to impose their own interpretation of what the wiki philosophy is.

Tgr changed the task status from Declined to Resolved.Jul 8 2023, 2:05 AM

IP edits are not possible on ptwiki so setting status accordingly.

IP edits are not possible on ptwiki so setting status accordingly.

It is clear to me that this request was opened in order to prevent IP edits via MediaWiki configuration and not by local admins abuse filters, local range blocks, and Commons.js changes after this being denied in this discussion. I don't think we have to be that clear and I'd rather suppose that you actually got the idea. By reading developers' comments, it is also clear that it was declined (more than once) and they definitely understood the purpose of this ticket and we are clearly on the same page.

It is also clear that whatever understanding of principles developers have is taken with respect, but won't change the results. Portuguese Wikipedia will keep banning IP edits on main domain, so those that have permission can accept or deny to make that experience better. Wouldn't it be better to make it via MediaWiki configuration?

Setting it as "resolved" is innacurate to say the least. I believe Portuguese Wikipedia editors were comfortable with that rejection and there is no need to make it subtle.

Darwinius changed the task status from Resolved to Declined.Jul 19 2023, 9:44 PM

This task was never "resolved". It was declined due to prevalence of individual POV of phabricator admins over the Portuguese Wikipedia community decision, as @Teles wrote above. Changed the status accordingly.