Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious attack on Wikipedia – what we know and what we’re doing

wikimediafoundation.org

Post reply on HN
Print view View original

171–180 of 320 posts

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#171

Post by Nemo_bis »

Metus wrote: post #24
jedieaston wrote: post #12

Remember: there are BitTorrent links that the Wikimedia Foundation gives out of SQL dumps of Wikipedia and the other projects. You can have a copy in case this happens in your country: https://en.wikipedia.org/wiki/Wikipedia:Database_download#Wh... Also, the Kiwix project has a hotspot project that allows you to host ZIM files (dumps of Wikipedia and other CC licensed content, like TED talks and StackOverflow) on a R…

Assuming that all formats contain the exact same data, i.e. they were generated at the exact same time, which is the (1) most useful for offline viewing (2) most future proof for archival and backup? Is there another, more viable/useful format?

The XML dumps are the most compact and sustainable format in the mid term (let's say decades). https://meta.wikimedia.org/wiki/Mirroring_Wikimedia_project_...

ZIM might be able to survive longer (centuries?) as probably the future will still need some HTML parser, while wikitext parsers or PHP might be long dead, who knows.

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#172

Post by [deleted] »

lkoolma wrote: post #144
dangxiaopin wrote: post #120

Earlier quoted context omitted.

It looks like a volumetric attack from this tweet. Wikipedia needs to use Verisign BGP mitigation. They create GRE tunnels to your routers and are capable of handling 2Tbps. During an attack, you make a BGP announcement and the traffic goes via Verisign scrubbing/tunnels. No application changes are required, no Matthew Prince selectively and benevolently enforcing CF neutrality. It's used by large banks.

After working with a few large corporations and their DDoS protection solutions, I did not have a good experience with Verisign, and they were not able to handle attacks or get things working. However, I have great experiences with Akamai and Cloudflare. I trust the people at Wikimedia will choose wisely. I would I have learned that Verisign has one of the worst BGP mitigation/scraping solutions out there. There are…

[deleted]

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#173

Post by alexis_fr »

innocenat wrote: post #145
DuskStar wrote: post #141

Earlier 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

It must be immediate, because Wikimedia can detect edit conflict (when someone update the article you are in the middle of editing)

It must be immediate for logged-in users, but not others. It’s an excellent thing that Wikipedia doesn’t nudge people to log in all the time, and I susped 95% of users are not logged in.

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#174

Post by Nemo_bis »

adventured wrote: post #110
atdt wrote: post #85

Earlier quoted context omitted.

Wikipedia has a huge impact in people's lives, particularly in non-English languages, and there's so much work to do, and so much of it feels urgent and necessary. I really responded to that, and I wasn't careful, and burnt myself out. (This was not the fault of the org; Wikimedia is largely a do-ocracy, and if you're intent on working through the small hours of the night, there is very little anyone can do to stop y…

What kind of role were you in at Wikimedia if you don't mind answering?

He was all over the place! It's all public under the same username so I hope he forgives me spoilering it: https://www.mediawiki.org/?search=Ori+livneh, https://gerrit.wikimedia.org/r/#/q/owner:Ori.livneh .

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#175

Post by bitwize »

wwright wrote: post #157
nine_k wrote: post #138

Earlier 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.”

It's not just supporting. Taking a neutral stance on censoring these things, or not being adequately proactive on hate speech, is now seen as condoning. You either censor your user base, or upstream will censor you. Gone are the days of "The net interprets censorship as damage and routes around it." The new policy is "The net interprets wrongthink as noise and filters it out."

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#177

Post by nullc »

dangxiaopin wrote: post #120
judge2020 wrote: post #6

Someone claimed the attack on twitter with some details (DDoS) - and proved it later by stopping the attack for x minutes then restarting it at a specific time. https://twitter.com/fs0c131y/status/1170093562878472194?s=20 - the attacker also went on to DDoS the twitch ingest servers (not twitch.tv itself) knocking some big streamers offline.

It looks like a volumetric attack from this tweet. Wikipedia needs to use Verisign BGP mitigation. They create GRE tunnels to your routers and are capable of handling 2Tbps. During an attack, you make a BGP announcement and the traffic goes via Verisign scrubbing/tunnels. No application changes are required, no Matthew Prince selectively and benevolently enforcing CF neutrality. It's used by large banks.

> It looks like a volumetric attack from this tweet. Wikipedia needs to use Verisign BGP mitigation. They create GRE tunnels to your routers and are capable of handling 2Tbps.

Great way for a state actor to intercept your traffic. little bit of volumetric dos and the target themselves responds by tunning through your partner(s).

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#179

Post by nickpsecurity »

blauditore wrote: post #137
chillydawg wrote: post #47

Earlier quoted context omitted.

It's because they're just serving a big site, not running the world's most sophisticated surveillance and ad serving machine. Serving giant websites isn't all that hard if you're just spewing out SQL queries into html templates. It all scales in all directions with a properly thought through architecture.

> Serving giant websites isn't all that hard if you're just spewing out SQL queries into html templates. It all scales in all directions with a properly thought through architecture. No. 1. Your comment makes it sound like Wikipedia is just, or mostly, serving read-only content, which is far from true. Yes, static read-only content is significantly easier to serve than dynamic, editable one, but Wikipedia is the latt…

Your countering a point they didn't make. SQL to HTML templates indicated dynamic site, not static. From there, they describe surveillance and ad networks that both increase the browser workload and make it rely on 3rd-party dependencies.

I thought it was a good, but snarky, point. Especially given my browsing sped up after I installed extensions that turn all that crap off.

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#180

Post by Nemo_bis »

woadwarrior01 wrote: post #153
input_sh wrote: post #150

Earlier 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.

That could be true, but do you have some numbers? Wikimedia wikis are in the order of a few hundreds edits per minute, around a thousand and sometimes more. https://tools.wmflabs.org/wmcounter/ https://wikipulse.herokuapp.com/
Post reply on HN