Live data from Hacker News

Wikimedia narrows down the app sendin 90M requests to a pic of flower

phabricator.wikimedia.org

71–80 of 105 posts

Re: Wikimedia narrows down the app sendin 90M requests to a pic of flower

#71
post #14

> it is a popular chat/social media mobile app used in India Indians of Hacker News, what are the likely candidates?

Considering that this seems to have been code accidentally left in while copy pasting from a tutorial, it's very hard to say, without doing the exact same investigation the Wikimedia team did. There are a lot of apps that have launched in India around that time frame with huge numbers of users thanks to nationalistic rhetoric. They are terrible apps, but they are made in India terrible apps, and that apparently is en…

To be fair, a nation has to make lots of terrible apps first, before they can make mediocre apps, and then good apps. The logic of wanting homegrown apps could still be correct, even though there is a painful period of terrible apps.

Now, what the U.S. excuse is for its terrible apps, I'm not sure...

Re: Wikimedia narrows down the app sendin 90M requests to a pic of flower

#72

Some time we'll get round to writing this up but there's a small customer of Cloudflare that gets a very high HTTP requests per second rate. It's a simple service (bit like a "what's my IP address" but not that) and it turns out that a quite popular hardware device hard-coded requests to this service and doesn't appear to cache the results and so it asks over and over and over again for the same information. We've co…

Could you be more explicit on the nature of the service? I’d like to explore mechanisms for tests that detect IoT devices that misbehave this way (and other ways as well). Your anecdote sounds interesting. Is it unrelated to time servers? Unrelated to internet connectivity tests?

One day we'll write this up. It is not time or connectivity.

Re: Wikimedia narrows down the app sendin 90M requests to a pic of flower

#74
post #23

> To narrow down the app, we decided to observe connections to the image from clients (phones) to our servers. We did this by opening the popular apps one-by-one and noting down the time. After doing this for all the apps, we then ran this query in Hive: SELECT * FROM wmf.webrequest WHERE year=2021 AND month=2 AND day=9 AND parse_media_file_url(uri_path).base_name='/wikipedia/commons/1/16/AsterNovi-belgii-flower-1mb.…

"way easier" depends on what you are familiar with.

If you are familiar with "querying the entirety of wikimedia server logs" and do it all the time (the word "entirety" makes it seem like a big deal, but they clearly have tools meant for this that they use all the time)... and have never learned to use "mitmproxy/Charles etc" before....

It sounds like the "querying the entirety of the server logs" for this task probably took them tens of minutes at most. It would probably take me at least an hour or two to learn how to use "mitmproxy/Charles etc".

So "way easier"?

If you have to do this sort thing all the time, it might be useful to install and learn how to use "mitmproxy/Charles etc", why not? Certainly worth considering. But if the tools you have are working for you...

I mean, what they did seems like it worked to get them the answer and was pretty efficient, using the toolset they use all the time for dealing with wikimedia ops... Seems like some good detective work to me. I get the desire to point out other tools that would be well-suited for this kind of task, but why the need to point it out as if they did something wrong or not "way easier"? Sounds like what they did was pretty easy for them, and they didn't need to learn new tools to make it "way easier".

I enjoyed hearing about how they tracked this down, and found it useful. Pointing out how they didn't use the "right" tools just makes it less likely people will be willing to share their processes.

Re: Wikimedia narrows down the app sendin 90M requests to a pic of flower

#76
post #60

Earlier quoted context omitted.

Thanks, I appreciate your effort but there really isn't any need to explain this to me. I understood the parent comment this way too (i.e. as a snide remark trying way too hard to be funny in the worst possible, low effort, Reddit kind of way). It's just that since it's rare to see this kind of response here, I was wondering if the author was trying to make any finer point, although admittedly that was unlikely to be…

Heaven forbid someone make a joke on the internet and not take your frustrations as seriously as you seem to take yourself. To address your frustration at the analysis stopping there: What do you expect someone who is likely more versed in web dev and their unique distributed systems to do? Do you expect them to have the expertise to decompile an app from a third party, an app popular enough to cause this much traffi…

> Heaven forbid someone make a joke on the internet

Jokes are funny.

https://news.ycombinator.com/item?id=7609289

> I agree with what people have already said, but I think there's one more point to add: people usually over-estimate how funny their own comments are. We have a tendency to think, "This idea of mine is hilarious! And different! Surely this witticism is the exception." And we are usually wrong. When you have N people all doing that, there's a lot of noise.

> I try to gently point this out to people who complain when their attempt at humor has been downvoted by the community. It's not that we don't like humor. We just don't like banal attempts at humor, which becomes noise. Or, put in a less charitable fashion, "You're not as funny as you think you are."

Re: Wikimedia narrows down the app sendin 90M requests to a pic of flower

#77
post #73

The most impressive thing about this is that the offending app doesn't even display the image, it was some copypasta code the app developers apparently didn't even understand.

Welcome to the Internet. Here we welcome amateurs and it shows. Or not, like in this case.

Re: Wikimedia narrows down the app sendin 90M requests to a pic of flower

#78
post #73

The most impressive thing about this is that the offending app doesn't even display the image, it was some copypasta code the app developers apparently didn't even understand.

Don’t know why you would go with didn’t understand rather than didn’t care. I thought the prevailing theory was that it was used for measuring internet speeds.

Re: Wikimedia narrows down the app sendin 90M requests to a pic of flower

#79

> [...] We will thus hold back the banning of the url for now, awaiting for confirmation of the desired effect to reduce the potential harmful impact on the application users. Given how much "sample code" we found around the internet using that url, it might still be a good idea to merge the patch later just to prevent this from happening again. Looks like a case that the developers carelessly copied and pasted some…

> Resorting to Twitter for support is increasingly common.

Always maintain some out of band support system. If that's email, so be it.

If there's business owners watching this, please do not make Twitter (or any other social media) your primary point of contact for support or abuse. I stay far away from Twitter such that I don't have an account and can't even see a single tweet without jumping through some hoops. I've learned via posting here that I'm not alone in this and that this trend will likely grow as time goes on.

Re: Wikimedia narrows down the app sendin 90M requests to a pic of flower

#80
post #73

The most impressive thing about this is that the offending app doesn't even display the image, it was some copypasta code the app developers apparently didn't even understand.

the hard part about this, if it were not wikimedia but some individual person's server, is that the traditional method of using something like an apache rewrite rule to replace the jpg/png with goatse wouldn't work, because the image isn't even being displayed.
Post reply on HN