A Startup With a Way to Filter Botnet Traffic Gets Funding
bits.blogs.nytimes.com
bits.blogs.nytimes.com
That isn't how that works. That isn't how any of it works.
Selenium + https://code.google.com/p/flash-selenium/ == Has both.
People who block flash & javascript for security reasons? Also blocks both.
The sheer ease of bypass and the rate of false positives for any sophisticated operator is going to be huge.
Maybe I'm overly skeptical but I don't see this filtering any bot operation that is sophisticated enough to run something like selenium.
EDIT: Folks, I'm aware Selenium is a terrible example but it was the first thing that came to mind.
There are plenty of other headless toolkits that are easier to weaponize. Maybe I didn't want to point that out by linking to them/mentioning them? :|
It was just a random example that was intended to not point in an easily weaponized direction.
I figured it was both common and known in tech circles that Flash/Javascript executing botnets for ads existed and have for year(s):
http://www.spider.io/blog/2013/03/chameleon-botnet/
They were acquired by Google so it isn't just random blog spam:
http://techcrunch.com/2014/02/21/google-acquires-spider-io-t...
But, as others have noted, it's probably been boiled down into something dumb for the layperson, and their algorithms are more complex than you would think from that quote.
Edit: Actually, given their target users, I guess he wouldn't be locked out, just falsely identified as a fake ad consumer.
That said, if I had a botnet I'd just figure out what domains belonged to WhiteOPs and null-route them.
EDIT:
Its apparently stated here: http://www.marketwired.com/press-release/White-Ops-Secures-7...
"White Ops offers the world's first systematic solution for accurately isolating and eliminating bot-infected traffic. By applying the techniques of Side Channel Analysis across thousands of real-time user session variables, White Ops differentiates between a human and machine-driven request -- regardless of the sophistication of the bot programmer and across the full spectrum of impression and click fraud techniques. This approach is vastly more effective than methods generally employed by legacy fraud detection services, which rely largely on historical data and statistical and predictive analysis to detect bot activity. "
That and bots that don't execute javascript would be a problem, yes. Our clients can account for that by comparing their traffic numbers with ours.
(full disclosure: I work at White Ops on the 'botprinting' team)
This is a more descriptive article on this funding round and what White Ops does. The company uses side channel analysis across an array of variables to detect behavioral differences between humans and bots.
Looks like they only report on the percentage of bot users. While that can be useful in the long-run (especially if you're implementing ways to mitigate it), but it seems like it'd be much more useful if you could tell on a per-user or per-session level whether the user was a bot, so you could turn off features like ad-serving or message-sending or whatever.
If an IP isn't allocated by a RIR, it is a "bogon" and usually dropped by your anti-spoof filters at your router.
I've actually been burned by use of that data as a user - the last time I was in Germany for a CCC camp, I needed to log into my bank account. Not trusting the WiFi, I bounced through my VPS to do so. It seemed to work fine, but a few days later the bank froze my account. When I called them they insisted that this activity meant my computer and email had been hacked and I needed to change my email password, virus scan my computer, change my username with the bank and change my password. There was no way for them to mark the use as 'legitimate'.
On the other side of the coin, there are lots of ad fraud bots running through residential ISPs.