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…
Wikimedia narrows down the app sendin 90M requests to a pic of flower
51–60 of 105 posts
Re: Wikimedia narrows down the app sendin 90M requests to a pic of flower
#52Earlier 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.
Re: Wikimedia narrows down the app sendin 90M requests to a pic of flower
#53Some 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
#54> 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.
Re: Wikimedia narrows down the app sendin 90M requests to a pic of flower
#55Earlier 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.
Re: Wikimedia narrows down the app sendin 90M requests to a pic of flower
#56Earlier 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?
Re: Wikimedia narrows down the app sendin 90M requests to a pic of flower
#57Earlier 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"?
[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
#58Some 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…
Re: Wikimedia narrows down the app sendin 90M requests to a pic of flower
#59Earlier 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.
Re: Wikimedia narrows down the app sendin 90M requests to a pic of flower
#60Earlier 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…
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).