Studio moh

CAPTCHAs (Completely Automated Public Turing test to tell Computers and Humans Apart) are easily hacked...apparently.

So...I'm brainstorming different methods of testing for human intelligence that aren't easily hacked by computers.

One major problem of conventional image-based CAPTCHAs are their inaccessibility to people that are blind. This shouldn't matter to me if I'm developing a CAPTCHA for an art website...but still! It's a fun little challenge!

The W3C has an interesting paper on the issue of inaccessible CAPTCHAs and offers possible solutions:

• Sound output: sites like Hotmail, Google, and Yahoo! use this secondary, non-visual CAPTCHA for blind users. Great. But what about blind AND deaf users?! Plus, voice recognition technology works very well with these computer generated voice samples...
• Non-interactive checks (like Heuristics, or SPAM filtering): these are my personal favourite techniques for CAPTCHA. But, using heuristics to determine the behaviour of robots still requires them to spam your site...and high-volume human users might be difficult to separate. Oh, and SPAM filtering can be hacked, sadly...
• Logic puzzles: this sounds promising...ask a simple math, verbal, or recognition-type question that computers can't "get". The W3C says, "Users with cognitive disabilities may still have trouble." I don't really want stupid people on my websites anyway...but, America is raising a nation of below-averagestupid students, so these tests would have to be simple enough for them to understand. Argh!

I love challenges like this :D

I'm torn between making a Taboo-esque CAPTCHA (eg, What's white, comes from cows, and you have it every morning? Answer: Milk!) and just using server-side, unobtrusive heuristics...

Sigh!

Heuristics are the way to go, obviously...but, omg...it's not nearly as fun.

...it's fun, easy, and always makes me happy.

I don't do any malicious hacking (that's bad, guys), I just download everything. Real quick. Woosh.

I justify hacking as training me against the worst possible scenario for my own sites...and how I can develop more secure code.

...sigh, it's just a reminder that you can never trust anything from the end-user; headers, cookies, form-input...anything can be turned into a code-injection point.

Making your own CSS styles is a nice (albiet butchered and terrible implemented) touch in MySpace.

In a normal web design workflow, you have something like this:

.modules {
background-color: #fff;
padding: 15px;
}

.modules p {
color: #aaa;
line-height: 150%;
}

In MySpace’s world, it’s more like this:


table table table table td, table table table table tbody td {
background-color: transparent !important;
padding: 15px !important;
}

table table table table td font, table table table table tbody td font {
color: aaaaaa !important;
line-height: 150% !important;
}


Ugh. Stab me in the eyes as hard and fast as you can, MySpace.

I was playing around with my API for FAP and made a very simple, 7kb, browser-based mass upload tool. Permissions and authentication are verified with JSON on the client side and files are uploaded using a plain POST request. Easy enough.

The problem came when I was trying to get my script to POST to the API. Asynchronous cross domain requests aren't permitted in most browsers. It's a serious security risk.

My solution: the iframe.

By targeting all POST requests to an invisible iframe the cross domain issue is no longer a problem.

You can even check progress with the onload() event.