My University (The University of Kentucky) actually just implemented this this year. We scan the codes and we can either go to a webpage or download an app that has the GPS location of the buses with ETA. Pretty cool, actually.
There's a project here in my town by a couple of my fellow engineering students working on a related idea they're calling awesometouch. They've installed a few in our city already as far as I know.
I don't believe they're running Android, and the machines are pretty special purpose, but still similar in concept as far as huge touchscreens go: http://awesometouch.org/
Thanks for the mention @jadedoto. You're correct, we're not running Android on our screens, but there is an Android port for MT4j, the Java multitouch framework we use: http://www.mt4j.org/blog/index.php?entry=entry110404-105831 If this Android x86 port comes further along (and there's some way to do remote administration for Android), maybe we can start developing for Android first, and porting that over to the large screens.
On the hardware side, one of the unfortunate limitations with most large touchscreens in that price range is that they only accept 2 touchpoints. For most applications, that's sufficient, but Martin mentioned that one of his goals is to enable multiple users to simultaneously interact. While the opportunity for that is a bit limited on his Acer screen, the larger screen size alone does make it easier for two users to view the screen simultaneously, and it's easier for them to alternate in usage without passing the screen back and forth.
Yeah, awesomeTouch runs some custom Java on top of Linux, although both their hardware and software have most likely evolved since last I saw.. They just did betaSpring, I believe.
LexKY in the house! Our team just got back from Betaspring, we have come a long way since our early days hacking with the NUIGroup / CCV tools: http://nuicode.com/projects/tbeta
We've narrowed our focus to indoor map applications. We're still deploying them on giant touchscreens with AwesomeTouch, but have also started a project called BuildingLayer to aggregate & crowdsource maps for the insides of buildings (because people always get http://lostinabuilding.com). And just ask John King from CNN, the only thing better than games on a giant touchscreen are maps!
I miss going to class with a floppy and knowing it was corrupted, get an extension on the assignment. I am only 20... are there really computer users out there unfamiliar with floppies? I keep 5.25" drives around for fun and I still have Windows 95 on 3.25"ers :)
I dont think he is stressing the ease of doing this with credit card numbers. The sample space he is suggesting generating is far too large... You can usually identify the first several digits simply by the issuing organization, as they all use standardized numbers, the remaining digits must pass a certain checksum algorithm. So really generating a bunch of valid cc numbers is quite trivial. Matching exp dates with numbers and ccv numbers.. Different story.
But i wonder what the limits to effectiveness is on this attack. I usually randomly swirl around with a smear tool to blur out things...
Bank of America uses a horrible method for generating debit card numbers. It's a standard prefix + account number + sequence number + check digit. If you have stolen someone's BofA debit card number then you can easily guess the replacement card's number (just increment the sequence number and recalculate the check digit). From there you just need to guess the expiration date (a comparatively trivial task).
Either you're skipping over a lot of information in the process of how that number's generated, or that's not how they do it anymore (and not how they've done it for at least the last couple of years).
But that's for debit cards - I think most banks include the account number in a debit card number. You would still need the CCV number from the back of the card for the attack to work.
edit: CCV proves that you at one time had access to the CCV number.
Online merchants are supposed to comply with PCI-DSS - not store your CCV ever, never transmit your number unencrypted, never store cardholder information unencrypted, plus tons of management controls and audit controls over the same.
In practice, let's just say lazy programming is everywhere.
I've seen many people who handle online transactions and violate PCI-DSS to some degree, including storing CCV numbers.
I'd expect random swirls to be reliable, or any obfuscation that introduces a reasonable amount of entropy. This whole attack relies on an almost-exact replication of the original blurred image. If you do something a computer can't easily reproduce over and over again, or something that looks the same no matter what the obfuscated content is (like blacking out), this attack cannot work.
Also, as far as your input filtering goes, I enjoy the 2001: responses. But you're not picking up extra "$" characters for it. It gives me an answer for "$$$$$$$$$$$$$$$$$$$$$$$4" and "$$$$$$4$$$$$$" and "$$$44$$$4$4$", for example.
