> This is a false promise; a user still must trust the server. How is this any different than trusting mozilla.org when you download Firefox? Unless you write

> This is a false promise; a user still must trust the server. How is this any different than trusting mozilla.org when you download Firefox? Unless you write the software yourself, you have to trust a server at some point. So I think what you meant to say was, "A user still must trust the server every time they load the program, which is different from only trusting it at install time". To which my reply is, yes, they do. However, it's simply the best we can do right now while still making it user-friendly for this audience. What is your alternative proposal? Apps like this are trying to address the root bug[1] using a go-where-the-people-are strategy. Tons of people use the web, therefore we should make apps that use the web. Asking them to change their behavior is incredibly difficult, especially when they don't see any tangible value out of changing. So here's some questions for you: 1. What is your proposal to addressing the root bug[1]? 2. What will people's reactions be when you ask them to use your proposal? Empathy for the user is one of the biggest things that I think most crypto projects are missing. These kinds of apps at least attempt to consider user adoption in their scope. EDIT: The cool thing that this project does that I haven't seen before is just put the encryption password in the URL fragment. That way, it can be automatically read by the client javascript for decryption, but it will not be sent to the server as part of the request. Clever! [1] - Pervasive Monitoring Is an Attack - http://tools.ietf.org/html/rfc7258 http://tools.ietf.org/html/rfc7258