davekt

https://typing.io/lessons let you type through code, which exercises the right pinky more than prose. The site also requires backspacing to correct typos. This adds realistic overhead not normally captured in wpm measurements.

Some amex cards have a 3 digit cvv [1].

[1] http://ecommerce.shopify.com/c/shopify-discussion/t/heads-up...

The home page of this article has a section comparing text inputs vs drop downs [1].

[1] http://creditcardjs.com/#drop-down-for-expiration

One scenario where immediate detection is helpful is for unsupported card types. The server detection would require users first fill all their card data only to discover they need to start over.

For a production ready alternative, take a look at http://creditcardjs.com, which was posted on HN a while back. The web site points out common mistakes when implementing credit card forms and delves into the motivation behind every design decision.

Thanks for responding. I would argue the opposite, that the browser is the safest place to sanitize because it better understands the context where user generated strings will be inserted.

An example where the server may not understand the correct context occurs in this utf7 attack (http://html5sec.org/#charset). The server sanitizes the user input as utf8 where it passes. The client forces the browser to interpret the input as utf7 instead, and the string that was harmless as utf8 now becomes active js.

Correct. If the 3rd party js properly sanitizes user input, this xss attack is moot. However, browsers love to eval stuff (http://html5sec.org/), and sandbox iframes provide good defense in depth. Secure programs like qmail have been using separate, sandboxed processes forever, but this secure design model has only recently been possible in the browser thanks to iframes and postMessage (http://www.cs.berkeley.edu/~devdatta/papers/LeastPrivileges....).

An example attack iframes would make more difficult is XSS in the comment fields, e.g. an attacker bypasses sanitization and injects js into a page. With a sandbox iframe, the comments section could be restricted from compromising the top level page, e.g. stealing cookies, redirecting, etc.

For 3rd party widgets, I actually prefer iframe for security. The same domain policy makes it more difficult for xss in the iframe to compromise the parent page. For HTML5 sandbox iframes, the security boundaries are even more strict and tunable.

There are some disadvantages to current iframes that Moot addresses like the lack of CSS cascading from parent page to iframe. The seamless iframe spec addresses this issue, but it's not widely adopted yet.