Ok, now what? There is clearly strong demand for cryptography in client side web applications. Telling people "don't do that" isn't good enough, they're going to do it anyway. How can we make it better?
One idea: a way to bundle, hash, and optionally sign a set of HTML/CSS/JS resources (not unlike a Chrome extension). If the bundle is updated the user can be prompted. If the user desires, they can check to see if trusted individuals or groups have already reviewed the code, or review it themselves. Perhaps the code is hosted on Github (or wherever) and people can comment on questionable changes there.
I agree that yes there is a great deal of demand for crypto on the client side and I don't think privacy on the Internet is going to move forward without a reliable way of doing cryto in that sphere.
However I agree with the poster that client side JavaScript is not the answer to that demand. At this time it's a leaky boat and can be exploited.
These seem like pretty weak arguments to me, especially if you were able to restrict execution to resources in the bundle (maybe that means no "eval" -- fine)
Most languages permit similar amounts of runtime dynamism, they just don't make it as easy as JavaScript. Actually, in some ways JavaScript is better than other languages in this respect:
* Using closures to encapsulate "private" variables is pretty bulletproof, AFAIK.
* ES5 features like "Object.freeze" and "strict mode"
* Object-capability safe subsets of the language, e.x. Caja, SES, etc
One idea: a way to bundle, hash, and optionally sign a set of HTML/CSS/JS resources (not unlike a Chrome extension). If the bundle is updated the user can be prompted. If the user desires, they can check to see if trusted individuals or groups have already reviewed the code, or review it themselves. Perhaps the code is hosted on Github (or wherever) and people can comment on questionable changes there.