Well, let me explain my thinking. Suppose we sign https://server.com/sjcl.js https://server.com/sjcl.js. That resource is now tamper-proof in the event that se

Well, let me explain my thinking. Suppose we sign https://server.com/sjcl.js https://server.com/sjcl.js. That resource is now tamper-proof in the event that server.com is compromised. But what about the rest of the application HTML/js? For example, an attacker could just say: <script src="/sjcl.js"></script> <script>sjcl = ...</script> And overwrite the library on the client side. Ok, suppose the browser support for content-signing prevents this somehow. The attacker can still modify the application-level code to use the library unsafely. I'm not totally familiar with the API sjcl exposes, but consider something like the e=1 RSA bug that was found recently. Even if sjcl's API is so great that it's impossible to misuse, an attacker could simply render application code that doesn't use it at all. Or he could just log keystrokes and phone home the pre-encryption content. What if we sign everything, including application HTML/js? Now we have another problem. We've basically resigned ourselves to serving only static content. We can't render any user input, because this would require a new signature. Probably not a useful web app.