Live data from Hacker News

Wikipedia was in read-only mode following mass admin account compromise

wikimediastatus.net

381–390 of 405 posts

Re: Wikipedia was in read-only mode following mass admin account compromise

#381

They have no incentive to improve the site, because they’re a for-profit entity. Despite the constant screeching for donations, the entire site is owned by a company with shareholders. All the “donations” go to them. They already met their funding needs for the next century a long time ago, this is all profit.

This is total horseshit.

/me wonders if you're a bad actor or just delusional

Re: Wikipedia was in read-only mode following mass admin account compromise

#382

Earlier quoted context omitted.

I was able to run some stats at scale on this and people who make mistakes are more likely to make more mistakes, not less. Essentially sampling from a distribution of a propensity for mistakes and this dominated any sign of learning from mistakes. Someone who repeatedly makes mistakes is not repeatedly learning, they are accident prone.

Can you elaborate? What scale? What kind of mistakes? This sounds quite interesting.

A decade of data from many hundreds of people, help desk type roll where all communication was kept, mostly chat logs and emails. Machine learning with manual validation. The goal was to put a dollar figure on mistakes made since the customers were much more likely to quit and never come back if it was our fault, but also many customers are nothing but a constant pain in the ass so it was important to distinguish who was right whenever there was a conflict.

Mistakes made per call, like many things, were on a Pareto distribution, so 90% of the mistakes are made by 10% of the people. Identifying and firing those 10% made a huge difference. Some of the ‘mistakes’ were actually a result of corruption and they had management backing as management was enriching themselves at the cost of the company (a pretty common problem) so the initiative was killed after the first round.

Re: Wikipedia was in read-only mode following mass admin account compromise

#383

Earlier quoted context omitted.

I was able to run some stats at scale on this and people who make mistakes are more likely to make more mistakes, not less. Essentially sampling from a distribution of a propensity for mistakes and this dominated any sign of learning from mistakes. Someone who repeatedly makes mistakes is not repeatedly learning, they are accident prone.

My impression of mistakes was that they were an indicator of someone who was doing a lot of work. They're not necessarily making mistakes at a higher rate per unit of work, they just do more of both per unit of time. From that perspective, it makes sense that the people who made the most mistakes in the past will also make the most mistakes in the future, but it's only because the people who did the most work in the…

In this case it was trivial to normalize for work done.

It’s very human to want to be forgiving of mistakes, after all who has not made any mistakes, but there are different classes of mistakes made by all different types of people. If you make a mistake you are the same type of person, but if you are pulling from a distribution by sampling by those who have made mistakes you are biasing your sample in favor of those prone to making such mistakes. In my experience any effect of learning is much smaller than this initial bias.

Re: Wikipedia was in read-only mode following mass admin account compromise

#384
post #125

See the public phab ticket: https://phabricator.wikimedia.org/T419143 In short, a Wikimedia Foundation account was doing some sort of test which involved loading a large number of user scripts. They decided to just start loading random user scripts, instead of creating some just for this test. The user who ran this test is a Staff Security Engineer at WMF, and naturally they decided to do this test under their highly…

...wow.

Re: Wikipedia was in read-only mode following mass admin account compromise

#386
post #372

Earlier quoted context omitted.

> Haven't we hit that point already with bad faith (and potentially government-run) coordinated editing […] campaigns, Yes, this is a real phenomenon. See, for instance, https://en.wikipedia.org/wiki/Timeline_of_Wikipedia%E2%80%93... : the examples from 2006 are funny, and the article's subject matter just gets sadder and sadder as the chronology goes on. > and voting campaigns I'm not sure what you mean by this. Wik…

That Wikipedia is not a democracy doesn't mean there are no votes and no elections. https://en.wikipedia.org/wiki/Wikipedia:Administrator_electi...

That's a relatively recent process: there have only been 3 such elections ever. They have measures in place to try to curb abuse of the process, and it cannot really be used to introduce bias (since an administrator exhibiting bias would leave a public trail of evidence attesting to that bias). That said, thanks for letting me know about it.

Re: Wikipedia was in read-only mode following mass admin account compromise

#388

Earlier quoted context omitted.

That's from the prequel, A Deepness in the Sky . (Which is also excellent.)

Deepness in the Sky is probably the first Sci Fi alien I read who didn't feel like a human wearing an alien suit. Fantasy sometimes does this better but usually with specific tropes.

If you liked that and you haven't read it yet, give "Dragon's Egg" by Robert L. Forward a read.

Re: Wikipedia was in read-only mode following mass admin account compromise

#389

Earlier quoted context omitted.

There doesn’t seem to be an ulterior motive beyond “Muahaha, see the trouble I can cause!”

A classical virus, from the good old days. None of this botnet/bitcoin mining in the background nonsense.

On the Atari ST we had a boot sector virus that inverted the mouse Y-axis after some random time.

So annoying.

Re: Wikipedia was in read-only mode following mass admin account compromise

#390

Earlier quoted context omitted.

Selecting the wrong environment in your test setup by mistake? I refuse to believe that someone on the security team intentionally tested random user scripts in production on purpose.

Once you get big enough… there comes a point where you need to run some code and learn what happens when 100 million people hitting it at once looks like. At that scale, “1 in a million class bugs/race conditions” literally happen every day. You can’t do that on every PR, so you ship it and prepare to roll back if anything even starts to look fishy. Maybe even just roll it out gradually. At least, that’s how it worke…

Yes this is a common release practice.

However this is a different situation as we’re talking about running arbitrarily found third-party scripts. I can’t imagine that was ever intended to be done in production.

Fun story, when I worked at Facebook in the earlier days someone accidentally made a change that effectively set the release flags for every single feature to be live on production. That was a day… we had to completely wipe out memcached to stop the broken features and then the database was hammered to all hell.

Post reply on HN