Poiché Mylar esegue la decrittografia nel browser, la chiave non viene mai memorizzata sul server. Bello. Ciò sposta la minaccia sul browser, dove, se l'utente malintenzionato è in grado di inviare uno script dannoso al browser insieme ai dati / app relativi a Mylar, lo script può raccogliere solo i dati decrittografati.
Quindi, in che modo Mylar garantisce che il codice dell'app che viene offerto al browser non sia dannoso?
Vedo in questo documento: link
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.
Quindi viene controllato un hash / firma del codice dell'app. Bello, supponendo che questo hash / firma non sia stato compromesso, possiamo sapere che il codebase è valido rispetto a una versione specifica. Vedo anche che Mylar utilizza due origini. Cosa succede se entrambe le origini sono compromesse? Inoltre, una delle origini potrebbe essere uno specifico hash di git repo? Quali sono i possibili problemi che interferiscono in qualche modo con questo passaggio di verifica?
Mi piacerebbe capire di più su come funziona questa specifica funzione di sicurezza e su come è sicura.