The problems may be entirely due to my paranoia which assumes the host cannot be trusted so communications must be done in such a way that the host gains limited information even when compromised. But at the same time, the system cannot be so draconian that it wouldn't work at all
Given that you can interact with the user, accept the password, etc entirely within the browser, and assuming that a suitable and trusted existing encryption library can be used, the rest is just standard ajax between js/server. A lot of work of course, but no new ground.
I think you're right that we should work on the common browser front end and treat the JS code as inherently separate from the backend code (we'd define an API I suppose). I would prefer the JS to be hosted separate from the server operator, but I would still accept a one host system, since its still a big step forward. But as long the browser front end is treated separately, its the right road map.
The front end definitely should be open sourced and flexible, I was thinking more of a reference API built on top of library of core functions. This would allow custom front end by implementing custom top level functions to replace the reference API without the need to change the core functions. The core functions could be hosted on public servers, which reduces the amount of "suspicious" code to be verified to only the custom frontend.
We might be getting seriously off topic for this sub-board though