Live data from Hacker News

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

phabricator.wikimedia.org

51–60 of 105 posts

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

#51

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…

Are you not tempted to just block the requests from these devices, and let the manufacturer take the loss? I imagine serving all those requests is costing real money.

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

#52

Earlier quoted context omitted.

Wikimedia is simply trying to be polite and not to publicly shame the company.

In addition to that, one of the culprits here is a widespread sample code that was carelessly copied to a popular app. Shaming does penalize the other culprit but not that one.

Surely the code sample is not to blame here? Or do you truly think the author of the sample is also deserving of being called a "culprit"?

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

#53
post #51

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…

Are you not tempted to just block the requests from these devices, and let the manufacturer take the loss? I imagine serving all those requests is costing real money.

It's not a TOS violation. It did cause us some ops pain at one point (they were getting hit with > 50,000rps concentrated in certain locations). But one of the reasons Cloudflare can operate our service is we have 3.2 million customers who are doing all sorts of stuff. We get so much stronger from that great variety of traffic.

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

#54
post #41
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.…

Certificate pinning has made this a pain in the arse.

You can only pin your own certificate, not someone else’s. In this case you probably don’t even need SSL proxying to pin down the culprit, as I dare say not many apps connect to wikimedia on startup. You do need SSL proxying to be sure though.

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

#55
post #54
post #41

Earlier quoted context omitted.

Certificate pinning has made this a pain in the arse.

You can only pin your own certificate, not someone else’s. In this case you probably don’t even need SSL proxying to pin down the culprit, as I dare say not many apps connect to wikimedia on startup. You do need SSL proxying to be sure though.

The app may not load at all with mitmproxy if it has pinned its server cert though.

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

#56
post #50

Earlier quoted context omitted.

Evidently the download has been specially crafted and surreptitiously emplaced to globally disseminate a steganographically embedded key that decrypts tailored malware aimed at disrupting the [REDACTED] nuclear weapons programme and for which the app is a weaponised delivery sabot distributed and marketed as part of the same covert operation. What I'm trying to say is, the image is a plant

> What I'm trying to say is [...] Since you seem to be responding to me, how does anything you wrote relate to anything I wrote?

It's usually not a good idea to explain a joke, and I'm not the GP so I'm not sure that's what they meant, but "plant" has multiple meanings, and I suspect they are referring to meanings 3 to 5 from this list: https://www.oxfordlearnersdictionaries.com/definition/americ... . Basically, you were asking for some kind of elaborate meaning to a random image downloaded by a random app, and they provided an elaborate conspiracy theory to match your question...

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

#57
post #52

Earlier quoted context omitted.

In addition to that, one of the culprits here is a widespread sample code that was carelessly copied to a popular app. Shaming does penalize the other culprit but not that one.

Surely the code sample is not to blame here? Or do you truly think the author of the sample is also deserving of being called a "culprit"?

Just to be clear, I don't think every author using this image for their sample code is to blame. I'm specifically looking for someone using the public Wikimedia CDN for speed tests [1] and I think that someone is probably the sample code author.

[1] https://news.ycombinator.com/item?id=26073450 has located the actual app and intended purpose, for your information.

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

#58

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…

This is similar to how Qualcomm's DNS servers got knocked off the air. An OEM shipped an update which would query a development TURN server we were running - once per connection, over millions of devices. It was a crazy day.

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

#59
post #55
post #54

Earlier quoted context omitted.

You can only pin your own certificate, not someone else’s. In this case you probably don’t even need SSL proxying to pin down the culprit, as I dare say not many apps connect to wikimedia on startup. You do need SSL proxying to be sure though.

The app may not load at all with mitmproxy if it has pinned its server cert though.

No, you can selectively decrypt HTTPS requests for only some domains, and act as passthrough for others.

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

#60
post #56
post #50

Earlier quoted context omitted.

> What I'm trying to say is [...] Since you seem to be responding to me, how does anything you wrote relate to anything I wrote?

It's usually not a good idea to explain a joke, and I'm not the GP so I'm not sure that's what they meant, but "plant" has multiple meanings, and I suspect they are referring to meanings 3 to 5 from this list: https://www.oxfordlearnersdictionaries.com/definition/americ... . Basically, you were asking for some kind of elaborate meaning to a random image downloaded by a random app, and they provided an elaborate consp…

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 begin with.

> Basically, you were asking for some kind of elaborate meaning to a random image downloaded by a random app [...]

Basically, since they already traced the culprit with a lot of effort (as opposed to just blocking the request URL/UA string pair, which was also an option), the logical ultimate step to conclude their investigation should be to see what the code does, especially considering it's trivial to do so.

While I would not expect to discover any "elaborate meaning" behind it, and never claimed anything like that, I certainly think it would be prudent to check what was going on if I had to decide what to do about it next. For example, it could have been intended as some proxy/filtering/DPI check. I've also seen similar stuff before incorporated into some custom Android builds to generate fake ad traffic.

It really beggars belief that on a website called _Hacker_ News it's necessary to explain why sometimes it's worth it to be curious to people who themselves were curious enough to read this story and the associated comments but then halfway through decided their curiosity was satisfied and thus nobody else should be asking any more questions either (to be clear, I'm referring to the parent commenter here).

Post reply on HN