It probably does, but it also makes it easier for a human. I would guess that humans gain from it far more than bots do (since humans are really good at distinguishing moving objects), which should be the primary goal of a captcha.
In theory, you could make the letters overlap so much that it is difficult to distinguish them in a single frame. This would give humans a distinct advantage over robots. However as it stands, a single frame is barely obscured at all, and I'm sure it could be easily broken.
I agree. Their assumption must be that OCR fails when a letter has covered regions, and to make it more readable to humans they provide the missing information in other time frames. But the letters have very nice borders and shadows, they are not deformed and have rigid motions which is trivial to track. Even in a single frame they provide more information than a traditional captcha. But the concept is promising and will definitely work with few modifications (e.g. no stroke color, time dependent deformations, not showing all letters in all frames etc.)
What makes you think the individual frames look like the letters? They certainly don't have to. At the price of a little flickering you could, say, show the top half of the letters in one frame, the bottom half the next, the right half the next and so on. Or randomly leave out one letter in every frame. Or even throw in different replacement letters for one frame each.
Accuracy is not always the only factor in play. The computational power required to process 20 frames is 20x the normal image. And the overhead of actually comparing the frames 20^2 if each frame is compared to every other frame. Since this is done automatically by bots, speed most certainly does affect the final performance of a bot.
Comparison of frames? I was only thinking about averaging predictions for each frame which is just 20x slower. Still I think that the process is way more constrained by the time to fetch new CAPTCHAs than by OCR, so this doesn't really matter.
Why not? If it can grab all 20 frames, it has 20 times more data than it would normally have to solve the captcha.
Even if the captcha recognition's success rate is only 5%, its overall recognition rate is going to go through the roof.
You also get to do something you can't do with static captchas, compare the results. If 70% of the frames recognized the first letter as A, it's likely to be A, and so on.
As the letters move, they briefly do the really hard task of segmentation for you.
If there is any incentive to crack this captcha, it will be cracked very soon if not already, it looks like a very easy one to write.
I was thinking they'd use motion blur - humans are good at seeing through that. But they don't blur. Each frame is crystal clear. Giving the bot 20 data instead of one, as you say.
Sure, but it wouldn't take a lot of tuning to update a bot to read the animated frames and then you're back to square one. In fact, with 20-odd frames and only three (entirely upper-case!) letters to select it looks very easy to develop a bot that would get a very high success rate.
Are the people using the captcha-breaking algorithms the ones developing them? Probably not. These things take time... the best way to combat them is probably to change what your captcha looks like and works like every week or so.
With this implementation you don't, but it's not hard to construct it such that there is no single frame with enough information to construct the whole message. If you screen capture there are several frames where you really can't tell what the middle letter is, but it's obvious what the message is.
The real issue is a computer can compare the images individually and combine them so if it get's 'G_G', 'GF_', and '_FG' it's going to assume 'GFG'.
In that case you don't gain anything from the motion (except maybe the ability to vote between your bot's output for the individual frames, but that also makes your bot 20 times slower).
It is pretty snarky, considering this is a one-off use of a 3rd party captcha solution on a form only required for legal reasons for a time limited promotion.
I doubt the unique capture implementation was done for a one off limited time form, I would have thought that this is something Apple has cooked up for re-use across multiple projects and this just so happens to be one of the first.
I'm surprised they don't include letters in different colors and only have you distinguish ones of a particular color. Or make certain colors blink having the user select only the ones that are blinking.
I tried making an animated gif CAPTCHA a few years back, relying on persistence of vision (to try and get round the whole screenshot and process botting issue): http://sandbox.palmnet.me.uk/gifcaptcha/index.php
Ended up with roughly 75% correct human responses and 40% correct using a bot. Which are pretty poor stats for both sides of the equation.
I would continue working in this. I have some feedback to make it harder for robots and easier for humans. Consider this as some quick ideas that should be elaborated (and they may be wrong):
- Move the letters in opposite direction to the windows and maybe rotate them or make them move inside the canvas.
- Make the windows appear in randomize locations but move them faster.
- Make the blacked part change colors.
I think this is a very, very good way to make a turing test. Congratulations.
Cheers for the feedback.
I gave up on it quite a while ago but I could revisit it some time and try out some of your ideas.
The main issue was that some browsers render the frames so slowly it was almost impossible. Also, while making it slightly harder to crack with a bot it can be done by merging the frames together and tracking the lightest parts to find the letters which can then be put through OCR.
Also, while making it harder for bots to crack it also makes it significantly harder for people to read, especially people without 20/20 vision which is a major problem.
Definitely. You should also consider tracking which letters have low recognition rates, since I guess it's mostly problems with things like Q vs O and Z vs 2.
Also, this bit: "It's important to note that NuCaptcha is a video stream and not a Flash program. This is because it is not secure to create a Captcha in Flash."
Yet, the Click-to-Plugin feature from Chrome says it's Flash. Worst captcha company ever?
I think the point is that it's not a Flash program that is taking the Captcha value as input and then animating it, where it would be easy to sniff the input value. It's a Flash player for a video stream that is generated externally to the Flash.
Interestingly they claim that the moving images are "an H.264 MPEG-4 Video Stream that is rendered in your browser in a variety of ways" http://nucaptcha.com/features/security-features but they're not--it's just an animated GIF!
The signup form looks horrible because they've mixed serif-fonts with a page with sans-serif fonts. Probably some intern is going to get fired for this...
The form is actually in an <iframe>, and the iframe content is completely unstyled, so presumably if your browser's default font is sans-serif then you won't see it.
This is the alternative means of entry page for a contest. This isn't even a page that Apple _wanted_ to build. It's a legal requirement. The CAPTCHA is provided by a third party. Who knows why it was chosen. I doubt they put a ton of thought into this page, or the choice of CAPTCHA, if they even built it themselves at all.
This still doesn't solve one of the big CAPTCHA issues. Do look at this USENIX paper in [1]. It's still possible to offshore manual CAPTCHA solving to places with cheap labour at extremely low costs. I don't know how common software solvers are, but my impression is that the technology there is only so-so.
Its very possible that the contest is being run by an outside agency and Apple have been know to proxy in content from the outside agency and display it inside an IFrame, similar to here.
If this gif CAPTCHA system becomes popular, there will be some smart hacker who will figure out a way to crack this (read first frame, match different frames etc.)
I wish there was some better CAPTCHA alternative. CAPTCHA can be really horrible sometimes.
I know some people who close a webpage when they see a CAPTCHA, unless they have no other option and are forced to fill the form.
You don't even need to be a particularly smart hacker. Even just dumping a screenshot of the page [1] using phantomjs gives you a relatively legible image.
Don't forget that if you're using animation and video to design a captcha, there are a lot of other design options possible: letters appearing one after the other, going in and out of blur, playing with colors, etc... A lot more graphical gimmicks can be added while maintaining comprehension for humans, and hopefully, improving blocking bots.
I wonder if creating an animation using canvas would've been better. Then the only way to crack it would be to bring the whole page in memory, take a screenshot and then OCR only the spot the canvas is in. If you made the animation move around also then I don't think anyone would bother trying to crack it.
Manipulating canvas requires javascript. It's probably not a good idea to give out value to captcha via js. Although modern browsers are very strict with who can access what js scope.
I know I'm not the only one who turns off gif animation in browser options. Lots of people can't read text if something is moving on the page. It's going to be a big hassle to turn it on for certain sites, then off again after the CAPTCHA, if this catches on.
Maybe it is enough to just try something different? Certainly somebody can break this, but if its something new, it requires some effort. Compare that to some well-known captcha system which you can break for something $2 per thousand captchas.
There's 20 frames in each challenge image, 20 different sets of data to process and compare for a correct result. It's also three letters long.
ED: The form itself is included in an iframe, with the following tag:
ED2: The audio CAPTCHA sounds even weaker. You could probably just pipe that to Googles dictation API and you'd be set.