5 ms·

In the about page: > Using client-side cryptography, your files and text are protected with a special password that is never sent to our servers. However, the

by gry 12y ago

In the about page: > Using client-side cryptography, your files and text are protected with a special password that is never sent to our servers. However, the .js file is still sent server-side. Tony Arcieri notes "there’s nothing to stop anyone who has sufficient access from injecting a malicious payload into it at any point in time." [1] This is a false promise; a user still must trust the server. [1] http://tonyarcieri.com/whats-wrong-with-webcrypto http://tonyarcieri.com/whats-wrong-with-webcrypto

abemassry 12y ago
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 https://github.com/abemassry/wsend-gpg it is a command line app though, I couldn't get it to work in the browser.
- gry 12y ago
  I'll check out. Browser and command line crypto are two different beasts; it is where trust is placed.
diafygi 12y ago
> 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
- gry 12y ago
  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
  - superuser2 12y ago
    OT, but: on the hook. On the lam means you are trying to escape (re)capture by the legal system.
    - gry 12y ago
      Thanks, you're right. I've misused the word for ages.
- gry 12y ago
  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 https://news.ycombinator.com/item?id=8023035

by gry 12y ago

abemassry 12y ago

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 https://github.com/abemassry/wsend-gpg it is a command line app though, I couldn't get it to work in the browser.

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

diafygi 12y ago

> 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

gry 12y ago
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
- superuser2 12y ago
  OT, but: on the hook. On the lam means you are trying to escape (re)capture by the legal system.
  - gry 12y ago
    Thanks, you're right. I've misused the word for ages.
gry 12y ago
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 https://news.ycombinator.com/item?id=8023035