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

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

phabricator.wikimedia.org

Post reply on HN
Print view View original

81–90 of 105 posts

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

#81

Post by msla »

walrus01 wrote: post #80
yborg wrote: 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.

Even worse: You might be seen as an easy way to Goatse people. Just give the yahoos the URL of an image you're rewriting to be the infamous gape. The traffic would only grow once you came to be known for Goatse as a Service.

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

#82

Post by oefrha »

jrochkind1 wrote: post #74
oefrha wrote: 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 prob…

You added way too many assumptions to a short non-accusatory comment.

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

#85

Post by GekkePrutser »

abetusk wrote: post #20

This reminds me of a Stack Overflow answer that became popular but instead of using 'example.com', they used some other random, but valid, URL that suddenly created a huge spike in traffic for the unsuspecting web page.

This is going to be so much fun when the owner of foo.bar brings their domain online :D

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

#86

Post by stickfigure »

msla wrote: post #81
walrus01 wrote: post #80

Earlier quoted context omitted.

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.

Even worse: You might be seen as an easy way to Goatse people. Just give the yahoos the URL of an image you're rewriting to be the infamous gape. The traffic would only grow once you came to be known for Goatse as a Service.

> Goatse as a Service (YC S21)

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

#87

Post by walrus01 »

stickfigure wrote: post #86
msla wrote: post #81

Earlier quoted context omitted.

Even worse: You might be seen as an easy way to Goatse people. Just give the yahoos the URL of an image you're rewriting to be the infamous gape. The traffic would only grow once you came to be known for Goatse as a Service.

> Goatse as a Service (YC S21)

Implemented via several dozen geographically distributed 1U servers with 10 or 100GbE network interfaces, and anycast DNS. You could do it pretty much the same as anycast DNS recursive resolvers, but all sharing the same hostname, IP and TLS keys.

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

#89

Post by whatatita »

oefrha wrote: 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.…

It looks like it wasn't a big deal to perform the lookup, so I guess it comes down to what the engineer was familiar wit.

It does say later in the post that they used a local proxy to confirm their findings, too. Maybe they wanted to check from both sides, just to be sure.

Post reply on HN