This approach is uniformly as good as or better than a browser app not using in-browser crypto from a security perspective. As daeken noted in a discussion a few days ago, it provides protection against a demand to produce the notes. He also claims that "For all other cases, there are a million simple means by which you can break it." So I challenge anyone on HN: Show me such simple means.

The instructions for claiming a reward are contained in a note stored in the app's database. To help you along, I'll navigate to any URL you send me while logged into the site. If you'd like to try your hand at finding a vulnerability in the AES implementation used, I'll send you a snapshot of the database. If you want to try injecting code, I'm happy to use a network you control if we can arrange the logistics though I won't promise to log in if you can't provide a valid SSL certificate :). If you need assistance to demonstrate a reasonable attack, ask. Post your attacks below or email my user name @gmail.com. The first successful attack wins. Usual disclaimers apply.

You might argue that this doesn't prove anything about JavaScript cryptography since additional security is used. That's true. If this survives, it doesn't provide evidence that the in-browser cryptography is sufficient; it only suggests that it can defeat some additional threats against an otherwise secure application.