1. Nothing like this is ever safe; the server can surreptitiously feed you JS that will fatally compromise your encryption.<p>2. This one is even worse, because it loads scripts from CDNs, all of which can compromise the encryption on the page.<p>3. If you're going to put Google Analytics on a page that purports to encrypt data clientside, you might as well just build a front-end to Google Docs, because you've given Google access to the content of the pages anyways. (I think a simplified Google Docs front-end is a fine thing to build, more useful for security than "clientside" encryption).<p>4. You're encrypting with unauthenticated CBC mode, which is obviously insecure.<p>5. It's unsafe to compress before encrypting; doing so creates traffic-analytic side channels. There's a whole thread of TLS vulnerabilities stemming from compression occurring at various points of the web stack.<p>If you really want to build something like this, my recommendation is:<p>1. Switch from a web page to a web extension, which will obvious most of the serverside dependency problem.<p>2. Stop using CryptoJS, which is extraordinarily difficult to use "properly", and use a Javascript NaCL implementation instead.
I've implemented all points that @tptacek mentioned (except the web extension, that will be a future update), and will also activate HSTS when I feel comfortable with the server setup.<p>I switched from CryptoJS to TweetNaCl which seemed fit to purpose, and also moved all CDN depencencies locally as well as removed Google Analytics :)