Because Mylar does the decryption in the browser, the key is never stored on the server. Nice. This moves the threat to the browser, where, if the attacker is able to get a malicious script to be served to the browser along with the Mylar related app/data, then the script could just harvest the decrypted data.
So, how does Mylar ensure the app code that is served to the browser isn't malicious?
I see in this document: http://www.mit.edu/~ralucap/mylar.pdf
Verifying application code. With Mylar, code running in a web browser has access to the user’s decrypted data and keys, but the code itself comes from the untrusted server. To ensure that this code has not been tampered with, Mylar checks that the code is properly signed by the web site owner. This checking is possible because application code and data are separate in Mylar, so the code is static. Mylar uses two origins to simplify code verification for a web application. The primary origin hosts only the top-level HTML page of the application, whose signature is verified using a public key found in the server’s X.509 certificate. All other files come from a secondary origin, so that if they are loaded as a top-level page, they do not have access to the primary origin. Mylar verifies the hash of these files against an expected hash contained in the top-level page.
So an app code hash/signature is checked. Nice, assuming this hash/signature hasn't been compromised we can know the codebase is valid against a specific release. I also see that Mylar uses two origins. What if both origins are compromised? Also, could one of the origins be a specific git repo commit hash? What are the possible issues with somehow interfering with this verification step?
I'd love to understand more about how this specific security feature works and how it is secure.