> 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

Also, there are numerous discussions about how to ensure a build/binary is what it purports to be. I'm trying to find those…

EDIT:

https://news.ycombinator.com/item?id=8023035

1. I think the best option is for the client to encrypt using a local library, like NaCl before sending anything to the server. The server should not provide the encryption algorithm. The client and server must agree in the algorithm, but neither provide it.

2. Yes, it defers trust and responsibility. Now Mozilla, Google, Apple, Microsoft, and Opera are on the lam for issuing a competent browser encryption.

The messed up thing is, all it does is defer trust. What I'm trying to say about the current state of client-side web crypto as far as I understand it, deferring trust doesn't do a damned thing. It's still the source of the crypto lib, which is you.

EDIT: clarity

OT, but: on the hook. On the lam means you are trying to escape (re)capture by the legal system.

Thanks, you're right. I've misused the word for ages.

You might be interested in this client side encryption I worked on if you're looking for something like this https://github.com/abemassry/wsend-gpg it is a command line app though, I couldn't get it to work in the browser.

I'll check out. Browser and command line crypto are two different beasts; it is where trust is placed.