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

201–210 of 320 posts

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

#201

Post by ivan_gammel »

beachy wrote: post #146
blauditore wrote: post #137

Earlier quoted context omitted.

> 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…

I've never heard anyone in my life say they could rebuild MS office in a weekend. What, in your opinion, would be the work needed to go from a 100k monthly active user site to a wikipedia scale site - that would be comparable to rebuilding MS office?

That seems indeed comparable given the scope and functionality of Wikimedia products.

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

#202

Post by WhitneyLand »

braythwayt wrote: post #50
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.

Please be careful of logical tautologies: "It all scales in all directions with a properly thought through architecture" sounds dangerously like, "Programming isn't that hard if you just do it right."

>>"Programming isn't that hard if you just do it right."

Is this like saying, programming isn't hard if you choose easy enough problems to solve? Or should we ask for a link to see a demo of an AGI implementation?

I guess math is not hard either if you're "doing is right", as long as it's all arithmetic...

>>That's not a tautology.

I would agree tautology is not the best description, probably fallacy would do fine.

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

#203

Post by MaxBarraclough »

inimino wrote: post #107
braythwayt wrote: post #50

Earlier quoted context omitted.

Please be careful of logical tautologies: "It all scales in all directions with a properly thought through architecture" sounds dangerously like, "Programming isn't that hard if you just do it right."

> Programming isn't that hard if you just do it right. That's not a tautology. In fact, it's actually worth pointing out, especially to junior engineers who get frustrated by how hard everything is, that it actually doesn't need to be that hard if you, well, do it right. Obviously that's not productive feedback without actually helping them be better, but it's far from a tautology. For anyone wondering, a tautology i…

> That's not a tautology. In fact, it's actually worth pointing out, especially to junior engineers who get frustrated by how hard everything is, that it actually doesn't need to be that hard if you, well, do it right

But this boils down to If you build systems using a high level of skill and foresight, it's easy to do.

This is of course not a tautology, but a contradiction. I agree that inexperienced developers can, as it were, 'make life hard for themselves', but that's (trivially) due to their inexperience. I don't think there's a silver bullet for inexperience.

Over-engineering is bad, as is under-engineering. Fuzzy principles like 'YAGNI' can't be applied without skilled discernment, which means experience.

> Programming is hard, but we make it much harder than it has to be by doing it spectacularly wrong in many ways, both individually and collectively.

I think I agree with this, but it depends on specifics. What sorts of things are you thinking of?

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

#204

Post by patsplat »

DuskStar wrote: post #141
patsplat wrote: post #80

Earlier quoted context omitted.

The proportion of read/write may skew towards reads, but Wikipedia still is an application where any user can create state visible to all other users. It's not as simple as this comment makes it out to be.

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

First off, keep in mind that even scaling a broadcast publication can be complex. Sure one can bolt on fastly or s3 but cache invalidation is never a simple problem.

Next "power users" as others put it are not a single set of editors. It's more of a social network with multiple levels of trust. The idea of a wiki is that all users have write access, even if those changes are moderated to have different levels of latency.

Of course there are ways to engineer the system, but at that point one is, well, engineering a system. And WMF is doing so on a shoestring compared to other comparable levels of traffic.

Is WMF creating new paradigms of computing? Probably not. But they are doing a good job, IMHO.

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

#205

Post by Metus »

Nemo_bis wrote: post #171
Metus wrote: post #24

Earlier quoted context omitted.

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.

Thank you for the answer. So especially for personal use I am better off hoarding the ZIM version, especially considering there is the dedicated Kiwix reader, while I am not aware of a similar tool for the XML dumps.

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

#206

Post by allard »

sannee wrote: post #160
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.

Wikipedia is blocked in China. It's politically undesirable for 1/8 of the human population...

Because all of them don't want it?

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

#207

Post by rocqua »

dangxiaopin wrote: post #139
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.

There's always something "undesirable" for someone in a big crowdsourced website.

The cloudfare 8chan action was based on a direct link with multiple actual mass-shootings. Moreover, as they took the decision they went to great pains to explain this was an exceptional case.

Going from that to 'undesired political speech will be censored' requires more of a slippery cliff than a slippery slope.

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

#208

Post by rocqua »

MaxBarraclough wrote: post #203
inimino wrote: post #107

Earlier quoted context omitted.

> Programming isn't that hard if you just do it right. That's not a tautology. In fact, it's actually worth pointing out, especially to junior engineers who get frustrated by how hard everything is, that it actually doesn't need to be that hard if you, well, do it right. Obviously that's not productive feedback without actually helping them be better, but it's far from a tautology. For anyone wondering, a tautology i…

> That's not a tautology. In fact, it's actually worth pointing out, especially to junior engineers who get frustrated by how hard everything is, that it actually doesn't need to be that hard if you, well, do it right But this boils down to If you build systems using a high level of skill and foresight, it's easy to do . This is of course not a tautology, but a contradiction. I agree that inexperienced developers can…

> If you build systems using a high level of skill and foresight, it's easy to do.

The point being made here is not necessarily a flippant 'git gud'. Instead, it is a statement that problems are tractable, and that getting some things right up-front can have good pay-offs down the road.

In other words, don't give up and try to figure out what is good and bad practice.

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

#209

Post by aftbit »

dangxiaopin wrote: post #148
lkoolma wrote: post #144

Earlier quoted context omitted.

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…

Any serious mitigation solution must be BGP based, not proxy. Besides its technical merits and convenience, it also minimizes the risk of a benevolent controller (e.g. Matthew Prince of Cloudflare) ruining your company, because it becomes your upstream provider only during the attacks. Otherwise the GRE tunnels are not in use. The IP addresses are still yours always. We used Verisign for mitigation of a 44Gbps volume…

That's your requirement, but it might not be Wikipedia's requirement. Ownership of IPs is really a technical detail invisible to most people; ownership of eyeballs by way of the domain name and top Google result is probably more important. Cloudflare doesn't impact that ownership other than being able to temporarily take you offline if they choose to terminate your site.

Still, large proxy-based CDNs do have the ability to completely bypass all the same-origin protections in the browser. Even if they are angels and don't abuse this trust for identity theft and surveillance, it makes them a juicy target for bad actors, state sponsored and otherwise.

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

#210

Post by aceofspades19 »

OBLIQUE_PILLAR wrote: post #188
dangxiaopin wrote: post #148

Earlier quoted context omitted.

Any serious mitigation solution must be BGP based, not proxy. Besides its technical merits and convenience, it also minimizes the risk of a benevolent controller (e.g. Matthew Prince of Cloudflare) ruining your company, because it becomes your upstream provider only during the attacks. Otherwise the GRE tunnels are not in use. The IP addresses are still yours always. We used Verisign for mitigation of a 44Gbps volume…

You appear to be extremely mad Cloudflare stopped proxying a website that encouraged large gun massacres.

How did 8chan "encourage" large gun massacres exactly? By allowing users to post content?
Post reply on HN