Comment 3 for bug 1592276

After doing a bit of researching into timing side channel attacks, I've learned that adding a random sleep() doesn't actually add much security. An attacker can just run multiple requests and average them out, and see which ones take longer on average.

More secure is to make your app delay its response for a pre-set amount of time, by making the request and then waiting out the rest of the pre-set delay. This can either be done with what's called a "WCET" (worst case execution time), i.e. pick a value that will be longer than a successful request; or it can be an unpredictable deterministic value, i.e. hash the input to an integer, and use that integer as your delay.

In testing, I found there was a dead giveaway when I found a valid DNS entry with a bad port number -- the block would take the full CURL timeout delay of 15 seconds to come back. So unfortunately, the only way to prevent information from leaking via timing, is to make sure that every unsuccessful request delays for 15 seconds before coming back. The good news is that at least this won't negatively impact people who enter a *correct* RSS URL. But it'll be annoying if you enter a URL with a typo.