Assuming that the web service is doing proper client side authentication most of the time (which, with enough effort, can be verified), and then gets coerced in

Assuming that the web service is doing proper client side authentication most of the time (which, with enough effort, can be verified), and then gets coerced into sending compromised JS at some point in the future - we still have better security than the alternative of no client side security at all. Sure the increased chance of a malicious update is a real threat, but it is better than that attack not needing to be performed at all. A further incremental improvement could be made using a Mega-style root of trust (ironically, an article explaining how they messed up the implementation explains it best: http://fail0verflow.com/blog/2013/megafail.html http://fail0verflow.com/blog/2013/megafail.html). Only the initial loader page (with embedded hashes and MACs) needs to be checked for whether or not it has changed on each page load. If you want to be immune from a later malicious update, you just have to manually save the loader page and open it instead of re-requesting it from the Mega. Yes, during an update they can stop serving the old scripts and deny access, but you will at least always know when an update has occurred.