Stopping scripters from slamming your website

Question

I've accepted an answer, but sadly, I believe we're stuck with our original worst case scenario: CAPTCHA everyone on purchase attempts of the crap. Short explanation: caching / web farms make it impossible to track hits, and any workaround (sending a non-cached web-beacon, writing to a unified table, etc.) slows the site down worse than the bots would. There is likely some pricey hardware from Cisco or the like that can help at a high level, but it's hard to justify the cost if CAPTCHA-ing everyone is an alternative. I'll attempt a more full explanation later, as well as cleaning this up for future searchers (though others are welcome to try, as it's community wiki).

Situation

This is about the bag o' crap sales on woot.com. I'm the president of Woot Workshop, the subsidiary of Woot that does the design, writes the product descriptions, podcasts, blog posts, and moderates the forums. I work with CSS/HTML and am only barely familiar with other technologies. I work closely with the developers and have talked through all of the answers here (and many other ideas we've had).

Usability is a massive part of my job, and making the site exciting and fun is most of the rest of it. That's where the three goals below derive. CAPTCHA harms usability, and bots steal the fun and excitement out of our crap sales.

Bots are slamming our front page tens of times a second screen scraping (and/or scanning our RSS) for the Random Crap sale. The moment they see that, it triggers a second stage of the program that logs in, clicks I want One, fills out the form, and buys the crap.

Evaluation

lc: On stackoverflow and other sites that use this method, they're almost always dealing with authenticated (logged in) users, because the task being attempted requires that.

On Woot, anonymous (non-logged) users can view our home page. In other words, the slamming bots can be non-authenticated (and essentially non-trackable except by IP address).

So we're back to scanning for IPs, which a) is fairly useless in this age of cloud networking and spambot zombies and b) catches too many innocents given the number of businesses that come from one IP address (not to mention the issues with non-static IP ISPs and potential performance hits to trying to track this).

Oh, and having people call us would be the worst possible scenario. Can we have them call you?

BradC: Ned Batchelder's methods look pretty cool, but they're pretty firmly designed to defeat bots built for a network of sites. Our problem is bots are built specifically to defeat our site. Some of these methods could likely work for a short time until the scripters evolved their bots to ignore the honeypot, screen-scrape for nearby label names instead of form ids, and use a javascript-capable browser control.

 

lc again: "Unless, of course, the hype is part of your marketing scheme." Yes, it definitely is. The surprise of when the item appears, as well as the excitement if you manage to get one is probably as much or more important than the crap you actually end up getting. Anything that eliminates first-come/first-serve is detrimental to the thrill of 'winning' the crap.

 

novatrust: And I, for one, welcome our new bot overlords. We actually do offer RSSfeeds to allow 3rd party apps to scan our site for product info, but not ahead of the main site HTML. If I'm interpreting it right, your solution does help goal 2 (performance issues) by completely sacrificing goal 1, and just resigning the fact that bots will be buying most of the crap. I up-voted your response, because your last paragraph pessimism feels accurate to me. There seems to be no silver bullet here.

The rest of the responses generally rely on IP tracking, which, again, seems to both be useless (with botnets/zombies/cloud networking) and detrimental (catching many innocents who come from same-IP destinations).

Any other approaches / ideas? My developers keep saying "let's just do CAPTCHA" but I'm hoping there's less intrusive methods to all actual humans wanting some of our crap.

Original question

Say you're selling something cheap that has a very high perceived value, and you have a very limited amount. No one knows exactly when you will sell this item. And over a million people regularly come by to see what you're selling.

You end up with scripters and bots attempting to programmatically [a] figure out when you're selling said item, and [b] make sure they're among the first to buy it. This sucks for two reasons:

1. Your site is slammed by non-humans, slowing everything down for everyone.
2. The scripters end up 'winning' the product, causing the regulars to feel cheated.

A seemingly obvious solution is to create some hoops for your users to jump through before placing their order, but there are at least three problems with this:

• The user experience sucks for humans, as they have to decipher CAPTCHA, pick out the cat, or solve a math problem.
• If the perceived benefit is high enough, and the crowd large enough, some group will find their way around any tweak, leading to an arms race. (This is especially true the simpler the tweak is; hidden 'comments' form, re-arranging the form elements, mis-labeling them, hidden 'gotcha' text all will work once and then need to be changed to fight targeting this specific form.)
• Even if the scripters can't 'solve' your tweak it doesn't prevent them from slamming your front page, and then sounding an alarm for the scripter to fill out the order, manually. Given they get the advantage from solving [a], they will likely still win [b] since they'll be the first humans reaching the order page. Additionally, 1. still happens, causing server errors and a decreased performance for everyone.

Another solution is to watch for IPs hitting too often, block them from the firewall, or otherwise prevent them from ordering. This could solve 2. and prevent [b] but the performance hit from scanning for IPs is massive and would likely cause more problems like 1. than the scripters were causing on their own. Additionally, the possibility of cloud networking and spambot zombies makes IP checking fairly useless.

A third idea, forcing the order form to be loaded for some time (say, half a second) would potentially slow the progress of the speedy orders, but again, the scripters would still be the first people in, at any speed not detrimental to actual users.

Goals

1. Sell the item to non-scripting humans.
2. Keep the site running at a speed not slowed by bots.
3. Don't hassle the 'normal' users with any tasks to complete to prove they're human.

Answer 1

It seams that most of the solutions I've read eventually degrade to a move-counter move situation and dont disincentivize people to play by the 'rules of fair play'.

Have you thought of things like purposeful performance throttling/shadow banning? If you are detecting a swarm of hits from a single IP, have your CGI scripts purposely delay in responding - or having them then be ineligible for winning the item?

So If you say set a cookie on the system and you see it hitting you more than X per interval of time, you start delaying the responses more and more. If you see cookie X continue this behavior for some interval of time, you set the dreaded 'Can not win today come back tomorrow flag' and dont tell them - that way, even if they win, they still loose.
If you have several parameters like this that would be easily/randomly tweekable, you could be changing the rules all the time in such a way that it would keep out the bots - but humans wouldnt even notice. Maybe you could have a login have a delay of X seconds - where the delay is depended on that IP addresses history of hits/logins :)

Just a thought or two

Answer 2

My solution would be to make screen-scraping worthless by putting in a roughly 10 minute delay for 'bots and scripts.

Here's how I'd do it:

• Log and identify any repeat hitters.

You don't need to log every IP address on every hit. Only track one out of every 20 hits or so. A repeat offender will still show up in a randomized occassional tracking.

• Keep a cache of your page from about 10-minutes earlier.

• When a repeat-hitter/bot hits your site, give them the 10-minute old cached page.

They won't immediately know they're getting an old site. They'll be able to scrape it, and everything, but they won't win any races anymore, because "real people" will have a 10 minute head-start.

Benefits:

• No hassle or problems for users (like CAPTCHAs).
• Implemented fully on server-side. (no reliance on Javascript/Flash)
• Serving up an older, cached page should be less performance intensive than a live page. You may actually decrease the load on your servers this way!

Drawbacks

• Requires tracking some IP addresses
• Requires keeping and maintaining a cache of older pages.

Answer 3

Take a look at this article by ned Batchelder here. His article is about stopping spambots, but the same techniques could easily apply to your site.

Rather than stopping bots by having people identify themselves, we can stop the bots by making it difficult for them to make a successful post, or by having them inadvertently identify themselves as bots. This removes the burden from people, and leaves the comment form free of visible anti-spam measures.

This technique is how I prevent spambots on this site. It works. The method described here doesn't look at the content at all.

Some other ideas:

• Create an official auto-notify mechanism (RSS feed? Twitter?) that people can subscribe to when your product goes on sale. This reduces the need for people to make scripts.
• Change your obfuscation technique right before a new item goes on sale. So even if the scripters can escalate the arms race, they are always a day behind.

---

EDIT: To be totally clear, Ned's article above describe methods to prevent the automated PURCHASE of items by preventing a BOT from going through the forms to submit an order. His techniques wouldn't be useful for preventing bots from screen-scraping the home page to determine when a Bandoleer of Carrots comes up for sale. I'm not sure preventing THAT is really possible.

With regard to your comments about the effectiveness of Ned's strategies: Yes, he discusses honeypots, but I don't think that's his strongest strategy. His discussion of the SPINNER is the original reason I mentioned his article. Sorry I didn't make that clearer in my original post:

The spinner is a hidden field used for a few things: it hashes together a number of values that prevent tampering and replays, and is used to obscure field names. The spinner is an MD5 hash of:

• The timestamp,
• The client's IP address,
• The entry id of the blog entry being commented on, and
• A secret.

Here is how you could implement that at WOOT.com:

Change the "secret" value that is used as part of the hash each time a new item goes on sale. This means that if someone is going to design a BOT to auto-purchase items, it would only work until the next item comes on sale!!

Even if someone is able to quickly re-build their bot, all the other actual users will have already purchased a BOC, and your problem is solved!

The other strategy he discusses is to change the honeypot technique from time to time (again, change it when a new item goes on sale):

• Use CSS classes (randomized of course) to set the fields or a containing element to display:none.
• Color the fields the same (or very similar to) the background of the page.
• Use positioning to move a field off of the visible area of the page.
• Make an element too small to show the contained honeypot field.
• Leave the fields visible, but use positioning to cover them with an obscuring element.
• Use Javascript to effect any of these changes, requiring a bot to have a full Javascript engine.
• Leave the honeypots displayed like the other fields, but tell people not to enter anything into them.

I guess my overall idea is to CHANGE THE FORM DESIGN when each new item goes on sale. Or at LEAST, change it when a new BOC goes on sale.

Which is what, a couple times/month?

Answer 4

Not a complete fix, but I didn't see it here yet.

Track the "slamming" addresses, and put up a disclaimer saying that BOC/ items will not be shipped to any address that is not following your TOS.

This will have psych impact on some, and others who want to take advantage of your site will have to switch up methods, but you will have negated one avenue for them.

Answer 5

How about using multiple order buttons (four or more). File-name them image1 through image4, three are the same image visually ("don't click here") and one reading "click here".

For each sale, randomly assign the image # for each option. Make them fairly large, so users would not accidentally click the wrong one. Images would be the same file size.
Once an IP clicks a button, any button, they are taken to the appropriate web page (ordering process, or "Oops, you clicked the wrong button") and given a 2-minute timeout from re-accessing the server.

Answer 6

You need to figure a way to make the bots buy stuff that is massively overpriced: 12mm wingnut: $20. See how many bots snap up before the script-writers decide you're gaming them.

Use the profits to buy more servers and pay for bandwidth.

Answer 7

I probably don't understand the problem fully, but this idea occurred to me. Use AJAX to draw and update the dynamic content at a fixed interval while making the full page deliberately slow to load using refresh.

For example, make the whole page take a full 15 seconds to draw the first time it is visited, after which dynamic content is automatically refreshed using AJAX after a set time of, say, 5 seconds. It would be a major disadvantage to do a full page reload. The page may regularly display new information (including ads), but a full page redraw using reload would be considerably slower.

It will be possible for script kiddies to figure out the AJAX query and automate it but, then, it would also be very easy to rate-limit those requests from the same IP. Since there is no typical method for a standard human user to initiate those requests from the browser, it would be obvious that high-rate requests to the AJAX URL from the same IP would be initiated by some form of automated system.

Answer 8

I say expose the price information using an API. This is the unintuitive solution but it does work to give you control over the situation. Add some limitations to the API to make it slightly less functional than the website.

You could do the same for ordering. You could experiment with small changes to the API functionality/performance until you get the desired effect.

There are proxies and botnets to defeat IP checks. There are captcha reading scripts that are extremely good. There are even teams of workers in India who defeat captchas for a small price. Any solution you can come up with can be reasonably defeated. Even Ned Batchelder's solutions can be stepped past by using a WebBrowser control or other simulated browser combined with a botnet or proxy list.

Answer 9

Use hashcash.

Hashcash is a denial-of-service counter measure tool. Its main current use is to help hashcash users avoid losing email due to content based and blacklist based anti-spam systems.

Answer 10

for this purpose i use Cloudflare as it doesn't affect my site but blocks any malicious user with CAPTCHA automatically and gives you more features .

Answer 11

The method Woot uses to combat this issue is changing the game - literally. When they present an extraordinarily desirable item for sale, they make users play a video game in order to order it.

Not only does that successfully combat bots (they can easily make minor changes to the game to avoid automatic players, or even provide a new game for each sale) but it also gives the impression to users of "winning" the desired item while slowing down the ordering process.

It still sells out very quickly, but I think that the solution is good - re-evaluating the problem and changing the parameters led to a successful strategy where strictly technical solutions simply didn't exist.

---

Your entire business model is based on "first come, first served." You can't do what the radio stations did (they no longer make the first caller the winner, they make the 5th or 20th or 13th caller the winner) - it doesn't match your primary feature.

No, there is no way to do this without changing the ordering experience for the real users.

Let's say you implement all these tactics. If I decide that this is important, I'll simply get 100 people to work with me, we'll build software to work on our 100 separate computers, and hit your site 20 times a second (5 seconds between accesses for each user/cookie/account/IP address).

You have two stages:

1. Watching front page
2. Ordering

You can't put a captcha blocking #1 - that's going to lose real customers ("What? I have to solve a captcha each time I want to see the latest woot?!?").

So my little group watches, timed together so we get about 20 checks per second, and whoever sees the change first alerts all the others (automatically), who will load the front page once again, follow the order link, and perform the transaction (which may also happen automatically, unless you implement captcha and change it for every wootoff/boc).

You can put a captcha in front of #2, and while you're loathe to do it, that may be the only way to make sure that even if bots watch the front page, real users are getting the products.

But even with captcha my little band of 100 would still have a significant first mover advantage - and there's no way you can tell that we aren't humans. If you start timing our accesses, we'd just add some jitter. We could randomly select which computer was to refresh so the order of accesses changes constantly - but still looks enough like a human.

First, get rid of the simple bots

You need to have an adaptive firewall that will watch requests and if someone is doing the obvious stupid thing - refreshing more than once a second at the same IP then employ tactics to slow them down (drop packets, send back refused or 500 errors, etc).

This should significantly drop your traffic and alter the tactics the bot users employ.

Second, make the server blazingly fast.

You really don't want to hear this... but...

I think what you need is a fully custom solution from the bottom up.

You don't need to mess with TCP/IP stack, but you may need to develop a very, very, very fast custom server that is purpose built to correlate user connections and react appropriately to various attacks.

Apache, lighthttpd, etc are all great for being flexible, but you run a single purpose website, and you really need to be able to both do more than the current servers are capable of doing (both in handling traffic, and in appropriately combating bots).

By serving a largely static webpage (updates every 30 seconds or so) on a custom server you should not only be able to handle 10x the number of requests and traffic (because the server isn't doing anything other than getting the request, and reading the page from memory into the TCP/IP buffer) but it will also give you access to metrics that might help you slow down bots. For instance, by correlating IP addresses you can simply block more than one connection per second per IP. Humans can't go faster than that, and even people using the same NATed IP address will only infrequently be blocked. You'd want to do a slow block - leave the connection alone for a full second before officially terminating the session. This can feed into a firewall to give longer term blocks to especially egregious offenders.

But the reality is that no matter what you do, there's no way to tell a human apart from a bot when the bot is custom built by a human for a single purpose. The bot is merely a proxy for the human.

Conclusion

At the end of the day, you can't tell a human and a computer apart for watching the front page. You can stop bots at the ordering step, but the bot users still have a first mover advantage, and you still have a huge load to manage.

You can add blocks for the simple bots, which will raise the bar and fewer people with bother with it. That may be enough.

But without changing your basic model, you're out of luck. The best you can do is take care of the simple cases, make the server so fast regular users don't notice, and sell so many items that even if you have a few million bots, as many regular users as want them will get them.

You might consider setting up a honeypot and marking user accounts as bot users, but that will have a huge negative community backlash.

Every time I think of a "well, what about doing this..." I can always counter it with a suitable bot strategy.

Even if you make the front page a captcha to get to the ordering page ("This item's ordering button is blue with pink sparkles, somewhere on this page") the bots will simply open all the links on the page, and use whichever one comes back with an ordering page. That's just no way to win this.

Make the servers fast, put in a reCaptcha (the only one I've found that can't be easily fooled, but it's probably way too slow for your application) on the ordering page, and think about ways to change the model slightly so regular users have as good a chance as the bot users.

-Adam

Answer 12

I'm pretty sure your server already logs all the IPs of incoming requests (most do) - so the data is already there.

Maybe you could:

Just validate the "winner" by verifying that it's IP shows up less than a certain threshold value in the logs (I use "grep | wc -l" to get the count). If it's over your threshold, temporarily block that IP (hour or so?).

Disqualify any "winner" with the same shipping address or payment info as the "last" winner, or that has won within a certain time frame to spread the "winning" around.

The bots won't get 'em all that way.

To annoy the crap out of the scrapers: When the "random crap" item goes up, run the HMTL output for that page through a "code obfuscator" ... which doesn't change the "display" of the page ... just scrambles the code with randomly generated Ids etc.

More insidious:

Increase the price charged for the "won" item based on how many times the winning IP shows up in the logs. Then even if the bots win, so do you. :-)

Answer 13

I have a solution that (probably) isn't listed (as I haven't read through all of the ones here just yet...)

You can track unique users through their browser's User Agent String. Essentially, by checking which information is available 'unique' you'd be able to get enough information to distinguish between different people (even on the same IP address).

Check out this article written by the EFF As well as this site (also by the EFF) that will 'test' your uniques just based on your User Agent from the browser.

For even better uniqueness, you'd be able to do a comparison between the bits of information from the uniqueness AND the ip address to really get the possibilities down to the offenders/bots.

---

also checkout this pdf from EFF

Answer 14

You know, if you published your RSS feed using pubsubhubbub, people wouldn't have to hit your web page over and over again to see the next thing in the Woot-off, they'd just wait for it to show up on their Google Reader.

Answer 15

A rather simple solution is to track the time difference between rendering the forms and getting the response: bots usually have extreme short response times of milliseconds, no user could do that; or extreme long response times of several hours.

There's a django snippet doing it, along with a more detailed description:

Alternative to Captchas (Without Human Interaction)

Answer 16

You are making this way to hard. I will probably kick myself since I just won a BOC from the site today with a bot site, but just put the RANDOM CRAP text in captchas on the site main page. The bots all look for the text "RANDOM CRAP". So you basically just avoid triggering them in the first place. Anyone looking with their eyes will see that it says "Random Crap".

Answer 17

Create a simple ip firewall rule that blacklists the IP-address if you detect more than a max. number of requests coming in per second.

Answer 18

Why dont you just change the name and picture of the BOC every time you offer it? It would become part of the fun of wooting to see the latest iteration of the BOC.

Answer 19

There is probably not a magic silver bullet that will take care of Bots, but a combination of these suggestions may help deter them, and reduce them to a more manageable number.
Please let me know if you need any clarification on any of these suggestions:

• Any images that depict the item should be either always the same image name (such as "current_item.jpg") or should be a random name that changes for each request. The server should know what the current item is and will deliver the appropriate image. This image should also have a random amount of padding to reduce bots comparing image sizes. (Possibly changing a watermark of some sort to deter more sophisticated bots).
• Remove the ALT text from these images. This text is usually redundant information that can be found elsewhere on the pages, or make them generic alt text (such as "Current item image would be here").
• The description could change each time a Bag of Crap comes up. It could rotate (randomly) between a number of different names: "Random Crap", "BoC", "Crappy Crap", etc...
• Woot could also offer more items at the "Random Crap" price, or have the price be a random amount between $0.95 and $1.05 (only change price once for each time the Crap comes up, not for each user, for fairness)
• The Price, Description, and other areas that differentiate a BoC from other Woots could be images instead of text.
• These fields could also be Java (not javaScript) or Flash. While dependent on a third-party plug-in, it would make it more difficult for the bots to scrape your site in a useful manner.
• Using a combination of Images, Java, Flash, and maybe other technologies would be another way to make it more difficult for the bots. This would be a little more difficult to manage, as administrators would have to know many different platforms.
• There are other ways to obfuscate this information. Using a combination of client-side scripting (javascript, etc) and server-side obfuscation (random image names) would be the most likely way to do it without affecting the user experience. Adding some obfuscating Java and/or Flash, or similar would make it more difficult, while possibly minimally impacting some users.
• Combine some of these tactics with some that were mentioned above: if a page is reloaded more than x times per minute, then change the image name (if you had a static image name suggested above), or give them a two minute old cached page.
• There are some very sophisticated things you could do on the back end with user behavior tracking that might not take too much processing. You could off-load that work to a dedicated server to minimize the performance impact. Take some data from the request and send it to a dedicated server that can process that data. If it finds a suspected bot, based on its behavior, it can send a hook to another server (front end routing firewall, server, router, etc OR back-end web or content server) to add some additional security to these users. maybe add Java applets for these users, or require additional information from the user (do not pre-fill all fields in the order page, making a different field empty each time randomly, etc).

Answer 20

Make the whole bloody page a CAPTCHA!
Sorta like Sesame Street... eight of these things, don't belong here...

Put 9 items, 9 HTML forms, 9 I WANT ONE buttons on the screen.
(9's just the number for the day... pick whatever number you want to make the layout still look good. 12 perhaps. Maybe customize it some for the resolution of the loading browser...)

And scramble them for each person.
Make sure the BOC has to be "seen" to know which one it is... of course this means the other 8 have to bee "seen only" also, to know they are NOT the item to buy.
Make sure you only use crazy-ass numbers to reference everything behind the scenes on the page's source. Fine, so the BOT sees its BOC time... but it'll be a wild guess to pick the right HTML form to submit back for processing.

Answer 21

What if you randomized or encrypted the form names and IDs, randomized the order of the form fields, and made the form labels a random captcha image, that'd make a script attack a lot harder :-D

Answer 22

2 things:

server layer solution: mod_evasive (if you use apache)

http://www.zdziarski.com/projects/mod_evasive/

front layer solution: reverse captcha, or other non intrusive captcha

http://www.ccs.uottawa.ca/webmaster/reverse-captcha.html

Answer 23

A potential solution to your particular problem (and not the general one) would be to require users to be signed in if they want to see the 'crap'. Only display the crap prizes to users that happen to be logged in. All other items can remain viewable to non-logged in users as they always have been. Then your loyal users are given first priority to the crap.

You'd obviously have to notify your users of this, perhaps with a notification that this is being done to increase the chances of real users finding the crap.

If your specific problem is bots harvesting for one particular type of item, then take the least restrictive alternative and only defend against that particular attack. This option would then prevent captchyas and the userability hit that you're concerned about.

If the bots log in and start spamming, you could force their log out and lock the account.

If they're only there to get the bag o' crap, they will leave fairly quickly and your page won't be taking the massive hits. Forget the highly technical solutions.

Answer 24

Two solutions, one high-tech, one low-tech.

First the high-tech: The BOC offerings sell out in a seconds because bots get many of them in the first few milliseconds. So instead of trying to defeat the bots, sell them what they are scanning for: a bag of crap. Worthless crap, of course: bent paper clips and defiled photos of Rosie O'Donnell. Then have built-in random delays on the server for a few seconds at a time. As the sale continues, the actual value of the product sold will increase while the sell price does not. That way the first buyers (bots in the first few milliseconds) will get something worth much less than what they paid (brown onion cakes?), the next buyers (slower bots or faster humans) will get something unspectacular but worth the purchase price (bought on consignment?), and the last buyers (almost all humans) will get something worth more than the purchase price (break out champagne?). That flat-screen TV might be in the very last BOC purchased.

Anyone that waits too long will miss out, but at the same time anyone who buys too quickly will get hosed. The trick is to wait for some amount of time...but not too much. There's some luck involved, which is as it should be.

The low-tech solution would be to change up the name of the BOC to something humans can interpret but bots can't. Wineskin of excrement? Sack containing smelliness? Topologically flat surface adjacent to assorted goods? Never use the same name twice, use marginally different pictures, and explain in the product description what is actually being sold.

Answer 25

As a long time (4 year) user of Woot.com and purchaser of a few bags of crap, amongst the many other items now taking up space in my garage, it seems that the solution should be part of the overall Woot theme.

Use captcha, but in a humorous vein. Much like the $1,000,000 promotion, make a game out of identifying yourself as a person. This has, in the past delayed the "sell out" of the BOC for a reasonable amount of time, while people, like myself, scramble to figure out the fairly simple but humorous puzzle to enter a coupon code.

Also, while people complain endlessly about the server errors, they don't stop coming back. Part of the thrill of a BOC in my opinion is the fact there are a gazillion other people trying to get one. If the servers throw an error, or a funky page, it's a sign that I'm somewhere in a group of way too many people trying to get one of 1500 products.

If you put as much creativity into building the puzzle, and it is original enough, it will delay the bots long enough to give everyone else a chance. Incorporating a random word that's captured as a code, putting an interim page between the "I Want One" and the purchase page, that requires some uniquely human interaction, you've stopped the bots there, until they figure out what needs to happen.

• You haven't implemented a boring, and sometimes painfully difficult to read captcha • you've made the process more fun, • you've reduced the load on the actual secure purchase server • You'll train the users that they will need to "DO" something to get a BOC • You'll stopped the bots at the interim page, delaying their purchases until most people have at least had a chance to try and figure out the funny, but not terribly difficult puzzle.
• Since being random is what a BOC is all about, a random, and changing puzzle/task would fit in simply with the whole pitch of a BOC.

As you experiment, the technology behind the interim page can become more advanced, with random information that can be captured for use in the purchase page. Since

I have purchased, without the aid of bots, or any scripts other than wootalyzer, which I feel is an acceptable aid, 7 BOC's since 5/31/05. The best one, which I didn't get, was the Please Please Me BOC. The B&D batteries were also fun, but I'm guessing didn't stump the bots, only frustrated the regular users.

Sometimes the best solution for a technology issue, isn't more technology.

Answer 26

As for CAPTCHAing everyone, why not use the Google solution of only requiring CAPTCHAs from IPs you suspect as being bots, or even just users that hammer the site? I'm sure asking someone for a CAPTCHA when they purchase isn't so bad if they've been hammering the site anyway, its just about the same as staying up and hitting F5 repeatedly. That or maybe require a periodic CAPTCHA when hammering, say every hundred (maybe smaller?) or so refreshes, to stop alarm-bots from working. You need some sort of CAPTCHA to prevent botting, but you also need to account for the fact that your real users will act like bots.

Answer 27

You will make enough on the lights today to pay for the CAPTCHA program from Cisco!! We are all used to them from buying concert tickets and other things.. It only seems fair. The way it is being done today is upsetting some and raising questions about a lottery or sweeps. I am sure you checked into that before you tried but it is not really a fun way to buy BOCs... It takes all the excitement out!

Getting the BOC first or a great product even by being on the sight draws people to Woot. If there is no reason to hang around and buy tons of stuff you don't need while waiting for the random BOC to come up, sales will drop off. The CAPTCHA may be the only way to defeat these people and still keep the excitement of Woot.

I was one of the first to get it to order a BOC last time and my first order was taken dumped with the million shipping and the second went through but was taken out of my account later. I was upset. I left Woot and have not purchased items like I did in the past on other days. I was willing to try it again, this way, today. I doubt I will in the future without a CAPTCHA for the fun stuff.

There are many sites trying to be like Woot. Of course they are not up to your level. I find myself reading a product description, not because I want the product, but I check in even for a laugh. I would hate to see someone come in with a fairer program and take away most of your business.

Just my opinion. I know almost nothing about bots and computers since I am a nurse.. But my vote is to upgrade to the higher level... The guys with the bots would just have to get in line with the rest of us and that is the way it should be:) Lori

Answer 28

Why not make the front page just an image-mapped graphic (all one picture with no labels, tags, etc)? Easy for a human to read and understand on pretty much any device, but impossible for a bot to interrogate. In essence make the whole front page a captcha.

Answer 29

How about selling RSA keys to each user :) Hey, if they can do it for WoW, you guys should be able to do it.

I expect a BoC for my answer ;)

Answer 30

Upfront caveats:

I'm not script-literate; I haven't read many of the other comments here.

I stumbled on this from the Woot description this morning. I thought a few comments from a moderate user of the woot sites (and two-time manual purchaser of BOCs) might be helpful.

Woot is in a unique position where it is both a commerce site and a destination with loyal users, and I understand the perceived delicacy of that balance. But personally I feel your concern about "negative user impact" of a Crap-CAPCHA ("CRAPCHA" - somehow I doubt I'm the first to make that gag) on users is way overstated. As a user I'd be happy to prove I'm human. And I trust Woot to make the process fun and interesting, integrating it into the overall experience.

Will this lead to the "arms race" posited? I dunno, but it can only help. If, say, key information to purchase is included in the product image or implied in the product description (in a different way each time), about the best a script could do would be to open a purchase page on detection of the C-word. Actually, I think this is fine: you are still required to be on-line and first-come-first-served still applies -- Wootalyzer and similar tools just increase awareness rather than automating purchase while I sleep or work.

Good luck figuring this out, and keep up the good work.

JGM