Stewards/Confirm/2018/Vituzzu

< Stewards‎ | Confirm‎ | 2018

logs: rights, globalauth, gblblock, gblrights | translate: translation help, statement

English:
  • Languages: it, scn, en-2, fr-2, la-1, es-1, pt-1
  • Personal info: I'm always in a hurry but, well, I'm still able to handle a bunch of things which may be useful. I still blame the common lack of resources to solve big problems, some of them have been laying unsolved for years. But also I blame lacking of technical support in some vital aspects of our duties. On the other hand, working on the wp0 abuse case I got in touch with many communities amazingly open to cooperate with us. These efforts to cooperate are way to precious to be wasted in addressing problems which may be effectively addressed in a technical way.
italiano:
  • Lingue: it, scn, en-2, fr-2, la-1, es-1, pt-1
  • Informazioni personali: Vado sempre di fretta ma riesco comunque a gestire un po' di cose che dovrebbero essere risultare utili. Me la prendo ancora con la mancanza di risorse che impedisce di risolvere alcuni grossi problemi che giacciono irrisolti da anni. Ma me la prendo anche con la mancanza di supporto tecnico in alcuni aspetti cruciali del nostro ruolo. D'altro canto lavorando sugli abusi via wp0 mi è capitato di entrare in contatto con molte comunità estremamente ben disposte nel cooperare con noi. Questi sforzi di cooperazione sono troppo preziosi per essere sprecati per gestire problemi che potrebbero essere risolti per via tecnica.
español:
  • Idiomas: it, scn, en-2, fr-2, la-1, es-1, pt-1
  • Información personal: Siempre tengo prisa pero, bueno, todavía puedo manejar un montón de cosas que pueden ser útiles. Todavía culpo a la falta común de recursos para resolver grandes problemas, algunos de ellos han estado sin resolver durante años. Pero también culpo a la falta de soporte técnico en algunos aspectos vitales de nuestros deberes. Por otro lado, trabajando en el caso de abuso de wp0 me puse en contacto con muchas comunidades increíblemente abiertas a cooperar con nosotros. Estos esfuerzos para cooperar son muy valiosos para ser desperdiciados al abordar problemas que pueden abordarse de manera efectiva de una manera técnica.
русский:
  • Языки:
  • Личная информация: translation needed
Deutsch:
  • Sprachen:
  • Informationen zur Person: translation needed
Nederlands:
  • Taalvaardigheid:
  • Persoonlijke informatie: translation needed
বাংলা:
  • ভাষা:
  • ব্যক্তিগত তথ্যাদি: translation needed

Comments about Vituzzu edit

Most VPN IP's are disabled by you. I think a reason enough to answer the messages. But Hakan confirmed your busyness with this message.--Kingbjelica (talk) 13:40, 11 February 2018 (UTC)[reply]
I try, but sometimes it's hard to guarantee. I started working on a template to be shown/linked for such blocks. --Vituzzu (talk) 20:26, 11 February 2018 (UTC)[reply]
Discussion about this vote follows.
  • @MBq: actually the two blocks you're referring to are perfectly legit, I suspect the users (who was being already helped by fellow stewards) you meant to help is forgetting to say they're using some VPN or, even worse, they are not aware of some malware on their PC. I don't like spending much time in finding potential or proven open proxies but is something which must be done in order to address stuffs like this. --Vituzzu (talk) 11:36, 18 February 2018 (UTC)[reply]
I understand you're tediously fighting global vandalism, and I certainly do appreciate your commitment. Alas, I've seen at least three complaints of guileless de.wp users being affected by your range blocks: [1], [2],[3] (german, sorry). I believe there might be an unknown number of other users who don't know where and how to complain, and simply stop contributing. - Also, I consider your standard blocking reason "leaky colon" inappropiate. Greetings, --MBq (talk) 12:13, 18 February 2018 (UTC)[reply]
@MBq: mediawiki interface makes it easy to reach me even by email (as you can see my email is publicly listed at my userpage). These three cases cannot be compared: one was an user editing from a VPS: users consiously editing from VPS or VPN can perfectly understand the situation they are caught into. Setting up a private VPS is a non-trivial action. What can be really troublesome are two kind of circumstances: users with a weird network configuration (e.g. people editing from some "hyperlan" provider or some offices) and users with some malware on their own PCs. Ringing a bell to the latter is not that bad, honestly they should be more worried of someone stealing their credit cards rather than my blocks. For people with "weird" network configuration we all try to do our best to address their problems, though mediawiki doesn't help us. Finally the block reason is not leaky colon but leaky colo. Colo is a common abbreviation for "colocation service/facility/provider", though a couple of years ago I was pointed out this jargoon can sound obscure so I'm currently using "hosting service/provider with open proxies" and similar things. --Vituzzu (talk) 13:12, 18 February 2018 (UTC)[reply]
colo/n: my apologies, didn‘t know that, thank you for clearing it up. As to the network oddities: true. And Mediawiki doesn’t faciliate things: true as well. Nevertheless I‘d like to maintain my opinion that you’ve induced too much collateral blockings. Perhaps you could use shorter blocks and smaller ranges. —MBq (talk) 16:13, 18 February 2018 (UTC)[reply]
@MBq: I don't want to change your opinion I just found something truly imprecise worth clarifying. Lengths are chosen to be less than the time the cause of a block is supposed to last: colocation facility network assignments almost never change, while botnets over residential xDSL connections are blocked for some weeks. It must be clear there's almost no possibility for an unaware user to be able to reach Wikipedia only from one of these blocked ranges, still they can edit meta. Finally the ranges are chosen via a similar criterion: blocking a range which has a coherent assignment: for example if an ISP offers transit, housing and residential access only the second network will be blocked, while the first one may be blocked on a case by case basis, but the first two networks will be blocked together. We found OVH mixes the latter two kinds of services so we're currently avoid blocking OVH, though this creates lots of extra spam attacks. Apart from open proxies collections (lists) handling these stuffs is not cheap in terms of "studying" the best solution, notwithstanding this I try to carefully consider any rangeblock I issue. --Vituzzu (talk) 18:30, 18 February 2018 (UTC)[reply]
“I try to carefully consider...“ - that’s all I‘m asking for. Thanks again for considering my case and for the given insights in your work. Objection withdrawn —MBq (talk) 19:53, 19 February 2018 (UTC)[reply]