I'm doing FFTs at regular intervals using the Accelerate framework. Then a lot of rolling window comparisons of frequency data to try and determine which fingerprints these frequencies match closest.
I don't think that's what they're saying at all. I think they're saying there are some features that are going to work best on an integrated hosting platform, just by their nature
I'm the guy who made the bot. I'm looking at relaunching this in a way that GitHub are happy with so that you can at least request an optimisation on your repos. In the meantime, check out http://imageoptim.com/
Interesting, I'll have a look at your workaround. It's truly awesome the things you can do with static files right now - no need to worry about a server staying up, having enough space, etc, etc.
I think the main use for this is going to be uploading images at a reasonable resolution. On mobile, you rarely want to upload the full 8 megapixels from the camera. The fact that you can scale it down client side is awesome!
"Essentially all this does it check the password (well, with extra meaningless false positives) without you having to press return."
You're absolutely right. That's a far clearer explanation of what's happening here. A standard login form is rate limited to protect from brute force attempts, when calling a url for each character entered, this is problematic. I think the value in his approach is that it makes it significantly harder to brute force the password.
Why not just use a video camera to watch them type on the keyboard? Plus, mobile devices show the last character typed. You're right, but this could be avoided by (for example) only displaying colors after 4 characters are typed
I think a better solution would be to only show the colour hash after there hasn't been a keypress in a few seconds. This would likely be a pretty good way of making sure you only displayed the hash after they were done typing their password, which would prevent enabling a brute force attack.
