I'm glad you mentioned this because I feel it's worth a response.
When you develop protocol or infrastructure code the more general the facility is that you develop the less control you have over how the result is going to be used.
For example SSL was originally developed for the purpose of making people feel safe transmitting their credit card numbers to e-commerce websites. Credit cards (like cars) have a pretty predictable upper bound on the financial loss should this system break.
However, the SSL/TLS protocol was very general and it has grown to be used for everything under the sun today. From protecting Twitter APIs to "launch the missiles"-type critical systems.
So when you advocate a general technique like Javascript browser crypto, you don't get to qualify it with "only for stuff that really isn't worth attacking anyway". You don't know in advance what data it's going to be used for, much less what the value of that data will be to attackers in the future.
When you develop protocol or infrastructure code the more general the facility is that you develop the less control you have over how the result is going to be used.
For example SSL was originally developed for the purpose of making people feel safe transmitting their credit card numbers to e-commerce websites. Credit cards (like cars) have a pretty predictable upper bound on the financial loss should this system break.
However, the SSL/TLS protocol was very general and it has grown to be used for everything under the sun today. From protecting Twitter APIs to "launch the missiles"-type critical systems.
So when you advocate a general technique like Javascript browser crypto, you don't get to qualify it with "only for stuff that really isn't worth attacking anyway". You don't know in advance what data it's going to be used for, much less what the value of that data will be to attackers in the future.