These are the clowns, btw: https://twitter.com/UKDrillas/status/1170221000363061250
Malicious attack on Wikipedia – what we know and what we’re doing
161–170 of 320 posts
Re: Malicious attack on Wikipedia – what we know and what we’re doing
#162Earlier quoted context omitted.
If you are not a political undesirable, it does help, though. I think Wikipedia is fine in this regard, not something to shun of for a big corp.
I think it’s somewhat misleading to refer to those who support genocide and child abuse as simply “political undesirables.”
They are beyond a certain line; some very-very far past it, some just crossed it. It makes them unsupportable by any corporation that aims to look decent.
Re: Malicious attack on Wikipedia – what we know and what we’re doing
#163Earlier quoted context omitted.
If you are not a political undesirable, it does help, though. I think Wikipedia is fine in this regard, not something to shun of for a big corp.
I think it’s somewhat misleading to refer to those who support genocide and child abuse as simply “political undesirables.”
[deleted]
Re: Malicious attack on Wikipedia – what we know and what we’re doing
#164Earlier quoted context omitted.
If you are not a political undesirable, it does help, though. I think Wikipedia is fine in this regard, not something to shun of for a big corp.
Wikipedia is blocked in China. It's politically undesirable for 1/8 of the human population...
Unlike a DDoS attack, this is not a technological problem.
Re: Malicious attack on Wikipedia – what we know and what we’re doing
#165Earlier quoted context omitted.
But how quickly must those writes be reflected in the reads of others? If you can accept a few minutes of latency there, I imagine things would get easier
In order for wikipedia's anyone can edit to work, its really important that when someone makes a bad edit to a popular article that it can be removed immediately. This is important both to get things fixed quickly and to make it less of a juicy target so less people vandalize (no fun to vandalize if it doesnt stay up). I suspect latency in the minutes for cache updates would be unaceptable to wikipedia users
Power users use very different workflows than read-only users. You can serve pages from a 30-minute-old cache to the 99.9% of passive readers and it doesn't hurt that much. Editors use "Recent Changes" to monitor edits, and that's much easier to render in real time because the audience is comparatively minuscule.
Re: Malicious attack on Wikipedia – what we know and what we’re doing
#166Earlier quoted context omitted.
Yeah, but unlike on Reddit, I never see "something went wrong" on Wikipedia. No offense to you nor your team, but to me, as a consumer, reddit's product doesn't appear nowhere near as polished as Wikimedia's projects.
No offense taken, I don’t work on the product side of things there. Also, with the caveat that I don’t know enough about the implementation details of the product at Reddit: I’d argue that Reddit’s workload is more write heavy that Wikipedia’s workload, which makes caching and scaling a bit harder for Reddit, relatively speaking.
OTOH, shouldn't it be easier to scale Reddit horizontally by sharding the subreddits into separate DBs?
Re: Malicious attack on Wikipedia – what we know and what we’re doing
#167Earlier quoted context omitted.
There are exactly zero big box retailers or lobbyists that will abide that.
Big box retailers seem to be able to comply with regulations mandating physical safety. Digital security requirements could be enforced by a similar system.
Because "physical safety regulations" is something that the majority understands, so it's hard to argue against that in public. With digital security, most people lack the mental models to follow the discussion, so it's really easy for lobbyists to tell them flatout lies about how those damn dems are out to take their smart lightbulbs away from them.
Re: Malicious attack on Wikipedia – what we know and what we’re doing
#168Just want to mention, WMF has a very small but elite team of engineers. Amazed they maintain an Alexa top 5 site with many orders of magnitude less engineering staff than Facebook or Reddit. I think they must count ~100 engineers? I can't imagine what such a small team must be going through with a major DDOS - wish them well in their efforts!
If you consider the amount of money they are burning in comparison to 5 years ago, are the results really that impressing? See https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2...
I found this updated version: https://en.wikipedia.org/wiki/User:Guy_Macon/Wikipedia_has_C...
Their expenses have doubled in less than 5 years...
Even if their ratio Expenses / Assets has now decreased compared to 3-5 years ago (but stalls now), it means that their goal of financial independence is still very far away and they still rely heavily on a huge amount of donations.
Re: Malicious attack on Wikipedia – what we know and what we’re doing
#169Earlier quoted context omitted.
I'm liable if my car spontaneously catches fire while parked. Car is just an analogy.
What I'm saying is that it's very simple to inspect a car and make sure it's not going to spontaneously catch fire while parked. You can get a reliable answer in a day from a mechanic. You can't get a reliable answer on whether a computing device is programmed to send malicious packets. There's too much code, most is compiled, there's too many ways to hide it. You can probably gather the smartest people in the world…
> What I'm saying is that it's very simple to inspect a car and make sure it's not going to spontaneously catch fire while parked.
With electric cars on the rise, it's only a matter of time until the equivalent of the Samsung Galaxy Note 7, but for cars.
Re: Malicious attack on Wikipedia – what we know and what we’re doing
#170Earlier quoted context omitted.
Caveat: the last full Kiwix English Wikipedia archive was made in 2018. They could use some help with automating their build process if anyone here has the time.
From a cursory glance at the site and source code, it's really hard to see who/what is involved with building an archive. There's automated builds set up for the Pi image itself.
The last time I checked, it was more a problem of lacking servers with sufficient resources: https://phabricator.wikimedia.org/T124960 https://phabricator.wikimedia.org/T219078
It sure doesn't harm if someone creates their own ZIM files and reports on their results (and/or shares the resulting files).