tptacek (original author of the OP here) and I responded to the draft here: http://news.ycombinator.com/item?id=4549504 The tl;dr is: the trust model is broken, and low-level primitives exposed in the way that they are is begging for pain.
Doesn't the Chrome plugin model sort of highlight the way forward? Chrome plugins have their own JavaScript environment, sharing only the DOM with client pages. A client wanting to do crypto could, for example, communicate this by mutating a piece of the DOM (for example, setting the text of a meta cleartext node) and then waiting for a DOM mutation in answer (a meta cyphertext node that, from the page's perspective, magically pops into existence).
Anyway, that's how I'd do it. But yes, doing crypto within a page seems to be asking for trouble.
I suppose so. But if that's your level of paranoia you probably shouldn't be doing native crypto either, as any process on your machine could be finagling the memory regions of your "secure" program in the same way. In fact, the only secure way to do crypto, I suppose, is pen and paper.
Yeah, I am not very optimistic about the primitives being used correctly, or any kind of safety in face of e.g. XSS. At least you can read from /dev/urandom...
Did either of you send any feedback or file any bugs at that time? A keyczar approach would be much loved by front-end devs and management.
EDIT: There are some promising comments in their archives, "A high-level API is also perceived to be the only kind of API that is usable by the majority of web developers. I agree we should not put this off to long." [1]
Not a lot has changed since then, sadly.